Parece confundir dos cosas:

• Trabajan cualquier cantidad de horas para resolver problemas inesperados o no planificados.

• Ellos son responsables y brindan un trabajo de calidad de una manera predecible.

La propiedad no se trata de que el equipo trabaje toda la noche para cumplir sus promesas a los clientes. La propiedad se trata de saber qué hay en el código, cómo funciona, tener un plan y poder decirte cómo y cuándo se harán las cosas. La propiedad es que los desarrolladores tomen las decisiones correctas para que el código funcione correctamente no solo esta noche, sino en los años venideros.

Lo siento si esto es un poco difícil, pero muchos gerentes me han dicho variaciones. tu publicación. La mayoría de las veces se reduce a:

• falta de mandato claro
• requisitos cambiantes
• enfoque a corto plazo
• urgencia constante

¿Podría explicar en la pregunta qué hizo usted, como gerente, para preparar esos comunicados, empoderar a su equipo y cómo escuchó sus comentarios? Entonces podemos hablar de propiedad.

Incluso cuando le dije que lo necesitaba ahora, dijo que tenía algo más que hacer y se escapó cuando yo no estaba allí.

Hoy, hay un error crítico y este senior El chico dijo lo mismo otra vez: "Hoy no puedo terminar. Tengo una reunión con amigos y tengo que irme". luego se escabulló mientras yo hablaba con mi gerente.

En ambos ejemplos, te refieres a él como que se escapó, pero con tus propias palabras te dijo que no estaba iba a hacer este trabajo y luego no lo hizo. Escapar implica que está siendo engañoso o deshonesto, pero parece que está siendo transparente, y debes reconocerlo. He trabajado con personas que dicen que manejarán las cosas y luego desaparecerán, y esas personas merecen ser despedidas. Alguien que le informa sobre su ancho de banda y luego lo sigue es completamente diferente. La integridad de esta persona no es un problema; solo está desempleado si sus resultados no son suficientes.

La semana pasada, les dije en una reunión de equipo que esperaba un mayor nivel de propiedad. Si prometen algo, deberían hacerlo. Si hay un error crítico, deben solucionarlo incluso si tienen que quedarse hasta tarde.

Esta es una declaración razonable y un nivel de propiedad que los ingenieros senior generalmente deberían aceptar con algunas advertencias:

1. Los errores críticos deben ser realmente críticos. Por ejemplo, en mi propia carrera me he quedado hasta tarde para corregir errores "críticos" que luego no se implementaron en producción durante dos meses. En esos casos, era un gerente que se asustaba por algo y lo quería ahora en lugar de un error crítico. Por supuesto, también ha habido problemas realmente críticos.
2. Los niveles de personal deben ser generalmente suficientes. Cumplir con las fechas de publicación y solucionar los problemas es importante, pero si siempre llegamos tarde porque tenemos a 3 personas haciendo el trabajo de más de 4 personas, esa es una situación diferente.

¿Existe una forma alternativa para hacer frente a problemas como este?

Algunas metodologías de desarrollo tienen formas integradas de gestionar estos problemas. En el desarrollo ágil, por ejemplo, los sprints son formas de prometer qué trabajo se entregará. También incluye formas integradas de medir la velocidad (la cantidad de trabajo que se realiza) y, por lo general, va junto con el software (creo que JIRA es el más popular) que determina si un equipo o individuos están logrando o no esos objetivos. En el desarrollo ágil, si necesita cambiar el rumbo a mitad de carrera, como tomarse el tiempo para corregir un error crítico, refleja que está cambiando el alcance inherentemente. Normalmente, sacas cosas para agregar lo que sea que se deba agregar. Este proceso hace que sea realmente fácil evaluar si "no puedo hacerlo hoy" es porque está trabajando duro en otros objetivos importantes o porque simplemente está siendo difícil.

En mi opinión, es un método fantástico para desarrollo de software que, lamentablemente, casi nunca se realiza correctamente.

ACTUALIZACIÓN : en respuesta a las ediciones de las preguntas, este error es de naturaleza absolutamente crítica (en la mayoría de las empresas se llamaría showstopper en lugar de crítico) y debe repararse de inmediato. Seguiría la técnica que describí anteriormente: quitar cosas de su plato a cambio de que él trabaje en ello ahora.

Parece que este proyecto ha sido un desastre y muy estresante para todos los involucrados, pero un error eso hace que el 90% de los usuarios no puedan iniciar sesión y valga la pena quedarse hasta tarde. Debe evaluar si este empleado se ha retirado por completo o no (en cuyo caso debe ayudarlo a cambiar a otro empleo) o si el proyecto lo ha agotado y necesita un descanso.

En mi oficina, solemos citar lo siguiente:

"Una mala planificación de su parte no requiere una emergencia en la mía".

En mi experiencia, los desarrolladores a menudo están motivados para ayudar con un problema que apareció debido a un error de su lado o algo imprevisto.

Pero a menudo surgen problemas que no solo no son sorprendentes Antes de decidir darle un ultimátum a su desarrollador y hacer que busque un nuevo trabajo, debe preguntarse lo siguiente:

• ¿Ha hecho lo suficiente para evitar "críticas "bichos en primer lugar? ¿Les dio a los desarrolladores el tiempo suficiente para implementar pruebas, revisiones de código, refactorizaciones y monitoreo?

• ¿Se está asegurando de que las nuevas funciones se activen cuando haya tiempo suficiente para corregirlas? (a diferencia de tarde en la noche o un viernes).

• Si los errores críticos son comunes, ¿está pagando lo suficiente por horas extras o servicio de guardia?

• ¿Los desarrolladores que desea tener la propiedad "son dueños" del proceso de lanzamiento? ¿Podrían detener el lanzamiento de una función, si creen que tiene errores?

• ¿Son sus plazos realistas y acordados con el equipo de desarrollo?

Si todas las preguntas se pueden responder con un "sí" claro, entonces es posible que deba despedir a su desarrollador senior.

Si alguna de las respuestas es "No" o "No estoy seguro", entonces comenzaría a buscar el problema en la administración y solucionaría estos problemas primero.

Afirmas que el equipo no tiene propiedad . Todo lo que construyen sus desarrolladores es propiedad de la empresa, no de ellos. Cuando dice que sus empleados deben "ser dueños" de los resultados de su trabajo, ¿significa también que recibirán las ganancias que esos resultados generen para la empresa? Si no significa eso, realmente no son dueños del trabajo y no puedes pedirles la propiedad.

Si hay un error crítico, deben solucionarlo incluso si lo han hecho. para quedarse hasta tarde.

Su solución para solucionar problemas críticos haciendo que su gente se quede hasta tarde es conveniente para la empresa y los empleados pagan el precio. Nuevamente, eso estaría bien si también obtienen una parte de las ganancias. ¿Lo hacen?

En este ejemplo en particular, el error evita que el 90% de los usuarios inicien sesión en el sistema. En promedio, esto sucede una vez al mes este año, mientras que sucedió dos veces el año pasado.

Cuando esto sucede con tanta frecuencia y no instala procedimientos organizativos para reducir el impacto de esos errores, ¿Es usted como organización la culpable?

En realidad, su enfoque actual para solucionar problemas "críticos" y su contemplación de despedir a su empleado podrían considerarse un signo de una organización disfuncional. El comportamiento de su empleado podría ser su forma de reaccionar ante eso. Su actualización de la pregunta original con una lista de lo que cree que está haciendo bien (en lugar de pensar en lo que podría estar haciendo mal ) también muestra que podría tener una problema al aceptar que usted, como gerente, es parte del problema.

Hay muchas cosas que la administración puede hacer para mejorar la calidad y reducir la urgencia antes de pedirles a los empleados que se queden hasta tarde:

1. No importa lo bien que crea que se ha centrado en la calidad, los resultados muestran que no es así. Tiene que mejorar seriamente la calidad de su proceso de desarrollo, lo que podría significar medidas como revisiones, inspecciones, programación de pares, aumento de pruebas, rediseño de componentes críticos, arquitectura y diseño mejorados, etc. Será mejor que comience a analizar los problemas organizacionales que causan esos problemas. de escribir la lista de medidas que ya ha implementado. Obviamente, no están funcionando.
2. ¿Por qué su empleado tiene que quedarse hasta tarde para corregir el error? ¿Puedes hacer tus lanzamientos temprano en la mañana para darles a tus desarrolladores todo el día de trabajo para solucionar problemas?
3. ¿Has pensado en usar funciones alternas u otras medidas para volver rápidamente a la versión anterior de la función y ofrecer ¿Tiene tiempo de su equipo para solucionar el problema?
4. No puede culpar a sus empleados por tener planes para la noche cuando surgen problemas con poca antelación. Puede instalar un sistema de servicio en espera los días de lanzamientos críticos. Entonces las personas saben de antemano que es posible que tengan que quedarse hasta tarde y pueden prepararse en consecuencia.

Trabajar en software es muy común.

Tratas a tu gente como profesionales. Estás hablando de propiedad, pero luego dices demandas de que un error 'crítico' debe arreglarse AHORA.

¿El error es realmente 'crítico'? ¿Es el resultado de requisitos poco claros? Nuestro viejo amigo 'scope-creep '?

En cada uno de estos, usted (como gerente) necesita manejar las expectativas. No todos los errores son "críticos". Los requisitos pueden apestar. Cambios en el alcance del proyecto.

En lugar de exigir que lo abandonen todo por algo "crítico", trabaje con sus equipos hasta que se solucione. Entonces manténgalos en esta estimación.

He estado poniendo 'crítico' entre comillas porque después de más de 30 años en este campo (¡ay, soy viejo) este término se usa muy mal. No todo puede ser 'crítico'.

Con la pregunta actualizada, ahora está claro que está intentando solucionar el problema incorrecto. El comportamiento del ingeniero senior es un síntoma de un proceso de desarrollo de software fundamentalmente roto y / o una empresa disfuncional.

Si tiene errores críticos que entran en producción todos los meses, entonces tiene al menos uno de los siguientes problemas:

• Ingenieros incompetentes
• Base de código no mantenible
• Pruebas inadecuadas

Dada la cantidad de mano de obra que tiene a su disposición (20 ingenieros son MUCHOS recursos), es probable que sea una combinación de los tres.

Mi conjetura es que el ingeniero senior está harto de la constante lucha contra incendios, y con razón.

Debe profundizar más y solucionar los problemas subyacentes que crean la necesidad de que las personas trabajen continuamente hasta tarde. Convencer a un ingeniero de que trabaje hasta tarde más a menudo no ayudará a la imagen general.

Ahora, qué hacer al respecto ...

Paso 1: Descubra por qué probar no es detectar estos errores críticos

Lo primero que debe hacer es evitar que estos errores críticos lleguen a producción. Cada error que llega a producción es una falla en el proceso de prueba.

Repase cada error crítico que se descubrió en producción y determine exactamente por qué no se detectó en las pruebas. Agregue más cobertura de prueba automatizada, cobertura de prueba manual o recursos de prueba según sea necesario.

Paso 2: Determine la causa raíz de cada error crítico

Para cada error crítico, averigüe:

• Quién creó el error
• Cuándo se creó el error
• Por qué se estaba modificando el código
• Dónde se introdujo el error en el código

Al hacer este análisis, descubrirá algunos patrones. Quizás hay uno o dos desarrolladores que siguen introduciendo estos errores. Quizás hay un módulo de código que es muy difícil de modificar sin causar problemas. O es posible que el código en su conjunto sea muy difícil de manejar.

Quiero hacer un punto adicional. Apresurar una corrección de errores a menudo conduce a una deuda técnica. Si su desarrollador senior se pregunta cómo se probará esta noche, ¡esa es una buena pregunta que debería hacer un desarrollador senior! He trabajado en lugares donde se prioriza la urgencia sobre la calidad y esto ha tenido consecuencias negativas a largo plazo. En última instancia, su equipo tendrá una capacidad reducida porque siempre está combatiendo incendios.

Parece que tiene un gran problema de prueba. Usted pregunta por qué no todos abandonan todos los compromisos externos de apagar un incendio, pero la verdadera pregunta es ¿por qué comienzan los incendios todos los meses?

¿Tiene algún control de calidad / prueba? ¿Por qué no encontraron que el primer y más básico paso (iniciar sesión) no funciona? ¿Cómo se envió a producción algo que no funciona?

Además, ¿por qué su respuesta a que los usuarios no pueden iniciar sesión para que todos se queden hasta tarde apresurando arreglos "críticos" en lugar de tener un sistema? admin revertir la actualización y la actualización se puede intentar de nuevo más tarde después de que se hayan solucionado los problemas.

"¿Cómo vamos a probar eso esta noche?" Ésta es la respuesta correcta. Cuando hay un problema crítico y se le presiona para que lo solucione ahora mismo, ¿cómo reservarán los desarrolladores tiempo para revisar adecuadamente que los cambios sean correctos / de alta calidad y cómo se pretende QA para verificar que todo lo demás sigue funcionando después del cambio? Parece que también está pidiendo estos cambios al final del día, cuando todos están cansados ​​y su capacidad de pensamiento está en su punto más bajo, lo que hace que sea aún más probable que otros problemas se filtren en esta solución crítica.

¿Cuándo las personas son más productivas? ¿Cuándo es el equipo más capaz de manejar errores críticos? Se han realizado estudios que responden a dichas preguntas sobre cuándo los humanos son más capaces de manejar ciertas tareas.

Tienes un error crítico y quieres que a) Sr. para cambiar de marcha mental, b) nueva tarea "crítica", c) trabajar "hasta cuando" para solucionarlo. ¿Y espera que este parche crítico funcione? Honestamente, ¿qué esperas del producto, el equipo, los miembros del equipo si tus deseos fueron satisfechos?

Suelta tu ego y tu fuerte > creencias irracionales.

El término que busca es Esfuerzo discrecional , no Propiedad 0000-.

Supongo que sus empleados están cumpliendo con sus obligaciones contractuales (de lo contrario, su El curso de acción es claro).

No tiene derecho a esperar un esfuerzo discrecional. Eso es lo que es por definición. Básicamente, esto no es algo de lo que puedas hablarles y esperar un cambio. Es probable que obtenga la respuesta opuesta. No tienen la obligación de darlo. Es probable que las amenazas de despedirlos tengan una respuesta deficiente tan abrumadora, además de ser ilegales.

No tengo buenas sugerencias sobre cómo se pueden mejorar las cosas. El mero hecho de que pueda confiar en el esfuerzo discrecional de parte de su gente me sugiere que la cultura no está necesariamente rota.

Arreglar esto llevará tiempo, así que en cambio, puedo ofrecer medidas provisionales:

Corrija el factor de bus de 1

¿Por qué solo un empleado puede resolver este problema?

Tenga un -la lista de llamadas

De acuerdo con el reembolso acordado con los empleados individuales, no lo que usted cree que vale.

Implemente actualizaciones en mejores momentos

Puede que no sea posible, pero implementar las cosas en mejores momentos puede aumentar las posibilidades de que alguien lo ayude.

El valor de su software depende de lo bien que esté compatible, por lo que no debe utilizar el esfuerzo discrecional como muleta. Si desea que su software sea compatible a un nivel, debe asegurarse de tener las cosas en su lugar para garantizarlo.

Entonces, ¿espera que sus empleados renuncien a su vida social y / o familiar en un abrir y cerrar de ojos para solucionar problemas?

¿Son realmente tan críticos? fuerte>

Los gerentes siempre parecen pensar que todo es fundamental porque decir no es difícil. Esta es una fuerte razón potencial por la que su desarrollador líder está retrocediendo. Están tratando de proteger sus límites porque tú no lo harás. Y están tratando de proteger los límites de su equipo porque tú no lo harás.

Si realmente son tan críticos, entonces ¿qué está fallando que permita que ocurran estos problemas?

Si la calidad de su producto es tan mala, entonces debe moverse y dejar que sus desarrolladores elaboren un plan para que el producto vuelva a encarrilarse. La mala calidad no se trata solo de errores. La mala calidad hace descarrilar la previsibilidad. Si constantemente se sale del plan porque su calidad es tan mala, entonces corrija su calidad. Y no lo arregla pidiendo a los desarrolladores que lo hagan en su tiempo personal. Si esa es la expectativa que establece, entonces le está diciendo a sus desarrolladores que la empresa no se preocupa por la calidad y, por lo tanto, no valora la previsibilidad. Si no valora la previsibilidad, deje de quejarse.

Si realmente son todos críticos, ¿por qué no planifica una rotación de guardia?

Esto no solo protege el tiempo personal de los empleados y protege las necesidades de la empresa, sino que también crea un incentivo para que los desarrolladores solucionen los problemas sistémicos que les están causando tantas luchas. (tal vez necesite más o mejores pruebas, tal vez tenga un código heredado roto, etc.)

¿Por qué no se queda hasta tarde y arregla las cosas?

Te estás quejando de que alguien no trabaja durante la noche para solucionar un problema. ¿Por qué no trabajas toda la noche para arreglarlo? Creo que encontrará las mismas conclusiones que el líder de su equipo.

Su comportamiento

Ha amenazado con despedir a sus empleados por no hacer algo que usted mismo se niega a hacer. Se queja de que esto sucede a menudo, pero no lo ha planeado con una rotación de guardia o mediante el pago de la deuda técnica.

Al leer su lista de pasos para planificar un lanzamiento, lo que me llama la atención es el uso frecuente de "Les dije que ..." y la granularidad de la planificación hasta los nombres de las funciones. Planifica los detalles menores que se pueden cambiar fácilmente, pero no planificará un proceso de soporte para su producto.

Este es 100% su problema.

Su equipo fuerte>

Me parece que tiene un grupo de profesionales inteligentes y honestos que saben cómo hacer un buen software, pero a su gerente le gusta dictarles cómo hacer su trabajo y cuándo el enfoque del gerente causa un problema, obligarlos a trabajar más horas.

¿Ha dado un paso atrás y le preguntó a su equipo cómo detectar errores menos críticos? ¿Le ha preguntado a su equipo cómo creen que deben manejar la responsabilidad por problemas críticos inesperados?

El líder de su equipo tiene razón al hacer retroceder sus expectativas. Y me alegra saber que está animando a su equipo a decir que no a las cosas. Él está tratando de proteger al equipo porque tú no lo estás.

En mi tiempo como líder de equipo, puedo decirte que una de las lecciones más difíciles pero más importantes es aprender a decir que no. Tal vez puedas aprender algo de este empleado tuyo.

Si el 90% de los usuarios no pueden iniciar sesión y los usuarios no pueden realizar compras (es decir, se están perdiendo las ventas), debe revertir la actualización a la versión de trabajo anterior de inmediato. Esperar a que sus desarrolladores solucionen y corrijan el error puede llevar mucho más tiempo y causar un impacto más negativo en el usuario que simplemente volver a una versión anterior.

Más importante aún, es menos probable que sus desarrolladores quieran seguir trabajando para usted si se ven obligados a realizar horas extraordinarias cuando hay una mejor solución disponible. Si valora a sus empleados, debe respetar su tiempo fuera del trabajo.

Respondiendo a la pregunta actualizada:

Su gran problema no es la falta de propiedad. Esto parece ser un síntoma de un problema subyacente más profundo: el hecho de que su proceso de desarrollo parece estar sustancialmente roto.

En teoría, su proceso (es decir, pruebas automatizadas, cobertura de pruebas de &, planificación en sprints, no cambios en los requisitos) debería evitar la mayoría de los problemas que ve.

Según su propia declaración, se encontró con varios problemas "Showstopper" con el programa incluso cuando se implementó en el cliente y algunos de ellos incluso fueron regresiones. Los sprints no terminan a tiempo (las pruebas son parte del sprint). E incluso cuando se escribe, la prueba no proporciona suficiente cobertura para detectar esos errores. También dijo que ya tuvo una situación de "quedarse hasta tarde" (por lo que les dio días libres después).

Necesita descubrir qué está fallando. Solo al encontrar y resolver el problema subyacente, puede esperar arreglar las cosas.

No puede obligar a alguien a hacer horas extras (depende del país y de circunstancias potencialmente extremas como excepción a las leyes)

Si la persona no puede o no quiere hacerlo Es su responsabilidad encontrar un empleado dispuesto o contratar ayuda externa si la tarea es vital y necesita atención inmediata.

Pregunte a un abogado laboralista en su jurisdicción para aclarar.

En cuanto a la propiedad y el seguimiento de las tareas asignadas o prometidas, tiene su arsenal disciplinario hasta la finalización de los contratos de trabajo.

Además, ¿qué Sefe dijo ...

Respondiendo a la pregunta actualizada,

Parece que se han seguido buenas prácticas de trabajo:

1. sprints
2. bloqueo de funciones cerca de la implementación
3. estimación de tiempo de los desarrolladores
4. pruebas automatizadas

Estoy parcialmente de acuerdo en que existe una cultura positiva de corregir errores críticos en el tiempo. Sin embargo, la cultura también necesita Reflejar ningún código es perfecto, a menos que gastes mucho dinero en él, hay un antiguo piso que dice que la NASA gastó alrededor de $ 1,000 por línea de código. No comentaré mucho sobre el aspecto cultural, ya que eso ya ha sido cubierto por otros, en cambio, algunas sugerencias de metodología:

Una estructura de equipo que está de moda en este momento son los escuadrones de características que poseen de un extremo a otro. finalizan la entrega y la responsabilidad operativa de la vertical aislada que escriben. Si sale mal, ellos son los que se despiertan por la noche, sin embargo, sería cauteloso al introducir esto en un entorno heredado, ya que prestará atención al disgusto si un equipo no tuviera la oportunidad de presentar la calidad que desean desde el principio. -Vamos. Y los roles de Operaciones tradicionales con contratos / pago según convenga probablemente estén más abiertos a la forma de trabajar de guardia.

Una mejor idea sería introducir la idea de campeones de control de calidad dentro de un equipo y los "3 amigos" El enfoque, es decir, el producto, el desarrollador y el miembro de control de calidad, escriben juntos la especificación de características (diseño impulsado por el comportamiento). Esto asegura que "cómo un miembro de QA lo rompería" se contabiliza desde el principio y debe ser lo suficientemente detallado, es decir, una especificación a modo de ejemplo. No es necesario que el miembro de control de calidad sea la persona que escribe la automatización, pero debe revisar el código. Como la gente ha mencionado anteriormente, el autor del código no debería ser el único responsable de acreditar su calidad y presentar a un tercero lo antes posible en el proceso es un paso positivo.

Quizás también sea necesario mejorar el entorno de producción y la gestión de versiones. Las "implementaciones azul / verde" y las "pruebas en producción" son prácticas comunes para implementar cambios gradualmente a una audiencia cada vez más amplia solo cuando las métricas se prueban. Idealmente, su entorno de ensayo debería detectar errores críticos, pero siempre hay algo diferente en la producción, por lo tanto, nunca debería ser un lanzamiento espectacular.

A juzgar por el período de tiempo, aunque esté utilizando una cadencia de liberación típica, es posible que desee considerar la liberación con más frecuencia. Las versiones más pequeñas y frecuentes pueden conducir a un menor riesgo si se combinan con una buena automatización de pruebas y versiones. Esto se puede combinar con interruptores de funciones para que las funciones se puedan activar por completo cuando se completen las historias de usuario de redacción.

Leí tu actualización. Su problema es que envió un producto roto. Eso es. Eso es en lo que necesita trabajar: no envíe productos rotos.

Su queja es ridícula. USTED decidió enviar un producto cuando estaba roto. Ahí es donde se detiene la pelota, contigo.

Luego cometió dos errores: Primero, parece que el momento de su lanzamiento fue tal que se le informó a las 4 pm. Lanzamiento media hora antes de que los desarrolladores lleguen al trabajo. Solución muy simple, es su trabajo saber esto. En segundo lugar, no parece haber ninguna motivación para que el empleado trabaje horas extraordinarias. Pagar horas extras suele funcionar bastante bien. Un entorno en el que permite que el código roto se envíe con regularidad no lo hace.

A la luz de la pregunta actualizada, sugiero que si bien es posible que tenga un problema de actitud de empleado en sus manos, lo que realmente tiene es una calidad de software problema:

1. No existe un proceso de garantía de calidad independiente de los desarrolladores que escriben estas funciones. Los desarrolladores son notoriamente malos probando su propio código, en gran parte porque, naturalmente, comienzan con la suposición de que todo lo que escribieron funciona y debería funcionar de la forma en que pretendían que lo hiciera, en lugar de cómo el usuario final espera que lo haga.

2. Cualquier entorno de prueba que tenga no es adecuado para reproducir los problemas identificados por sus clientes. Identificó errores que impidieron el inicio de sesión en varias etapas del proceso, pero la verificación final no identificó este problema.

3. El desarrollador senior está dispuesto a ignorar los problemas críticos que en realidad son fundamentales . "Amigo, mis amigos y yo íbamos a hacer algo genial esta noche" no es el tipo de reacción a "nadie puede iniciar sesión, por lo tanto, nuestro negocio está perdiendo el 100% de los posibles ingresos de estos productos que usamos". para pagar tu salario ”quieres ver. Si así es como reacciona ante una emergencia, ¿cómo crees que lidia con cosas menores? ¿Con más atención a los detalles o menos?

Hay una parte específica de tu historia actualizada que me plantea muchas más preguntas y creo que debes investigar en detalle: en En un punto del proceso, el equipo dijo que escribieron todas las pruebas y no hubo problemas. Luego, dice más tarde, se descubrió que no todas las pruebas se escribieron después de todo, que el error de inicio de sesión no se identificó y que dedicó tiempo adicional a escribir esas pruebas y solucionar el problema de inicio de sesión, que luego se demostró en producción para no ser reparado.

1. Cuando dijiste que las pruebas no estaban escritas después de todo, ¿por qué no estaban escritas? ¿Fue que el caso en cuestión fue un descuido o el equipo tergiversó la finalización de su trabajo? Es razonable esperar que lo primero suceda ocasionalmente, lo último es un comportamiento inaceptable que debe dejar claro que no será tolerado en el futuro (a menos que haya sido un malentendido de su parte).

2. Una vez redactadas las pruebas, ¿cómo sabe que estas pruebas son correctas? ¿Revisaste las pruebas? Claramente no funcionan; todos pasaron, pero el problema que se probó explícitamente y se dijo que estaba solucionado aún llegó a producción. No es extraño que personas sin escrúpulos escriban pruebas de manera que siempre pasen, especialmente si hay presión de fecha límite. Si no puede revisar las pruebas usted mismo, debe buscar a un técnico en otro equipo para que las revise por usted.

También hay algo más que escribió, que el El número de errores críticos ahora es de hasta una vez al mes, pero antes era más como una o dos veces al año. ¿Porqué es eso? ¿Ha investigado por qué está sucediendo eso ahora? ¿El producto o el equipo cambió significativamente en ese período de tiempo? Parece que la calidad está disminuyendo.

Esto es lo que creo que debería hacer:

1. Contratar a un evaluador de control de calidad bueno y experimentado y someter todo el trabajo de este equipo a pruebas de control de calidad independientes (debe hacer esto en toda su empresa, pero este equipo en particular lo necesita porque la calidad está disminuyendo).

2. Revise el entorno de prueba y compárelo con la producción para asegurarse de que el entorno de prueba aún refleja la producción.

3. Revise las pruebas y el código que su equipo está escribiendo para determinar la calidad y la corrección de manera regular y con más detalle de lo que está haciendo actualmente.

Es posible que tenga un problema de actitud en su equipo con el senior, pero definitivamente tiene un problema de calidad. Los problemas de actitud son difíciles de solucionar, pero los problemas de calidad son más fáciles de solucionar y tienen la ventaja adicional de hacer que la actitud de un chico del equipo sea irrelevante si lo haces bien.

Siendo yo mismo un miembro senior del equipo y teniendo que lidiar con situaciones de este tipo una y otra vez, solo puedo decir que un tipo en el que siempre puedes confiar también necesita algo de motivación. El tipo seguramente es honesto y tiene derecho a su vida personal después de la oficina, pero se quedará y arreglará errores si hay una mejor motivación para él, o si logras crear un ambiente amigable para él.

Piensa al revés: qué pasa si el tipo se enferma o deja el trabajo o tiene alguna emergencia y tiene que dejar la oficina por un tiempo. Actualmente, su tiempo con sus amigos parece ser un problema para usted, pero puede tener todas las necesidades legítimas para salir de la oficina incluso durante las horas de trabajo (y pasar tiempo con sus amigos después de la oficina también es una necesidad legítima).

Una actitud gerencial muy común es siempre pasar por alto al tipo que puede hacerlo . Ahora bien, esto varía de persona a persona, pero al ser un empleado, esto puede generar frustración y tal situación surge cuando el empleado comienza a decirle no .

Entonces, en mi opinión, debe hacer dos cosas:

1: ) Debería crear una plataforma de aprendizaje para el personal subalterno y delegar gradualmente las cosas para que en momentos de necesidad crítica no tenga que mirar el mismo chico cada vez.

2: ) Siempre que dentro del horario de oficina el chico esté haciendo lo que se supone que debe hacer y cumpliendo con sus KPI, está bien y debe ser tratado de manera amistosa. conducta.

Me parece que él simplemente valora más estar fuera de la oficina que en ella.

Hay muchas razones por las que, y un buen administrador no asumiría simplemente lo peor. Quizás esté teniendo problemas personales en casa, ya sea una relación, una enfermedad o cualquier otra tensión.

Quizás esté cada vez más insatisfecho con el trabajo y simplemente ya no le importa.

Hay muchas razones por las que puede estar actuando como lo hace. Te sugiero que veas si hay algo por lo que querrías darle más gracia antes de desgarrarlo demasiado o disciplinarlo.

Bienvenido a WorkPlace, donde todo es culpa del gerente. Todo.

Lo miro como dijeron que el producto está listo y no lo está, por lo que deben mantener sus palabras. - Proyecto de código

Enmarca la pregunta de una manera diferente .
Tienes un ingeniero senior al que se le ha asignado la responsabilidad de una función, es responsable de las pruebas y ha pasado el producto final. Ese producto con luz verde tiene problemas de calidad críticos. (¡Y estoy de acuerdo en que su definición es bastante crítica!)
En otras palabras, tiene un ingeniero senior de bajo rendimiento que no desea hacer horas extras para corregir sus propios errores (o, como usted dice, cumplir con sus promesas).

Pero la clave aquí no es que el ingeniero no haga horas extras - según los comentarios, tienes una aplicación móvil, por lo que no es como si pudieras lanzar una solución rápidamente de todos modos.
El problema clave es que el ingeniero senior está dando luz verde a estos productos rotos en primer lugar.

Las expectativas / legalidades aquí dependen en gran medida de dónde se encuentre ubicado, pero en una cuenta personal, nunca he trabajado en una empresa (EE.UU. o Japón) donde se aceptaría la falta de propiedad de su ingeniero superior. Ya sea que tenga la culpa o no, es un hecho que un error crítico debe solucionarse lo antes posible. Afortunadamente, tampoco he trabajado en una empresa en la que al menos no me pagarían (dentro de lo razonable) por mis esfuerzos para corregir mis propios errores.

El siguiente paso aquí es revisar y encontrar por qué ocurren estos errores. La mayoría de las respuestas aquí sugieren que el problema es algo sistémico; yo diría que el hecho de que solo uno de sus múltiples equipos tiene el problema sugiere lo contrario.

Aún así, debe revisar, encontrar la causa e intentar arreglarlo. Si se trata simplemente de un ingeniero senior de bajo rendimiento, entonces se deben tomar medidas para que ese ingeniero esté a la altura o para contratar a otro ingeniero que pueda hacer el trabajo correctamente.

Parece que es hora de avisar a todo este equipo. Si no comienzan a cumplir con las pautas, pautas claras, se cancelarán.

Puede lograr esto estableciendo pautas sobre errores / problemas que se informan contra lo que admiten. Por ejemplo, un error de prioridad 1 debe comenzar a funcionar dentro de 1 hora, el progreso se debe informar a la gerencia (usted) cada hora después de eso, hasta que el error se solucione o se implemente una solución a su satisfacción. Su satisfacción es clave, y debe apoyarlos a ellos y a los otros equipos para que hagan las cosas cuando el trabajo fluye más allá de las horas normales de trabajo estando presente o muy disponible usted mismo.

Cuando se vayan a casa , luego no cumplieron con sus requisitos para trabajar en el problema y registrarse cada hora. Esto ahora es medible. Estos lineamientos también tendrían que ser cumplidos por otros equipos.

Ahora, cuando no cumplen con estos requisitos una vez, notifican, notifican formalmente por escrito, CC a su gerente y a RR.HH. que no cumplieron sus obligaciones. La segunda vez, vuelve a informar, informa al equipo que un tercer incidente es motivo de despido. Tercera vez, despedido.

Ahora supongo que este desarrollador senior tiene algunos conocimientos críticos que supone que los hace invaluables. Nadie es tan valioso y esto envía ese mensaje. No están apoyando a la empresa, la empresa ya no los apoyará.

Espere algunas consecuencias si se trata de la rescisión. De hecho, poseen un conocimiento que requerirá cierto esfuerzo para ponerse al día con los demás. Asegúrese de que los desarrolladores de Jr. conozcan estas políticas, si pueden comenzar a hacer el peso incluso si su Sr. los abandona, entonces podrán mantener las cosas en marcha cuando elimine al alborotador.