TLDR: Empujé la funcionalidad (rota) sin aprobación que terminó siendo detectada por el control de calidad, y mi jefe está (con razón) molesto. ¿Qué tengo que hacer?
Trabajo como desarrollador en un producto digital.
Recientemente, dentro de un plazo ajustado, enviamos una compilación para que la revisara nuestro equipo de control de calidad, y anoche recibió un informe de que encontraron un error en el producto. Este error fue una funcionalidad que agregué, sin aprobación, como prueba para una versión futura del producto.
Había puesto esta funcionalidad detrás de una especie de código de acceso que debía ingresarse interactuando con un elemento del producto en una secuencia determinada, con la suposición de mi parte de que solo yo podría activarlo, y nadie más lo haría. Míralo. Más tarde me di cuenta de que el código que introduje inicialmente activaría la funcionalidad no aprobada incluso si la secuencia se incluyera en una secuencia más grande, lo que significa que una serie de interacciones aleatorias tendrían la posibilidad de activar la funcionalidad (aunque pensé que sería raro ). Hice una solución para permitir solo la secuencia precisa, pero ese código no se incluyó en la compilación enviada.
Unos días después de eso (ayer), después de que QA probara el producto, activaron accidentalmente la secuencia e informaron la funcionalidad resultante como un error. Mi jefe se lo mostró a nuestro director creativo, quien también pudo activar la funcionalidad. Luego habló conmigo sobre el asunto esta mañana.
Cuando mi jefe habló conmigo sobre esto, expresó varias preocupaciones:
Además de lo anterior, dijo que ahora tendría que hablar con su propio jefe para decidir qué harían al respecto. Resultó que se acercó a mí poco después y me preguntó si podría hacer el cambio de código más pequeño posible para eliminar la funcionalidad, posiblemente pudiendo omitir un barrido de control de calidad completo y salvar nuestra ventana de lanzamiento. Inmediatamente presioné un cambio de una línea que eliminó la funcionalidad, mostrándole el código que cambié para hacerlo. Me dio las gracias, pero no he hablado con él desde (hoy temprano).
Aunque ahora me doy cuenta del error en mi juicio, en ese momento mis acciones fueron informadas por este pensamiento: Desafortunadamente, muchas veces mi jefe y director verán una característica parcialmente completada (por mí mismo o por otro desarrollador) o escucharán una idea descrita verbalmente, y rechazar la característica o funcionalidad, debido a lo que siento es una falta de visión de lo que podría ser una característica en su forma final. Cuando, en cambio, he adoptado el enfoque de presentarles algo más pulido, casi siempre lo aprueban. Recientemente discutimos una función como la que está en cuestión, por lo que dediqué una hora de trabajo para obtener la funcionalidad aproximada, para usar como demostración. Pensé que con mi muro de "contraseña", nadie lo vería accidentalmente.
Ahora me doy cuenta de lo grave que esto podría ser. En el pasado, aunque trabajé en las cosas para pensar que podía demostrar su valor, siempre mostré las cosas en las que trabajé y las presenté para su aprobación final, mucho antes de la construcción final. Me doy cuenta de que me pasé de la raya al permitir que algo saliera en vivo, incluso si pensaba que estaba evitando que alguien lo viera accidentalmente.
Creo que esto podría ser algo por lo que mi jefe podría despedirme. Aunque soy uno de los mejores en el equipo, podría ser que esta ruptura de confianza sea suficiente para justificar mi despido.
No quiero perder este trabajo. Disfruto mi trabajo, es desafiante y creativo, y estoy agradecido por el salario y la flexibilidad. Le envié un mensaje a mi jefe disculpándome, diciendo que me doy cuenta de la gravedad de mis acciones y que rompí la confianza y que nunca volveré a hacer algo similar, saliendo de las especificaciones sin aprobación, etc. Todavía no ha respondido.
¡Cualquier consejo sobre qué hacer en este punto sería muy apreciado! Gracias por adelantado.
En el futuro, cuando trabaje en cosas como esta, verifíquelo en una rama en lugar del maestro. O opte por la baja tecnología y guárdelo en otro lugar de su disco duro personal. A menos que esté en una crisis, el problema no fue el tiempo invertido, sino el riesgo de que algo desconocido, no probado y potencialmente rompa.
Qué hacer: habla con tu jefe. Explícale que entiendes que lo que hiciste estuvo mal. Dile por qué, para que sepa que lo entiendes. Proponga un proceso para asegurarse de que nunca vuelva a suceder (el proceso consiste en revisiones de código. Con las revisiones de código, esto nunca se aprobaría. A menos que tenga revisiones de código y las eluda, en cuyo caso la respuesta es un bloqueo técnico que impide fusiones para dominar a menos que su ha sido revisado, y en ese caso estás en una mierda mucho más profunda, porque eludir la revisión del código parece sombrío). Y acepta que vas a estar en la caseta del perro por un tiempo.
La cantidad de problemas en los que se encuentre depende de cuál sea su trabajo y cuál fue la funcionalidad. Si trabajas en algo como defensa, banca, etc., estás acabado. Si crea un sitio web y su código no tiene nada que ver con el acceso a las cuentas o la información de pago de otras personas, es probable que esté bien. No hay suficiente información para contar aquí.
Lo que hiciste estuvo mal, de hecho iría tan lejos como para decir espantoso , pero estoy seguro de que no necesitas que te lo diga. Y ciertamente no necesita que un aleatorio de Internet lo intente.
Más o menos manténgase en la línea que ya ha estado siguiendo:
Pida disculpas sin reservas, explique que entiende que lo que hizo estuvo mal y que sabe por qué. Y, quizás lo más importante, enfatice que esto nunca volverá a suceder.
No intentes justificar lo que hiciste. Usar la iniciativa y esbozar PoC para demostrar ideas no es algo malo en sí mismo, y siempre he alentado a los desarrolladores que trabajan para mí a que hagan precisamente eso. Pero cuando está trabajando con una fecha límite de lanzamiento apretada no es el momento y enviarlo a la compilación para la vida definitivamente no es el lugar e intentar explicarme su pensamiento en ese sentido (si yo fuera su gerente) en este caso simplemente irritarme más.
No intente difundir ninguna culpa. Como han señalado otras respuestas, esto destaca una posible debilidad en el proceso de revisión del código de su organización y no digo que estén equivocados, pero usted no es la persona que se lo dice en este momento. Si lo hace, solo parecería que dice "No debería haber sido capaz de cometer este 'crimen', debería haberme atrapado", lo cual es inmaduro en el mejor de los casos y culpar a la víctima en el peor.
Discúlpese también con el equipo de control de calidad, no solo les hizo perder el tiempo, sino que estaba intentando pasarles algo que es fundamentalmente deshonesto. ¡Se supone que debes estar en el mismo "lado"!
Suponiendo que el cronograma de lanzamiento se pueda salvar sin un costo demasiado significativo para el negocio y que su historial sea muy bueno con este incidente fuera de lugar, entonces podría sobrevivir, pero espero que le tome bastante tiempo ser más blanco que blanco. para reconstruir la confianza de la organización en usted. ¡Buena suerte!
Bueno, ha aprendido por las malas que siempre necesita buscar consejo antes de incluir una funcionalidad.
Lo primero será contárselo a tu jefe, para demostrar que comprendes perfectamente la gravedad del asunto y que no lo volverás a hacer. Admitir abiertamente un error es algo realmente profesional.
Siguiente paso, recuperar la confianza de su jefe. Es posible que tengas que pasar desapercibido por un tiempo. Pero luego puedes demostrarle que su opinión importa, pedirle consejo, incluso para decisiones que no son tan grandes como poner en producción una nueva funcionalidad.
Te equivocaste, sabes por qué, sé paciente y bueno en tu trabajo y deberías ser bueno.
Mensaje para su jefe: Jefe, su proceso de revisión de código está totalmente roto. Sus procesos deben configurarse de modo que un desarrollador no pueda agregar código que se agregará a la producción sin que otro desarrollador revise y acepte el código mismo. Así que es tu culpa tanto como la culpa del desarrollador.
Mensaje para ti: No es así como funciona. No puedes seguir adelante y hacer las cosas por tu cuenta. Si tienes una idea, acude a tu jefe y cuéntaselo. Y si es una buena idea, él o ella te ordenará que la implementes, y todo está bien. Pero debe darse cuenta de que lo que usted piensa que es una buena idea y lo que la empresa piensa que es una buena idea pueden ser muy diferentes. La primera pregunta que debe hacerse para cada idea es: ¿Ganaremos más dinero? ¿Venderemos más productos? ¿Los clientes estarán más contentos y nos darán mejores críticas? Por otro lado: ¿Necesitaremos tener documentación? ¿Creará problemas para el soporte? ¿Hará que el desarrollo futuro sea más difícil? Eso es todo lo que su jefe consideraría. No es tu trabajo considerar estas cosas, pero tienes que hablar con tu jefe.
La buena noticia: esto no es algo por lo que normalmente te despedirían. Se detectó el problema, no se produjo ningún daño (tuviste suerte allí, cómprale una cerveza al probador cuando tengas la oportunidad). Este fue un momento educativo para ti. Es muy posible que su jefe sea más duro con usted de lo necesario para mejorar la parte educativa de este palo, sin ninguna consecuencia real para su carrera. Si esto hubiera llegado a los clientes, sería diferente.
@Lilienthal: Si se le dice al jefe que su proceso de desarrollo, del cual es responsable, no funciona, nunca se trata de un consejo oportuno.
Primero, las malas noticias: Actuaste muy tonta e impulsivamente.
Ya lo sabes, no hace falta decir nada más.
Ahora, las buenas noticias: probablemente no serás despedido.
Dale unos días, discúlpate y detalla a tu jefe lo siguiente
Si yo fuera su jefe, probablemente no lo despediría, pero lo vigilaría de cerca en el futuro previsible. Probablemente también me reiría un poco cuando se calmara el polvo, luego pensaría en cómo canalizar tu creatividad.
Los programadores son muy traviesos, y eso es de conocimiento bastante común, por lo que lo que hiciste no estuvo completamente fuera del ámbito de las expectativas. Desafortunadamente, los tiempos han cambiado y estas travesuras están mal vistas en estos días.
Reconstruya la confianza de su gerente y, en el futuro, aprenda a abogar por sus cambios/características. Sea capaz de cuantificar lo que está impulsando y siga los procedimientos descritos. Demuestre en una demostración, pero nunca intente colar nada en producción nuevamente.
Primero que nada: respirar
Vamos a desenrollar la cadena de eventos:
Creo que esto podría ser algo por lo que mi jefe podría despedirme. Aunque soy uno de los mejores en el equipo, podría ser que esta ruptura de confianza sea suficiente para justificar mi despido.
Podría conducir a su despido, pero no lo ha hecho . De hecho, te dio la oportunidad de rectificar tu error a corto plazo. Incluso te dio comentarios positivos.
Además de lo anterior, dijo que ahora tendría que hablar con su propio jefe para decidir qué harían al respecto. Resultó que se acercó a mí poco después y me preguntó si podría hacer el cambio de código más pequeño posible para eliminar la funcionalidad, posiblemente pudiendo omitir un barrido de control de calidad completo y salvar nuestra ventana de lanzamiento. Inmediatamente presioné un cambio de una línea que eliminó la funcionalidad, mostrándole el código que cambié para hacerlo. Me dio las gracias , pero no he hablado con él desde (hoy temprano).
Una pequeña nota técnica al margen:
Pensé que con mi muro de "contraseña", nadie lo vería accidentalmente.
Mire el cambio de función adecuado . Muchos frameworks lo soportan. Ejecutado correctamente, esto lo ayudará a deshabilitar rápidamente las funciones de errores en vivo mientras soluciona el problema subyacente y este error podría ser un punto de inflexión para su equipo de software.
Desafortunadamente, muchas veces mi jefe y director ven una característica parcialmente completada (por mí mismo o por otro desarrollador) o escuchan una idea descrita verbalmente y rechazan la característica o funcionalidad, debido a lo que siento que es una falta de visión de lo que es una característica. podría estar en su forma final. Cuando, en cambio, he adoptado el enfoque de presentarles algo más pulido, casi siempre lo aprueban. Recientemente discutimos una función como la que está en cuestión, por lo que dediqué una hora de trabajo para obtener la funcionalidad aproximada, para usar como demostración.
Esto de aquí es una de mis mayores debilidades (no completar las ideas con la suficiente frecuencia). Reconoce esta debilidad y descubre cómo combatirla. Oblígate a no trabajar en cosas nuevas y emocionantes hasta que hayas trabajado en una cierta cantidad de problemas sin terminar.
Por último, pide una reunión con tu jefe y dile que te gustaría hablar. Luego, establezca cómo va a trabajar para no repetir este tipo de error. Haga una lista de puntos de acción (por ejemplo): - analice la alternancia de funciones - analice cómo completar el trabajo sobre los problemas antes de enviarlo - Recuerde hablar también sobre sus sentimientos (inseguridad sobre su trabajo). Cualquier persona buena y comprensiva (supongo que tu jefe lo es) seguramente no te hará responsable por sentirte inseguro después de cometer un error.
¡Buena suerte!
erik
usuario34587
curt1893
steve-o
Chris E.
Stephan Branczyk
lvella