El desarrollador no cumple con la fecha límite

Se le percibe como el líder del equipo, por lo que, en ausencia de alguien con ese título formal, debe asumir ese rol. Ya se reúne regularmente con el director ejecutivo como si tuviera ese rol formal, por lo que, de forma predeterminada, lidera el equipo.

Le sugiero que hable con el nuevo miembro del equipo, averigüe si es realista que pueda desarrollar la nueva capacidad en un plazo realista y luego analice las opciones con el director general y explique sus hallazgos. Si es razonable completar el desarrollo en un plazo breve, el director ejecutivo puede aceptar que continúe el trabajo. Si su consejo es que es poco probable que se complete, debe recomendar un curso de acción, como detener el desarrollo, posponerlo para una fase posterior, o incluso asignarle tiempo, si la característica es lo suficientemente importante. Lo que no puede hacer, dado su rol de facto, es ignorar la situación; de lo contrario, no está cumpliendo con su rol.

Dando un paso atrás de esto, me preocupa que un desarrollador haya podido desviar el proyecto de esta manera. Una vez más, como usted es el líder del equipo en todo menos en el nombre, debe controlar la actividad de desarrollo y asegurarse de que se evalúe el impacto de cualquier cambio de alcance propuesto antes de aprobarlo. Si no impone su autoridad ahora, habrá anarquía dentro del equipo, con otros desarrolladores (y especialmente este nuevo) yendo al CEO cada vez que piensen en algo nuevo para agregar al alcance y al proyecto. nunca entregará porque siempre hay algo nuevo y brillante para construir. ¿Quizás necesite completar el alcance acordado y luego tener una nueva versión en la que se puedan agregar nuevas ideas?

Los líderes de equipos no lo son solo porque fueron designados oficialmente como dicho líder de un equipo. Lideran porque asumen el rol y, una vez asumido, son los gerentes de proyecto de facto y son responsables y rinden cuentas por el proyecto exactamente de la misma manera que si fueran designados oficialmente. No puede liderar el equipo, ser visto como el líder del equipo, y luego eludir las responsabilidades y la rendición de cuentas en el mismo.

Y cometiste un error fatal: permitiste que T y el CEO ampliaran tu alcance. Y ahora estás lidiando con los efectos del desplazamiento del alcance. Nada más y nada menos.

La buena noticia es que el aumento del alcance le sucede a los mejores de nosotros. Y la recuperación está disponible para usted. Debe sentarse con el director ejecutivo y describir lo que ha observado, que T y el director ejecutivo introdujeron un cambio fuera de control que pone en peligro todo el proyecto en su conjunto. Aunque el cambio puede ser una gran idea, la introducción debe estar "bajo control", que sea analizada por el equipo más amplio, los impactos identificados y entendidos, el cronograma y los costos ajustados en consecuencia, las cosas repriorizadas, las estimaciones y los valores de planificación acordados de manera integral por el equipo más amplio, y luego programar el trabajo. Debe "enseñar" a su director ejecutivo sobre el control del alcance y el control del alcance y lo importantes que son estas cosas y hacer que su director ejecutivo se comprometa a seguir adelante.

Después de esto, debe tener una reunión con el resto del equipo, tal vez solo con T también, y establecer expectativas adecuadas sobre este tipo de cosas y nunca volver a hacerlo. Si sientes que no tienes esta autoridad y el equipo no te seguirá, entonces no eres el líder del equipo.

En ausencia de una autoridad formal aquí, deberá andar con cuidado. Puede estar infiriendo cómo el CEO ve su rol y puede que en realidad no sea como él lo ve. Además, si tiene un gerente formal que, aunque no es un desarrollador senior, sigue siendo su jefe, sería cauteloso asumir una autoridad formal que usted no tiene. Estoy de acuerdo con otros en que lo mejor para usted es demostrar liderazgo, pero debe hacerlo de manera informal, por ejemplo, simplemente eliminando los obstáculos y haciendo que las cosas sucedan. Mi instinto me dice trabajar con tu colega y tratarlo como un igual a menos que estés formalmente por encima de él. Incluso si usted es desarrollador senior y él es desarrollador junior, si ambos reportan al mismo gerente, usted no es su jefe y no apreciará que actúe como si lo fuera. Trate de entender qué lo está bloqueando, ofrézcase a ayudarlo, recuérdele los peligros de prometer demasiado y no cumplir. Asumo que usted quiere ayudarlo y está pensando en términos del equipo y no quiere simplemente quitarle el cuero cabelludo. Puede ser que termines teniendo que hacer el trabajo tú mismo pero asegúrate de que esto se sepa, sin restregarse las narices. Después de todo, incluso si su desempeño es bajo, si usted no es su jefe, no es su lugar sancionarlo.

A corto plazo, puede darle a T suficiente cuerda para que se ahorque. Usted preside las reuniones semanales, así que hágalo responsable del trabajo que no está haciendo cuando esto afecta el cronograma, el costo, el alcance, el riesgo, etc. del proyecto. Si su salida por la tangente no causa ningún problema, entonces no hay daño ni falta, pero si causa demora, no intente ser un "buen tipo" encubriéndolo.

A más largo plazo, su proyecto tiene un par de desafíos importantes:

• Sin liderazgo formal. Sin esto, habrá poco en el camino de la autoridad, la responsabilidad o la rendición de cuentas para el éxito. No necesita un maestro de scrum o un gerente de proyecto, necesita a alguien en su estructura de liderazgo para ser dueño de este proyecto que tomará decisiones como la que T acudió al director ejecutivo.
• Sin plazos formales. Necesita una fecha en la que el sistema debe estar listo. Y "tan pronto como sea posible" es una respuesta Bull-Sh*t, necesita una fecha clara que sea razonable, factible y alcanzable dado su alcance.

Idealmente, podrá abordar estos problemas centrales para evitar que T (o alguien más) se vuelva deshonesto y agregue alcance o costo o lo que sea sin control. Esto requerirá un poco de esfuerzo, pero le ahorrará problemas a largo plazo, porque en algún momento, si su equipo no tiene disciplina, alguien en algún lugar hará que el proyecto fracase.

Como no eres el líder oficial, lo mejor que puedes hacer es hablar con el gerente del proyecto o el scrum master. Hable acerca de la importancia del proyecto y sugiera poner en una caja de tiempo el proyecto fuera de curso; máximo un día más, y luego el equipo necesita seguir adelante. Además, el equipo puede comprobar este proyecto después de la entrega.

La nueva persona puede comenzar este proyecto, porque aún no tiene el conocimiento del dominio y le gustaría demostrar que será bueno para la empresa.

Esto podría haber sido una prueba de su director ejecutivo, no le consultó sobre sus pensamientos sobre la idea de T, aunque lo ve como líder de equipo y, por lo tanto, como un experto.

Hablaría con su CEO sobre un poco (!) de formalismo en la planificación de nuevos requisitos, para que más de un desarrollador pueda pensar en ellos y la estimación del esfuerzo la realice solo un miembro experimentado del equipo o dos o más desarrolladores. juntos.

Para estimaciones de tiempo recomiendo el libro "Waltzing With Bears" de Tom DeMarco y Timothy Lister. No es demasiado largo y divertido de leer y le enseñará un método mejorado de estimación de tiempo (optimista - realista - pesimista) donde puede establecer la confiabilidad que desea tener.

También hable con T, pero más para entender sus intenciones de por qué hizo ese solo con el CEO. ¿Quiere ser parte del equipo? Creo que su acción le habrá costado la confianza del CEO y del resto del equipo. ¿Pensó en este riesgo antes? ¿Es solo un idiota y quiere ser la estrella brillante de la compañía? ¿Quiere asumir tu papel principal?

No deberías hacerle todas esas preguntas directamente, pero espero que tengas suficiente intuición para averiguarlo.