Cómo pedirle al líder del equipo que me avise si rompe o cambia algo

Somos un pequeño equipo que está a punto de lanzar un sitio web rediseñado que está pasando por un importante lavado de cara. Debido a la naturaleza del marco de tiempo, tengo menos carga de trabajo y mi Gerente quiere que pruebe las cosas para asegurarme de que todo esté bien. También tenemos un probador de tiempo completo. Mientras probaba, descubrí que hay algunos problemas que no estaban allí primero. Fueron el resultado de la negligencia de mi gerente u otro desarrollador, pero me corresponde a mí, ya que está relacionado con el front-end. Por ejemplo, estaba revisando el sitio web en el móvil y el menú no se carga pero en el escritorio sí. Esto significa que han hecho su trabajo para hacer que el menú sea dinámico, pero no lo otro y no me lo dijeron.

Con el tiempo mi equipo ha contaminado mi trabajo con todo lo que pueden tirar y ver qué pega porque creen que conocen bien mi trabajo.

Si no hago algo que se me asignó o me tomo un poco de tiempo, mi gerente rápidamente plantea el problema o hace que otros desarrolladores se sienten conmigo para completar la tarea.

Con un problema tan grande como que el menú no se carga en el dispositivo móvil, el director de TI asume que el tipo contratado como front-end (yo) no es bueno en su trabajo. En realidad, la persona que trabajaba en el menú no trabajaba en el móvil. Si el cambio es algo en back-end, el gerente se agita rápidamente hacia mí, preguntando por qué , y su memoria no es muy buena para mí.

Mi pregunta es, como subordinado, ¿cuánto derecho tengo para decirle a mi gerente que mi diseño estaba bien, pero después de que él u otro desarrollador trabajaron en él, se arruinó y que la persona adecuada debería arreglarlo?

El otro desarrollador eliminó rápidamente el historial de SVN, por lo que no se puede saber quién hizo qué hace un par de meses, por lo que es una guerra de palabras.

Si alguien aquí intentara eliminar parte del historial de versiones, ¡saldría por la puerta el mismo día!
Trate de salir de la mentalidad de etiquetar errores como causados ​​por 'negligencia'. Son bichos, la gente comete errores. Una vez que comienza a meterse en el juego de la culpa, comienza a afectar sus relaciones laborales con sus compañeros de trabajo.
Lo primero que debe hacer es asegurarse de que nadie más que un administrador pueda tocar el historial de SVN. Secundo la sugerencia de que debería ser expulsado por eso.
Me encantan los comentarios aquí, el colega es un imbécil. Reemplazó todos los archivos con archivos nuevos, luego me culpó a mí y cuando el gerente dijo que lo recuperara, es decir, revertir/restaurar, hizo algo donde nadie puede ver el historial antes de ese momento. el gerente no conocerá esa magia y solo él la sabe, por lo tanto, despedirlo no es una opción porque crea desorden y al gerente le encanta porque el 5% del trabajo, el 95% del desorden es mejor que nada. @SnarkShark No me refiero a error como negligencia. Me refería a ignorar el hecho de que esa parte también necesita trabajo y no hacerlo.
@JoeStrazzere sí, pero arruinan cosas que no están relacionadas con ellos, y si hago lo mismo, el gerente me está atacando.
"¿Cuánto derecho tengo para decirle a mi gerente que mi diseño estaba bien, pero después de que él u otro desarrollador trabajaron en él, se arruinó y que la persona adecuada debería arreglarlo?" - Ninguno. Si alguien a quien manejé me dijera esto, me aseguraría, ya no lo manejé.
El principal problema aquí parece ser el control de versiones. No puede probar de manera efectiva el software que cambia sobre la marcha.

Respuestas (2)

¿Tiene la tarea de realizar pruebas y durante sus pruebas encuentra errores? ... para eso está la prueba. Usted informa los errores y luego se pueden resolver. Jugar al juego de señalar con el dedo no es muy constructivo. Si está documentando correctamente, esto no debería preocuparle.

Me gano la vida solucionando problemas (no software). La forma profesional de manejarlo es hacer un informe sobre lo que no funciona correctamente, posibles líneas de investigación sobre cómo resolver los problemas y centrarse en las soluciones en lugar de culpar.

La gente no debería jugar con los controles de versión, pero ese no parece ser su rol. Ese es un problema en sí mismo y haría un informe al respecto de la siguiente manera sin hacer el juego de la culpa.

'Mientras investigaba la causa del problema X, descubrí que las versiones anteriores no están disponibles, lo que dificulta identificar la causa. Esto puede indicar un problema con el sistema de control de versiones o una manipulación deliberada. Avanzando, identifiqué XX y XY como las razones principales de la falla de YY cuando ocurre una situación de WW. etc,.... (luego trabaje hacia estrategias de resolución).'

Bueno, el gerente me mostró actitud cuando sangré el código mientras realizaba una tarea de prueba que era una mejora de UX, ya que no pudo averiguar qué agregué/eliminé debido a su falta de conocimiento y no se lo dije porque si una persona es grosero conmigo después de ofrecer ayuda en numerosas ocasiones, uno tiene que parar. Si pruebo correcciones y él tendrá el mismo comportamiento conmigo, sin sangrar/sangrar el código. Tendré que denunciar a su manager por su mal comportamiento.
Cómo tratar con un gerente en estas situaciones sería una pregunta muy diferente a la planteada. Pero denunciar a su gerente a alguien superior por herir sus sentimientos generalmente es una mala idea a menos que tenga alguna influencia/conexión con el superior. En este caso, es tanto su gerente como el líder de su equipo de los que desea quejarse. Tal queja podría fracasar muy mal. Hay otras estrategias que podrías usar.
¿Quieres editar la pregunta y proporcionar una mejor respuesta?
En realidad no, no conozco toda tu situación, si planteas la pregunta que quieres que te respondan, todos podemos intentar ayudarte. Editar la pregunta existente invalidaría todas las respuestas actuales, pero podría eliminarla y comenzar de nuevo.
@Nofel "El gerente me mostró una actitud cuando pretendía el código": para los cambios de estilo que no cambian la funcionalidad, considere realizar estos cambios por separado, por ejemplo, un viernes por la tarde. Y márquelos como "guiones fijos, etc."

Como el software es determinista y hay suficientes herramientas para rastrear cualquier cambio, esto debería ser realmente fácil de resolver.

No usar un sistema de este tipo (de una manera libre de manipulaciones) pone la carga de la prueba de fallas prácticamente en la empresa.

Tener errores que llegan a producción también apunta a otros problemas en los procesos. (Prueba y despliegue)

Comience a mejorar el proceso de su equipo para salir de tales situaciones en el futuro y entrar en un ambiente de trabajo constructivo.

Simplemente lo asumí porque "el problema tan grande como que el menú no se carga" no sería un gran problema si solo se descubriera en un entorno de prueba. Para eso están las pruebas, ¿no?
Lo siento, respondo preguntas aquí con el espíritu de lo que comprendo del texto del póster, tratando de que sea útil. Si sabe algo más o tiene una opinión diferente, no dude en publicar una respuesta usted mismo. Si encuentra que mi publicación es un mal consejo, no dude en votar negativamente.