Administro 20 ingenieros de software divididos en 4 sub equipos. Todos los equipos tienen buenos estándares de trabajo y un alto nivel de propiedad, excepto uno. Ese equipo tiene un chico senior y tres juniors. Cada vez que hay un error crítico (que afecta a la empresa), este senior siempre lleva el trabajo al día siguiente diciendo cosas como "No puedo terminarlo hoy", "Lo investigaré mañana", "¿ ¿Realmente lo necesito hoy? "o" ¿Cómo vamos a probar eso esta noche? " 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í. También les dijo a estos jóvenes que también retrasaran su trabajo.
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.
Hoy, hubo un error crítico y este senior dijo lo mismo nuevamente: "No puedo terminarlo hoy. Tengo una reunión con amigos y me tengo que ir ". luego se escabulló mientras yo hablaba con mi entrenador.
Esta no es la mentalidad que quiero que tenga mi equipo. Planeo decirle que tiene que cambiar su estilo de trabajo o buscar un nuevo trabajo, y esperé la respuesta. ¿Es demasiado directo para hacer eso? ¿Existe una forma alternativa de solucionar problemas como este?
Actualización
En este ejemplo en particular, el error evita que el 90% de los usuarios inicien sesión el sistema. En promedio, esto ocurre una vez al mes este año, mientras que sucedió dos veces el año pasado. Los errores críticos son errores bien definidos que: 1) impiden que los usuarios inicien sesión en el sistema y 2) impiden que los usuarios compren productos, solo estos dos tipos de errores.
Lo que hicimos para preparar cada lanzamiento:
- Teníamos planes exhaustivos en los que todos entendían los requisitos. De hecho, planificamos el nombre del campo y las funciones. Implementé para todos los equipos la regla de que los requisitos no pueden cambiar después del inicio del sprint. También tenemos casos de prueba listos antes del inicio del sprint.
- Agregamos búfer a todas las tareas, digamos que si creemos que podemos terminar algo en 1 día, colocamos 1.5 días. Descubrimos que algunas personas siempre subestiman las tareas.
- La primera fecha límite fue a fines de enero; es cuando creen que pueden hacerlo con pruebas. Esta es otra regla que implementé en todos los equipos. Las OP nos dicen lo que quieren y nosotros les decimos cuánto tiempo les llevará. Entonces, les dije a otros equipos que todo estaría listo para la tercera semana de febrero.
- A fines de enero, dijeron que todas las funciones se realizaron con pruebas en casos de prueba. Los implementamos en nuestro entorno de prueba y encontramos un error en el que el usuario no puede iniciar sesión. Resultó que no escribieron todas las pruebas. Les pregunté cuánto tardarían en corregir los errores y escribir las pruebas, dijeron que dos semanas.
- Las primeras dos semanas de febrero, les dije a todos que solo probaríamos y corregiríamos errores críticos en estas dos semanas. Una vez más, los errores críticos son 1. los usuarios no pueden iniciar sesión o 2. los usuarios no pueden comprar productos en la aplicación. Todo lo demás estará en nuestra cartera de pedidos.
- Semana 3 y 4 de febrero después de que lo lanzamos a los clientes. Pasamos estas dos semanas arreglando errores no críticos (que registramos desde el n. ° 4) que son bloqueos reproducibles y otros errores menos importantes como el diseño, etc. Nuevamente, todas estas correcciones tienen pruebas.
- Lo publicamos a los clientes con todas las pruebas en verde. Después de la implementación, descubrimos que algunos números no eran correctos, por lo que volvimos a probar todo y encontramos que volvía el mismo problema: los usuarios no pueden iniciar sesión.
- La última vez que se quedaron hasta tarde en la noche, les di 2 días libres adicionales.