¿Cómo yo, líder de equipo, evalúo proyectos

Los tímidos a menudo valoran los proyectos, y no todos lo hacen bien. Aquí, mucho depende de la personalidad del propio líder del equipo, así como de su comprensión del equipo. Existen muchas técnicas para evaluar proyectos desde el método "por analogía" hasta PERT. Pero hoy hablaré sobre cómo uso la planificación del póker y otras técnicas para evaluar con mayor precisión y con mayor beneficio.




Antes de hablar sobre enfoques específicos, vale la pena detenerse en las principales dificultades del proceso.

Siempre hay dos lados en una evaluación: un equipo y un cliente. Al estar entre ellos, el líder o gerente del equipo se ve obligado a buscar un equilibrio de intereses opuestos. Es imposible sobreestimar la estimación, ya que el cliente se negará a pagar más. Subestimar tampoco vale la pena. En este caso, tendrá que interrumpir el ritmo del equipo, con el riesgo de fatiga excesiva, agotamiento y el hecho de que el código entre en producción sin control.

La profundidad del estudio de la tarea de evaluación es una cuestión filosófica. Las tareas pueden discutirse durante mucho tiempo, luego la evaluación de todo el sprint se retrasará. Pero si no profundiza en la esencia, puede perderse algo importante que afecta la fecha límite.

Los desarrolladores débiles y fuertes actúan de manera diferente. Si un desarrollador fuerte aprecia la tarea, el débil no cumplirá con sus plazos. Por el contrario, los fuertes harán la tarea mucho más rápida que la débil apreciada. Teniendo en cuenta la diferencia en la velocidad del trabajo, son posibles diferentes errores "sociales" en la evaluación, por ejemplo, cuando un desarrollador débil "mira" a qué hora uno fuerte evalúa una tarea, y establece los mismos plazos para no explicar por qué su "estimación" es más larga: " Llamó a la semana, ¿no puedo decir que tomará tres? Diré al menos un año y medio ... ".

El llamado póker de planificación ayuda a sortear este problema, cuando todo el equipo participa en la evaluación, sin saber quién será la tarea, y la evalúan a ciegas, sin ver lo que ofrecen los colegas.


Autor: Hkniberg de Wikipedia en inglés - Movido de en.wikipedia a Wikimedia Commons., Dominio público Todos escanean una

tarea en su cabeza. Si los términos establecidos por los miembros del equipo son muy diferentes, comienza la discusión. En estos momentos, generalmente resulta que el equipo no notó ninguna característica que tendría que implementarse como parte de la tarea. Después de eso, todos volverán a votar. Y luego no hubo afirmaciones de que alguien hubiera estimado que algo andaba mal: todos participaron. Incluso si hay un error, nadie perderá el tiempo buscando al culpable, habrá una conversación más constructiva sobre los nuevos factores que han aparecido y cambiado la alineación (y cómo tenerlos en cuenta en el futuro, trabajando en los errores, escribí sobre eso en un artículo anterior en párrafo 5 ).

Una evaluación más precisa del proyecto ayuda a hacer preguntas adicionales al cliente. Pero aquí puedes ir demasiado lejos fácilmente. A algunos desarrolladores no se les pide una evaluación precisamente porque bombardean al cliente con una gran cantidad de cartas de aclaración. Desde el punto de vista de las relaciones con los clientes, el número de preguntas adicionales se minimiza mejor, y esto aumenta la incertidumbre de la tarea.

Algunos consejos sobre cómo evitar errores.

Para minimizar el error en la evaluación, sigo algunas reglas simples.

Inicio una llamada introductoria con el cliente antes de leer los términos de referencia. En esta llamada, le pido que hable sobre el problema a vista de pájaro: quién será el usuario final, cómo aplicarán el resultado, qué dispositivos estarán involucrados (con tales permisos), cómo se vería el backend si ya existe, etc. Después de eso, puedes comenzar a leer TK.

Al leer los términos de referencia, hago una lista de preguntas para el cliente. Al estudiar la tarea, en tu cabeza deberías tratar de "codificar" todo el proyecto; imagina cómo se verá. La lista de preguntas debe ser tal que, después de recibir las respuestas, sea posible formar una evaluación confiable.
La idea principal aquí es que las preguntas no deben hacerse gradualmente, sino a la vez. Y a menudo es mejor recurrir a una lista preparada de preguntas para no estirar la correspondencia. Aún así, el texto transmite mucha menos información. En la llamada, puede revolver la pantalla si esto de alguna manera aclara la situación.

Si por alguna razón es imposible llamar por teléfono, estoy buscando un documento de Google, donde agregaré estas preguntas y el cliente las responderá cuando llegue el momento. Esta es una forma más efectiva de comunicarse en una tarea que un chat o correo personal. Este documento puede enviarse posteriormente a los desarrolladores que participarán en el proyecto; no tendrán que volver a hacer las mismas preguntas.

Por cierto, es deseable que la persona responsable del proyecto responda las preguntas del lado del cliente, y no el ex secretario del director, que simplemente desempeña el papel de un teléfono dañado. Esto reducirá el riesgo de que los parámetros del proyecto cambien directamente durante la operación.

Si es posible, traigo desarrolladores al campo.Comprender cómo se usará el producto en realidad ayuda a marcar los puntos "y" y mejorar la puntuación. Por ejemplo, se está desarrollando un software para cajas registradoras. Y sus desarrolladores han estado sentados en la computadora durante 15 años y no han visto la caja en sus ojos. Los lleva a los usuarios finales, solicita hacer una compra no en algún lugar, sino específicamente en esta tienda. Y ven que tía Masha está sentada allí, que presiona dos botones simultáneamente con sus dedos y no puede distinguir las letras en los lentes del monitor. Como resultado, muchas preguntas sobre el proyecto desaparecen por sí mismas: la fuente se agranda y se agrega la confirmación de las operaciones. Es difícil imaginar tales cosas en mi cabeza. Y la sensación de realidad recibida de una visita personal alimentará al desarrollador por otro año.
Desafortunadamente, tal inmersión no es posible en todos los proyectos.

No evalúo la tarea si la condición es "y" / "o". Por ejemplo, si se propone "hacer autorización y registro". No hay problema en dividir este punto en dos tareas y evaluar cada una de ellas individualmente. Dicha evaluación será más precisa, porque no combinará entidades similares, pero aún diferentes. Cuanto mejor sea la descomposición, más preciso será el resultado.

"O" es aún peor, siempre es idéntico al TK borroso, a partir del cual es imposible construir estimaciones precisas. ¿Es necesario o no hacer una autorización a través de las redes sociales? ¿Qué pasa si hay alguna API específica para el backend? Si no conoce los detalles, simplemente no puede dar una evaluación precisa.


Imagen: Michael Dubakov @ Medium

No puede haber una evaluación de 40 horas para la tarea.Esta es otra variación de la regla anterior. Agile recomienda descomponer un proyecto en tareas de no más de 20 horas. No debe haber tareas indivisibles para una semana de trabajo. En pequeñas porciones, la estimación es mucho más precisa.

Cuando descompongo una tarea, intento registrarla. Es útil al mismo tiempo desde dos ángulos.

En primer lugar, simplifica el proceso. Tan pronto como comience a escribir pensamientos sobre un tema determinado, el cerebro los desarrolla con placer. Por cierto, por eso no recomiendo que la descomposición se mezcle con la estimación, es decir seleccione una tarea y evalúe cada una de ellas de inmediato. Es mejor dividir todo el proyecto en componentes, arreglarlo y luego evaluarlos a la vez, para no hacer que su cabeza funcione en dos modos a la vez.

En segundo lugar, el "registro" de descomposición ayuda a explicar la posible discrepancia entre las estimaciones y la realidad en el futuro. De hecho, tiene una descripción completa de la tarea que se está formando: qué opciones consideró. Por ejemplo, tuvo en cuenta la autorización mediante inicio de sesión y contraseña con un token, renovación de token, etc., y el cliente, al parecer, todavía quería autorización a través de las redes sociales, simplemente no escribió sobre ello. Su descomposición de "registro" ayudará a proteger al equipo de las afirmaciones de que apreció algo, pero no cumplió con los plazos.

Enseño al equipo a no agarrar las tareas relacionadas antes de que se completen.Los desarrolladores pasan mucho tiempo en funciones adicionales. Hacen la autorización, en el camino ven que algo necesita ser reparado en alguna parte, y profundizan en este proceso paralelo. Intento sacar un reflejo: vi una tarea que lo acompañaba: formar un boleto por separado. Ni siquiera tiene que ejecutar la tarea a través del líder o gerente del equipo. Cuando el líder del equipo analiza las tareas, él mismo lo verá y lo enviará a trabajar, si es necesario. Por lo tanto, no tiene que sacar a nadie del trabajo (creó una tarea y la olvidó), y se preservará la precisión de la evaluación.

Estoy poniendo tiempo para las pruebas.Al evaluar, muchos se olvidan de los probadores. Pero, de hecho, cualquier tarea, especialmente una difícil, debe pasar por pruebas por parte de personas vivas: deben pensar en ello, buscar errores. Si encuentran algo, los errores irán a los desarrolladores que ya han logrado cambiar a un contexto diferente. Tendrán que sumergirse nuevamente en el tema. Y este ciclo puede repetirse más de una vez.
Se debe establecer tiempo para la prueba. Como regla general, esta evaluación se realiza por separado de lo que dijo el desarrollador.

Tomo en cuenta el tiempo para la programación de pares y otras características del trabajo.La programación en pareja ayuda a intercambiar experiencias y motivar a los desarrolladores. Se sientan juntos o hurgan en la pantalla, discuten la tarea y las herramientas utilizadas, y hacen algunos cambios a su vez. Este enfoque vale la pena para el equipo, pero desde el punto de vista del cliente, la tarea no se mueve dos veces más rápido. En los proyectos donde trabajé, no practicamos programación de pares constantemente, pero algunas tareas eran convenientes para hacerlo. Y tomamos esto en cuenta en la etapa de evaluación.

Del mismo modo, debe dedicar tiempo para una demostración al cliente, llamadas telefónicas, correspondencia, etc. Y, en general, para encajar en la evaluación, el desarrollador debe trabajar de manera eficiente, y para esto necesita dormir lo suficiente, descansar normalmente (y no todo el equipo de servicio el fin de semana en producción) y no conducir el trabajo más rápido, más rápido. Por lo tanto, la evaluación siempre debe basarse en la práctica laboral real, y no en el pronóstico optimista de que todos nos sentaremos y "haremos el plan quinquenal en tres años".

Estoy poniendo tiempo para el cálculo del proyecto. Hay cuatro tipos de stands: desarrollo, pruebas, preproducción y producción. Es mejor desplegar estos stands al comienzo del proyecto e inmediatamente colocarlos para este momento. Si esto no se hace, se interrumpirá la sincronización del desarrollo, las pruebas y la implementación, lo que puede convertirse en una verdadera mordaza.

No hago evaluaciones de arriba a abajo: llamo un término específico. De acuerdo con las reglas de marketing, cuando un desarrollador dice "de 4 a 12 horas", quiere decir "hacerlo más rápido que 12 horas". El cliente escucha "4 horas". Si la tarea se completa en 11, el desarrollador considerará que todo está bien y el cliente estará insatisfecho. Sucede que el cliente no está contento, incluso si la tarea se completa en 4 horas y 15 minutos. Por lo tanto, incluso si se compila una etiqueta con un término mínimo y máximo dentro del equipo (empresa), y luego se calcula el promedio (hay algún sentido en este enfoque), solo se muestra al cliente el resultado final.

Nombro las fechas solo en horas, no en días o meses.Muchas personas piensan que si el proyecto se estima en 96 horas, se completará en 12 días durante 8 horas, siempre que solo una persona trabaje en él. La situación se extrapola fácilmente a dos desarrolladores, nombrando una calificación de 6 días. Pero esto no es cierto. Hay muchas tareas que dependen unas de otras. En primer lugar, los desarrolladores no pueden comenzar a trabajar hasta que se haya creado una plantilla de proyecto con todos los sistemas de ensamblaje y soportes (y se cree 2-3 días teniendo en cuenta los deseos del cliente). En segundo lugar, todo se detiene cuando hay llamadas para la planificación. En tercer lugar, hay errores de bloqueo que le impiden seguir adelante. En otras palabras, 96 horas en el lugar de trabajo no significa que el 100% del tiempo (8 horas al día) se dedique específicamente a estas tareas. Para la evaluación en días, podemos suponer que el desarrollador no tiene 8, pero, digamos,6 horas de trabajo por día (la cifra exacta debe determinarse a partir de la práctica).

Siempre pregunto a los desarrolladores cuántas horas llevará una tarea desde una computadora (y no "después de cuánto tiempo estará lista"). Esto es una consecuencia del párrafo anterior. Al interactuar con el equipo como parte de la evaluación, es importante formular correctamente la pregunta.

Tomo en cuenta el "coeficiente del equipo".Por lo general, las personas mayores de ayer van a los timbales. Evalúan las tareas en función de su experiencia, incluso si tienen medios en su equipo. Quizás el mayor no trabaja mucho más rápido, pero después de él casi no hay errores. El medio no es de tal calidad. Por lo tanto, en Agile existe el llamado "coeficiente de equipo", que muestra la diferencia entre el optimismo del evaluador y la vida real de un equipo en particular. Se calcula solo en la práctica: se compara una estimación teórica con una real para los últimos sprints. Cuanto mejor conoce el líder del equipo a su equipo (y mejor tiene su mano en la evaluación), más cercano es este coeficiente a 1.

Entre otras cosas, el "coeficiente de equipo" también tiene en cuenta el llamado "optimismo de los desarrolladores" al evaluar. Las tareas siempre se evalúan en función de la ausencia de errores, la saciedad y el buen humor de los artistas, la ausencia de problemas en el medio ambiente. Pero la realidad está repleta de contingencias y no hay forma de protegerse de esto. La "relación de equipo", calculada durante un período de tiempo razonable, permite que esto se tenga en cuenta.

Tratando de establecer la influencia del equipo, a veces en la evaluación interna pasan de horas a puntos de historia. Sabiendo que la tarea tomará 8 puntos de historia, recuerdan que la semana pasada 1 punto de historia costó 8 horas. A partir de esto, predicen los costos laborales. Pero es más fácil para mí pensar en horas.

No introduzco factores adicionales para no confundir a otros participantes en el proceso.A menudo veo personas, realizando una evaluación a nivel de equipo, poniendo tiempo para negociar en ella. Pero la unidad de evaluación no debe establecer este stock o tener en cuenta otras cosas extrañas. Y resulta que el desarrollador calificó la tarea a las 8 en punto, pero multiplicada por 2 por fidelidad. Timlid duplicó su calificación nuevamente, adaptándose al equipo. Y el gerente de 32 horas hizo 40 para el cliente (para una cuenta pareja o simplemente con el objetivo de negociar luego durante 30 horas). Esto es más como adivinar en posos de café. Sí, y el cliente, al ver una estimación de 40 horas para una tarea de 8 horas, decidirá que el equipo no sabe cómo.

Como señalé anteriormente, a nivel de equipo, solo necesita tener en cuenta las características del equipo en sí mismo, acordando quién pone fuerza mayor en la evaluación (y debe tenerse en cuenta allí, ya que siempre evaluamos las tareas, suponiendo que el editor de código no solicite una licencia, los desarrolladores no se encuentre con baja por enfermedad, etc.).

Firmemente defiendo mi defensa de la evaluación. El corolario del párrafo anterior: siempre me mantengo firme en mi evaluación. Si sé que el proyecto se llevará a cabo durante 6 meses y esperan una evaluación de 3 de mi parte, nunca nombraré 4 meses para "complacer" al cliente o gerente.
Cabe señalar que a veces hay negociaciones internas. Cuando sabe que el proyecto debe estar listo para el Año Nuevo, inconscientemente comienza a manipular los resultados de la evaluación para cumplir con el tiempo restante. El cerebro produce estas cosas perfectamente. Incluso si tiene una lista de 200 subtareas allí, entonces convergerán de tal manera que cumplan con la víspera de Año Nuevo.

A pesar de todo esto, estoy listo para que cambie la evaluación. Esto es normal: los proyectos viven, se desarrollan. Al realizar cualquier evaluación, entiendo que esta es una característica del proyecto en este momento en particular.

Y la última palabra de despedida: no obligue a los desarrolladores que no cumplan con los plazos a escribir largas cartas a los gerentes sobre este tema. En primer lugar, es probable que sean tímidos. En segundo lugar, el gerente probablemente preguntará algo y una vez más distraerá. En tercer lugar, su carta de explicación simplemente se perderá en la correspondencia. Normalmente te pido que escribas un comentario sobre una tarea en Jira. Sin la participación de una persona viva (gerente), generalmente es más simple y más rápido. Y durante el informe será fácil de encontrar. Y timlidu plus: se comentarán todas las tareas que estén fuera de lugar. Nuevamente, trabaje en los errores para mejorar la calidad de la evaluación en el futuro.

El autor del artículo: Eugene Wetzel ( @imater )

PD Publicamos nuestros artículos en varios sitios de Runet. Suscríbase a nuestras páginas enCanal VK , FB , Instagram o Telegram para conocer todas nuestras publicaciones y otras noticias de Maxilect.