Hable con su gerente.

Esto es escalones por encima de ti. Has intentado ayudar al otro equipo. No han aprovechado la ayuda. Su capacidad para hacer cosas a través del otro equipo será limitada, y tratar de hablar con sus gerentes tiene muchas posibilidades de fracasar. No debe simplemente no hacer nada, porque la empresa podría beneficiarse significativamente de su código. Al mismo tiempo, juzgar la productividad del otro equipo (aunque sea con precisión) no es su trabajo. Todo esto se ha elevado a un nivel de política de oficina que está por encima de ti, y eso significa que es hora de pasar la responsabilidad al nivel político por encima de ti en la oficina.

Siéntese uno a uno con su gerente, explique la situación de la manera más simple y directa que pueda y, en la medida de lo posible , omita cualquier juicio sobre el otro equipo o su trabajo que no pueda respaldar directamente. evidencia fáctica. Luego deje que él (o ella) lo maneje (posiblemente escalando a su jefe).

Esto bien puede resultar en una tarea de una semana para convertir su código, y eso es ciertamente algo que puede ofrecer hacer en su conversación con su gerente, pero no es algo que deba hacer sin obtener el visto bueno a menos que generalmente le den una enorme margen de maniobra sobre qué tareas asumir.

No estoy de acuerdo con la respuesta de Ben aquí y digo que este es un problema que debe tratar de resolver acercándose al equipo en cuestión antes de seguir escalando.

Como usted es un usuario clave del código que están (supuestamente) escribiendo, está en condiciones de describir los impactos en cadena en sus entregables. Debe asegurarse de que sean 100% conscientes de estos impactos. En un mundo ideal, estarían de acuerdo en realizar las mejoras que desea, por lo que comenzaría describiendo los problemas por escrito y ofreciendo su ayuda para implementar estas mejoras. Un simple correo electrónico como el siguiente debería ser suficiente.

Hola [MIEMBRO DE OTRO EQUIPO],

Me acabo de enterar de los planes más recientes para implementar 'X' y me preocupan los efectos colaterales de la falta de funcionalidad 'Y'. Planeé usar 'Y' cuando llegue el momento de implementar la función 'Z' en mi final. La falta de esta función provocará retrasos en el producto final, ya que tendré que producir una solución alternativa.

También me preocupa que si 'X' no puede lograr un tiempo de ejecución de menos de 'N' segundos. Nos esforzaremos por alcanzar el objetivo de rendimiento 'T'. La implementación en 'Idioma original' logró un rendimiento de 'Na' segundos. ¿Hay alguna forma de mejorar este rendimiento? Estaría encantado de explicarle algunos de los métodos que utilicé para lograr este nivel de rendimiento en el "idioma original".

Si sería útil, ¿podríamos reunirnos para discutir más a fondo?

los mejores deseos, descartable

Una vez que hayan sido conscientes de las consecuencias de la falta de funciones o el bajo rendimiento, es de esperar que estén abiertos a revisar el plan; si no lo están, debe plantearlos como riesgos del proyecto a través de los canales habituales del proyecto. Si no tiene la autoridad para hacerlo usted mismo, debe escalar a su gerente para que tome medidas en su nombre.

Finalmente me haré eco del consejo de Ben de no juzgar el desempeño del otro equipo.

El otro equipo tiene la responsabilidad de considerar los costos de mantenimiento, así como la implementación inicial. Es posible que hayan considerado que su solución completa es más complicada de lo que realmente se necesita.

Si su objetivo es llegar a la X más simple posible en su idioma preferido, tendrían dos rutas: adaptar y desmontar su código, o construir desde cero. Eligieron el segundo enfoque. Si tenían razón o no, es su decisión, no la tuya.

Dicho esto, puede pedirle a su gerente que realice un seguimiento de las funciones y el estado para asegurarse de que entregarán la funcionalidad requerida en la fecha programada.