El miembro de su equipo no cumple con la fecha límite para la codificación y prueba de un componente. ¿A qué te dedicas?

Usted es el gerente de un proyecto de desarrollo de software. Uno de los miembros del equipo no cumple con la fecha límite para la codificación y prueba de un componente. ¿A qué te dedicas?

@ameer_hamza Su pregunta parece superponerse con ¿Cómo lidiar con un miembro del equipo que no cumple con los plazos? en pm.stackexchange.com/questions/611/… Revise esa pregunta y, si no cubre su consulta, modifique su pregunta en consecuencia.
Para ser sincero, me sorprende la cantidad de respuestas aquí que ignoran el contexto y optan por el enfoque prescriptivo. ¿Puede proporcionar más información, como las expectativas de un "gerente" en su empresa, la responsabilidad del equipo o los valores o la cultura de la empresa?
dé al desarrollador una 'marca negra' cuando tenga 3 marcas negras, despídalo inmediatamente y contrate a un reemplazo. Esto garantiza que solo tenga los mejores desarrolladores en su empresa.

Respuestas (5)

Si el desarrollador no cumplió con la fecha límite, hay una razón detrás de eso. Averigüe qué sucedió, asegúrese de que no vuelva a suceder o cree un plan de contingencia para cuando vuelva a suceder.

En mi práctica, la mejor manera de abordar esto es establecer una guía de comunicación con los desarrolladores.

En primer lugar, recomendaría a los desarrolladores que le den sus estimaciones para la tarea en la que trabajarán, o si hay una fecha límite para la tarea, pídales que hagan una revisión/investigación durante 15-30 minutos y confirmen que va a cumplir con la fecha límite o negar y proporcionar una nueva estimación, según la información que encontraron de la investigación.

Durante la ejecución real, el desarrollador debe informarle si algo salió mal (ocurrió un problema, se percató de un riesgo o simplemente entendió que esto llevará más tiempo) y no cumplirá con la fecha límite. Según el motivo, puede intentar ayudarlo de muchas maneras diferentes, si es necesario.

Trate de evitar situaciones en las que le dé al desarrollador una tarea con una fecha límite y verifique el progreso de la tarea solo cuando llegue la fecha límite.

También es su trabajo como PM apoyar a los desarrolladores a través de su trabajo y ayudarlos a hacer su trabajo de la mejor manera.

Tú gestionas tus variaciones. Acelere o bloquee las tareas exitosas donde pueda y lo que pueda pagar. Y comuníquese temprano, honestamente y tanto como sea posible. Esto es gestión de proyectos. A menos que planifique consistentemente gordo y feliz, que no es un objetivo que debería tener, llegará tarde tanto como llegue a tiempo y temprano. La forma en que maneja esas variaciones desfavorables es lo que lo convierte en un buen PM, no es que nunca llegue tarde.

Te acostumbras, como sucede todo el tiempo. :-)

Empiezas a estar reajustando el horario. Luego, si es necesario, escala la fecha límite más reciente a aquellos que necesitan saber , para que puedan ajustar sus planes y las expectativas del cliente.

En el mundo real, probablemente tenga un búfer en el cronograma para que la fecha límite incumplida no cause un daño importante.

Si esto sucede con frecuencia, entonces debe aprender a ajustar las estimaciones que le da este programador o enviarlo a un curso para una mejor capacitación.

En la gestión de proyectos clásica solo hay comunicación. Su proyecto está retrasado no porque ese desarrollador, su proyecto está retrasado debido a una mala planificación o gestión de riesgos. Lo que sus partes interesadas quieren que haga en esta situación es explicar la situación, las consecuencias y, por supuesto, lo que hace ahora para que el aplazamiento sea lo más pequeño posible.

Si todavía hay cosas que hacer, apoye a su desarrollador con más desarrolladores y cree un entorno en el que puedan concentrarse en su trabajo.

Si básicamente ha terminado, solo hay una comunicación honesta, y no olvides asumir la responsabilidad, no hay nada más débil que culpar al desarrollador.

Si observa la causa raíz del problema, su proyecto completo depende de la planificación incorrecta o de menos personas en una tarea específica. Esto no es una mala gestión de proyectos. En proyectos de software es normal. En los componentes de software nuevos, simplemente no es posible planificar adecuadamente, dependiendo de la complejidad de su software. Es por eso que debería pensar en cambiar a métodos ágiles como Scrum o Kanban. Ofrecen una forma mucho mejor de planificar y pronosticar basándose en estadísticas sólidas.

Llegar tarde no se debe a una mala planificación y gestión de riesgos. El trabajo es probabilístico. Siempre lo ha sido, siempre lo será.

Su éxito como PM depende de su capacidad para crear un vínculo de confianza entre los miembros del equipo. Todos en el equipo deben sentir y creer que la verdad, la cooperación y el apoyo mutuo son valores compartidos por todos en el equipo. Arrojar al miembro del equipo que llega tarde "debajo del autobús" destruirá ese vínculo.

En lugar de eso, tendría una conversación cara a cara con esa persona para comprender qué obstáculos enfrentaron que les impidieron cumplir con sus expectativas. Esté dispuesto a aceptar y admitir su papel en la creación de esas expectativas. Recuérdese el contrato original de asignación de la obra en cuestión. ¿Era INTELIGENTE ? Pregúnteles qué pensaron que les ayudaría a lidiar mejor con los obstáculos que encontraron.

En la próxima reunión retrospectiva o stand-up, usted y el miembro del equipo que llegó tarde expondrán los hechos y los obstáculos antes mencionados. Deje que las necesidades de la situación hablen por sí mismas sin juicio de su parte. Esto debe hacerse de manera rutinaria en la reunión diaria de pie en lugar de un evento especial o flagelación. Permita que el equipo organice por sí mismo el plan de recuperación para que todo el equipo se apropie de la situación, no solo usted o el miembro que llega tarde. Establezca las reglas básicas de que mantendremos la discusión positiva y los comentarios breves. Pídales a todos que usen "declaraciones en primera persona". Esto reducirá la proyección de juicios y emociones que se sienten impulsados ​​a compartir. Si los miembros del equipo comienzan a culpar, recuérdeles que todos compartimos las consecuencias de la situación.

Por último, terminaría con el dicho de que " las malas noticias nunca mejoran con la edad ". Si alguien tiene problemas en algún momento, debe hablar de inmediato para que el equipo pueda manejar la situación. Cuanto más tiempo se ocultan los problemas, menos opciones tenemos para tomar medidas correctivas y más difícil es nuestra recuperación.

Si toma medidas sin el consenso del equipo, la moral del equipo se verá afectada y su acción parecerá arbitraria. Sin embargo, después de reiterados plazos incumplidos y esfuerzos para apoyar a esta persona, es probable que su equipo se dé cuenta de que su miembro retrasado no está a la altura y lo "votarán para sacarlo de la isla". Con ese consenso, su trabajo como primer ministro será lograr que así sea. Los miembros del equipo pueden entristecerse (o no) por la partida, pero sabrán que ellos (y usted) han hecho todo lo razonable para ayudar a su antiguo colega a tener éxito.