Cometí un posible error en un proyecto en vivo en el trabajo, ¿cómo manejar este lío?

Tienes culpabilidad aquí, pero diría que no es del todo culpa tuya.

Por supuesto, como desarrollador, siempre debe probar su propio código antes de registrarse y NUNCA debe confiar en el control de calidad como plan de prueba. Esto es evidente.

Por otro lado, creo firmemente que también deberían asumir algo de culpa aquí:

1. No le comunicaron cuándo se iba a implementar el código en vivo/producción/cliente.

2. Un compañero no revisó los cambios de su código antes de pasar por el proceso de control de calidad. Esta debería ser una política obligatoria en su equipo, especialmente para los desarrolladores junior y nuevos del equipo.

3. Su equipo de control de calidad debería haber sido más minucioso antes de autorizar ciegamente el lanzamiento del software a producción.

No dejes que te culpen a ti, reconoce tus errores pero señala los otros puntos de falla que llevaron a la situación. Si su gerente y su empresa son un lugar en el que vale la pena trabajar, estarán más preocupados por resolver el problema que por castigar con la culpa.

Todos cometemos errores, cada uno de nosotros.

Definitivamente reconozca su error : esto es claramente su culpa, ya que no hizo las pruebas, y el hecho de que otras personas también hayan tenido la culpa no es una excusa. (Y en cualquier caso, tal vez no lo hicieron; ¡tal vez debería haber sabido que el sistema iba a estar activo el domingo y simplemente no revisó algún recurso importante para averiguarlo!)

Sin embargo, el otro paso importante es dejar en claro que esto no volverá a suceder , no prometiendo que no sucederá, sino explicando por qué sucedió y qué pasos tomará para evitarlo en el futuro y, si es necesario (que parece que lo es), pedir ayuda. Parece que te faltaba información importante: solicita pautas sobre cómo manejar las solicitudes de cambios de última hora, dónde verificar para asegurarte de qué se publicará cuándo, etc. Nuevamente, el objetivo de esto no es poner culpar a nadie más, sino averiguar exactamente lo que hizo mal o lo que debería haber sabido y todo lo que puede hacer para tomar mejores decisiones en el futuro. Con suerte, quedará claro que su error se debió a algo que se puede reparar fácilmente, y todos se sentirán razonablemente seguros de que no volverá a suceder.

El hecho de que usted sea nuevo en el trabajo puede jugar a su favor aquí: se espera que las personas nuevas cometan algunos errores y mejoren rápidamente . Si, después de trabajar allí durante un año, todavía no sabía lo suficiente para evitar causar este tipo de problema, claramente sería una señal de un problema importante, pero como no ha estado allí el tiempo suficiente para estar muy familiarizado con la forma en que funciona todo, las personas pueden sentir que se trata de un error de novato que es poco probable que se repita.

Nuevamente, este es realmente el punto más importante aquí, durante la reunión, deje en claro que su prioridad es evitar que el problema vuelva a ocurrir, no evitar culpar , y es posible que decidan que ese enfoque lo convierte en un empleado lo suficientemente bueno como para conservarlo.

Cometer un error como nuevo empleado es realmente estresante, pero dado que fue su primer error, es poco probable que lo despidan, ya que contratar nuevos empleados siempre implica una inversión que no querrán perder.

Sugeriría lo siguiente:

1. Recuerde SIEMPRE probar su código antes de implementarlo. Esta es una regla que nunca debes romper.

2. Averigüe cómo funciona el control de cambios y el ciclo de desarrollo en su empresa, es decir: ¿Se permiten solicitudes informales o deben especificarse y aprobarse antes del desarrollo? ¿Cuándo y quién implementa los cambios? ¿Cuándo y dónde se realizan las pruebas? Si no existe un proceso controlado, potencialmente puede ganar puntos al ayudarlos a implementarlo ;-) Si lo hay, su empleador debería haberle explicado este proceso claramente para evitar un error como este.

3. Descubre cuál es la línea de mando. ¿Quién tiene la autoridad para solicitar y aprobar cambios? Una vez que tenga la respuesta, NUNCA actúe sobre las solicitudes de cambio de una persona no autorizada sin consultar con la autoridad correspondiente.

4. No está claro en su publicación dónde implementó sus cambios. ¿Los implementó directamente en un servidor de producción? Es esencial tener un servidor de pruebas o de desarrollo donde los desarrolladores puedan probar su código antes de implementarlo en producción. Para prevenir mejor este tipo de errores, idealmente los desarrolladores no deberían tener acceso directo a los servidores de producción y el código probado debería implementarse en producción solo después de que Preguntas y respuestas lo haya aprobado. Esto debería ocurrir como parte de un proceso controlado de control de cambios.

Asumir la responsabilidad no significa solo reconocer su error, sino también participar en la implementación de procesos que hacen que las cosas funcionen mejor.

¡Buena suerte con la reunión!

Este proceso está seriamente roto y no es tu culpa . Es absurdo poner código en producción sin revisión de ningún tipo. Idealmente, se debe revisar el cambio y se debe ejecutar una prueba de regresión completa.

Si el tiempo es crítico, entonces el mínimo absoluto sería que dos desarrolladores acuerden la solución. En tales casos, la gerencia debe comprender que existe una posibilidad significativa (> 1 %) de que la corrección falle.

No recibió capacitación y no tiene autoridad sobre el código que está en producción o el proceso de implementación. Nunca asuma la responsabilidad cuando no tiene autoridad. Explique lo que se le pidió que hiciera y cómo respondió. Una respuesta racional por parte de la gerencia sería analizar el incidente y luego modificar el proceso para evitar que ocurra en el futuro. Cualquier otra cosa es irracional. No te quedes en organizaciones irracionales.

Tuve que regresar y releer esto para asegurarme de que lo interpreté correctamente. También voy a hacer algunas inferencias.

El viernes, cuando estaba a punto de salir del trabajo, un compañero de trabajo me detuvo y me dijo que hiciera cambios en el código que ya funcionaba.

No me informaron del hecho de que este proyecto en vivo sería utilizado durante el fin de semana por un cliente real en un entorno de producción.

Entonces, básicamente, se le asignó una tarea sin una fecha límite explícitamente establecida y, sin saber que su registro terminaría como parte de un lanzamiento de producción, ¿la completó parcialmente el viernes con la intención de terminar después del fin de semana? Como buen desarrollador, antes de irse el fin de semana, verificó su progreso en caso de que el equipo de limpieza arrojara un cubo de trapeador en su computadora. Realmente no parece que hayas hecho nada malo per se, excepto que tu código terminó como parte de un lanzamiento de producción. Tal vez el desarrollador senior no pensó que te quedarías para trabajar en el código, por lo que nunca se molestaron en informarte sobre el lanzamiento (suposición peligrosa).

Entonces, operando bajo los pretextos anteriores, así es como lo abordaría.

Sea fáctico y objetivo

Tu mensaje inicial ya es defensivo. "Bueno, nadie me lo dijo, y QA normalmente prueba, y... y... y..." A nadie le importa. Cíñete a los hechos. "Me pidieron que trabajara en XYZ justo antes de irme. No sabía que había un lanzamiento de producción este fin de semana y que se incluiría el código. Verifiqué algunos de mis cambios antes de irme el fin de semana, así que no No perdían trabajo, pero no estaban completos ni totalmente probados".

Acepte la responsabilidad y pregúntese cómo podría haberlo hecho mejor.

La responsabilidad no es lo mismo que la culpa. Admita que revisó el código bajo suposiciones falsas y que causó un problema. Luego, en lugar de defender sus acciones, concéntrese en algo mucho más productivo... descubrir cómo puede evitar que vuelva a suceder. "Si vuelvo a encontrarme con esta situación, ¿sería mejor si revisé mi código como un estante o no lo revisé en absoluto hasta que sentí que estaba listo para la producción? ¿Tenemos una rama de control de fuente separada que debería estar usando para registros parciales para que no terminen accidentalmente en un lanzamiento de producción?"

Escucha las respuestas

Es sorprendente que tenga que decir esto, pero escuche lo que los desarrolladores senior y los gerentes de proyecto le sugieren que haga para evitar el problema. Las personas generalmente estarán mucho más dispuestas a ayudar a alguien que saben que es interesante para escuchar y aprender.

Este no es el lugar para criticar procesos.

Sería totalmente improductivo entrar a la reunión y decir: "Bueno, si nuestra estrategia de ramificación fuera mejor, y hubiéramos seguido nuestros procesos estándar, y..." Esto simplemente parece culpar. Me parece que HAY un problema con el proceso (teniendo en cuenta que el código no probado/no aprobado se lanzó a producción), pero hay un momento y un lugar para plantear estas sugerencias. El sistema actualmente implementado funciona al menos mínimamente, y aunque un mejor sistema podría haber evitado el problema, intente comprender completamente el sistema actual antes de señalarlo con el dedo.

Ten compasión de ti mismo

Eres el nuevo desarrollador. Cometiste un error. Todos lo hemos hecho y seguiremos haciéndolo de vez en cuando porque somos humanos. A lo largo de los años, he descubierto que, a menos que hagas algo completamente negligente e incompetente, los errores generalmente no terminan con tu carrera. Puede optar por gastar su energía castigándose por ello, defendiendo sus acciones o haciendo las cosas bien y averiguando cómo hacerlo mejor en el futuro. La mayoría de la gente respetará a una persona que diga: "Sí, me equivoqué. Me gustaría arreglarlo y estoy dispuesto a escuchar".

¿Cómo entró el código en producción? Las cuentas de desarrollador no deben tener acceso para implementar código en producción. Cualquier sistema que dependa de que los desarrolladores utilicen su buen juicio solo será tan bueno como el peor juicio. Si hay una consecuencia grave por interrumpir la producción (y parece que la hubo), entonces debería haber un sistema serio para garantizar que se apruebe cada lanzamiento. No solo un proceso que siguen las personas, sino privilegios de cuenta que requieren que la persona adecuada apruebe el cambio. No debería poder implementar código incorrecto en producción, incluso si quisiera. Si puede, entonces el problema final es que su sistema está roto.

Estoy de acuerdo con mucho de lo que otros han dicho y no tiene sentido repetirlo. Solo algunos comentarios adicionales:

Ciertamente deberías admitir tus errores. Evite seguir tal admisión con un "pero" seguido de cualquier cosa que suene como lloriqueo o culpar a otros. Dicho esto, no aceptes la culpa de lo que no es culpa tuya. Evite dar nombres a menos que lo presionen. Como en este caso, podría decir: "Me dijeron que hiciera tal y tal cambio" sin decir quién me lo dijo. Claro, si el jefe no lo sabe, lo descubrirá o preguntará tarde o temprano, pero evita sonar como si estuvieras tratando de culpar a los demás si lo haces bien.

Según su publicación, me parece que estaba confundido acerca de los procedimientos para asignar trabajo a la biblioteca con su empresa, o que la empresa tiene un control deficiente de esto. ¿Normalmente solo se compromete con la biblioteca después de que el control de calidad haya aprobado los cambios? Si no es así, ¿cómo sabe la persona responsable de la implementación en producción cuándo están listos los cambios? Si la respuesta es: "Bueno, se supone que deben saber, ya sabes", entonces hay un problema.

Si le dijeron los procedimientos y no los siguió porque tenía prisa por irse a casa o lo que sea, eso es culpa suya. Si siguió los procedimientos pero alguien más se desplegó prematuramente porque no estaba prestando atención, no es culpa suya en absoluto. Si la empresa no tiene una forma clara de saber qué se debe implementar y qué no, ese es el problema de la empresa.

Algunas personas han hecho comentarios sobre las revisiones por pares y la aprobación de control de calidad. Eso por supuesto depende de la empresa. En una empresa pequeña puede que no haya revisiones por pares o personal de control de calidad. En mi trabajo anterior, luché durante mucho tiempo para tener un departamento de control de calidad real, en lugar de las pruebas aleatorias que estaba haciendo la empresa.

Pero en cualquier caso, en qué momento te comprometes con la biblioteca depende de los procedimientos de la empresa. En cualquier lugar en el que he trabajado, el programador prueba en su escritorio y luego, cuando está satisfecho, se compromete con la biblioteca. A partir de ahí, se compromete a las regiones donde QA y/o el usuario pueden probar. Por lo tanto, no necesariamente puede decir, no se comprometa hasta que pase el control de calidad. En mi humilde opinión, tiene sentido implementar en la región de control de calidad desde la biblioteca, por lo que debe estar en la biblioteca antes de que podamos realizar el control de calidad. Pero lo que es una buena política no es la pregunta inmediata. La pregunta es cuál es la política de su empresa y si la siguió.

Si hubiera sabido que esto se ejecutaría el domingo en vivo, habría probado el código.

Este es tu primer error. ¿Por qué hay una condición previa para que pruebes tu código? Siempre debe probar su código y nunca confiar en el control de calidad para que lo cubra. Ese no es el trabajo de QA.

Hagas lo que hagas, no digas nada de lo que escribiste aquí en tu reunión. Esto es 100% culpa tuya y lo único que puedes hacer es asumirlo al 100%. Digamos que lo rompió, que no lo probó y que está buscando activamente formas de realizar pruebas unitarias y de integración para que esto no vuelva a suceder.

Aquí hay otra forma de ver las cosas. Una de las grandes cosas por las que los ingenieros civiles solían afligir a los ingenieros de software es la responsabilidad y la falta de licencias. Si un ingeniero civil comete un error mientras construye un puente y alguien muere mientras conduce sobre él, ese ingeniero es responsable de ese error. ¿Te imaginas si saliera en las noticias y dijera: "Mi compañero de trabajo no me dijo que los autos pasarían por encima durante el fin de semana".

Si bien el software Live puede no ser literalmente de vida o muerte, para algunas empresas, la interrupción del sistema Live puede estar muy cerca de sentirlo.