¿Cómo puedo evitar que otro equipo se haga cargo de mis proyectos?

Necesita fijar a su colega a una fecha.

Calcule qué tan pronto puede entregar y luego aumente la estimación en una cantidad adecuada, tal vez 20-40%. Programe una reunión con su gerente y colega y dígales que necesita que el producto se entregue en esta fecha. Pregunte si su colega puede entregar. Si dice que sí, entonces genial, puedes documentar su compromiso. Si no pueden prometer cumplir con el objetivo, presione con fuerza para hacerse cargo del proyecto usted mismo.

Intentaré responder parcialmente a tu pregunta, es decir:

Esto también ha causado un gran retraso en nuestra entrega.
¿Cómo puedo manejar esta situación? ¿Qué puedo hacer para evitar que este problema vuelva a ocurrir en el futuro?

Creo que deberías centrarte en tratar de no retrasarte, en lugar de centrarte en lo que el otro equipo debería construir o no. La clave aquí es que todos se den cuenta de que estos dos requisitos parecen "un sistema que hace notificaciones", pero no lo son. Su proyecto necesita un sistema que envíe notificaciones para su caso de uso específico en este momento , mientras que el otro equipo está construyendo un sistema generalizado para notificaciones en alguna parte . Dado que no tiene tiempo para explorar todos los casos de uso posibles para crear una solución generalizada y el otro equipo no está listo para proporcionar una solución funcional en este momento, existe una razón para mantener ambos proyectos por ahora.

He estado en una situación similar antes, excepto que mi solución aún no estaba construida. Después de discutirlo con el otro equipo, les dije a mis gerentes: "Aún no están listos. No sabemos exactamente qué les proporcionaremos y cuándo estará listo, y no queremos arriesgarnos a que nos bloqueen, así que decidimos ir con nuestra propia solución por ahora , aunque eso significa que tenemos que hacer parte del trabajo dos veces".

Mis gerentes se preocupan más por el cumplimiento de los plazos que por la escritura de código potencialmente redundante. En su caso, su código ya está allí, por lo que puede presentar un argumento aún más sólido.

También me aseguré de tranquilizarlos:
"Estoy entusiasmado con su solución, y realmente creo que cuando haya terminado, deberíamos buscar integrarla con nuestro proyecto. Dado que aún no tiene un cronograma, y ​​debemos entregar para diciembre, creo que por ahora iremos con nuestra propia solución. De esa manera, nuestros equipos pueden trabajar de forma independiente, pero mantenámonos actualizados".

Reconocer que hay espacio para dos sistemas en este momento, y que se pueden fusionar en un futuro indefinido, evita un contexto irritante. Para el otro equipo también es un beneficio no tener a su equipo con una fuerte dependencia y una línea de tiempo estricta respirándoles por el cuello.

En mi caso creo que al final al otro le tomó más de un año terminar su servicio, y nunca migramos a su solución, al menos mientras yo estuve involucrado.

Por lo que deduzco, su equipo necesita notificaciones como una de las características de su producto.

Hasta que la gerencia le indique que NO construya la funcionalidad de notificaciones antes de que el otro equipo las proporcione, su equipo debe proporcionarlas y puede estar pendiente de los retrasos derivados de no tenerlas.

Dicho esto, depende de su gerente y equipo decidir de qué manera se construirá SU característica.

Tal como lo veo, puede construirlo como una solución general y utilizarlo en su proyecto.

Y después de eso, su gerente puede presentarlo en la cadena de mando como una característica de su producto que puede estar disponible para otros proyectos en la empresa.

En ese caso, la propiedad de la solución permanece en su equipo.

Actualmente, admite notificaciones por correo electrónico y estamos trabajando en push y sms.

Así que ya tienes una solución que funciona, ellos no tienen nada. Pídale a su gerente que estudie la posibilidad de poner a ese equipo bajo su supervisión. Ya demostró que tiene buenas iniciativas y que puede cumplirlas.

Como material de apoyo para la discusión, construya un pequeño "plan de proyecto" que muestre las principales actividades requeridas, los módulos deseados en el software y la cantidad de personas que se estima serán necesarias.

¿ Cómo puedo evitar que otro equipo se haga cargo de mis proyectos ?

Aprendí por las malas que elegir las palabras es muy importante. En su caso, debe recordar que todos los proyectos son proyectos de la empresa, no suyos.