¿Cómo manejo a un compañero de trabajo senior que rompe cosas en mi parte del proyecto y me culpan a mí?

Para el tema de que él niegue lo que acordaste, hazlo por escrito :

• Ponga cualquier reunión en sus dos calendarios o prográmelas por correo electrónico

• Tome notas durante la reunión y envíele un resumen de la reunión, por ejemplo:

  Como se discutió en nuestra reunión de hoy...

  Por favor, señale cualquiera de estos detalles que sean incorrectos.

Tanto para lo anterior como para lo siguiente, no confíe en la comunicación verbal, ya que es fácil de negar; es un buen punto de partida (ya que es más fácil aclarar las cosas rápidamente), pero debe hacerlo por escrito después.

Para el tema de él rompiendo cosas:

• Use el control de fuente : esto debería darle un registro de papel adecuado para respaldar su caso.

  • ... con pruebas automatizadas : las pruebas se realizan después de cada confirmación y se envían correos notificando a todos sobre las pruebas fallidas. Va a ser difícil para él echar la culpa si la prueba falla después de su compromiso. Si dice que "las pruebas introducen errores", esto es algo que deberías hacer retroceder, por ejemplo:

    ¿Puedes explicar qué quieres decir con esto? Las pruebas no cambian el código y, por lo tanto, no pueden introducir errores.

• Revertir sus cambios (si no lo arregla o al menos lo reconoce):

  Revertí el cambio X que comprometiste, ya que rompe Y, asegúrate de que las pruebas pasen antes de enviar cambios a nuestro control de código fuente.

• Señala sus errores graves : si no te consulta o no sigue lo que dijiste, envíale un correo como:

  Acabo de ver su cambio X. Esto no sigue lo que acordamos en nuestra reunión en la fecha Y debido a la razón Z. [Lo revertí / Lo arreglé / Por favor arréglenlo.] Por favor consulte nuestras notas de la reunión antes de hacer cambios en futuro.

• Gestión de CC en su caso.

• Si estos pasos no ayudan, hable con la gerencia para señalar instancias problemáticas específicas (con pruebas que lo respalden), mencione cómo ha tratado de resolver esto con su compañero de trabajo hasta el momento y pregúntele cómo le gustaría que lo manejara. este.

Recientemente, las cosas se han acelerado un poco cuando negó totalmente nuestra reunión 1-1 sobre los problemas que le planteé.

Una de las cosas que he aprendido de la manera difícil (y este es mi primer trabajo) es que las personas pueden y hacen flip-flop cuando están bajo presión. Así que es imperativo que te asegures de tener las cosas por escrito. Por ejemplo: envíele un correo electrónico solicitando una hora para programar una reunión en la que discuta los problemas y luego actualice los boletos de JIRA para reflejar lo mismo.

Por ejemplo,

Después de discutir el PROBLEMA-003 en nuestra reunión, decidimos manejarlo cambiando los datos enviados al backend. Anteriormente enviamos a fulano de tal y ahora estamos planeando enviar a fulano de tal.

Ahora lo que entiendo es:

1. Ha estado en la empresa más tiempo que tú.
2. No es un "tipo de front-end" y quiere entrometerse con el código.

Con este fin, lo que sugiero es tener un proceso en el lugar donde todo el código de interfaz que entra en la rama maestra se prueba por regresión antes del lanzamiento del cliente. Si aún no está allí, tendrá que implementar al menos un proceso muy rudimentario para su seguridad. Si se cambió el código y no lo hiciste tú, las confirmaciones de Git te salvarán. Ellos nunca mienten.

Además, debe asegurarse de que el error no esté en la parte delantera. ¿No se adhirió al contrato de la API, por ejemplo, o cambió sin que usted lo supiera? Asegúrese de que todo esto esté bien documentado y sin ambigüedades.