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.
¿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).'
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.
Daniel
usuario44108
rath
usuario15704
usuario15704
Donald
W máx.