Una pregunta que me hacen con frecuencia durante las capacitaciones es: “¿Cómo estimamos cuánto tiempo tomará completar la tarea X?” Quiero compartir mi experiencia calculando la cantidad de tiempo que puede tomar una tarea y hablar sobre algunas de las técnicas que he utilizado al estimar el esfuerzo que puede requerir una tarea de análisis de negocios.
¿Por qué deberíamos estimar el tiempo de finalización de una tarea?
Muy a menudo, la frase "esta tarea tomará de cinco a siete días" es percibida por el manager como "estará lista en cinco días". Entonces, ¿cómo puedes mejorar la precisión de tus estimaciones de tiempo?
Primero, debes comenzar a hacer estimaciones, luego monitorear su precisión y finalmente analizar las razones de cualquier desviación de tus expectativas originales. Cuanto más evalúes, mayor será tu precisión (si eres meticuloso en este proceso y sacas conclusiones).
La peor evaluación de tiempo es la que no existe (desde el punto de vista de quienes necesitan estas estimaciones de tiempo como insumo para la planificación). Al hacer una estimación, reducimos la incertidumbre. Incluso si la estimación es aproximada, es mejor que nada.
Métodos de estimación
1. Estimación por analogía
El primer método de evaluación de tiempo es estimar por analogía. Cuando te preguntan "¿cuánto tiempo tomará redactar los requisitos para el subsistema X?", puedes recordar cuánto tiempo te tomó la última vez completar una tarea similar. Este es el método más rudimentario de evaluación.
Su precisión aumenta si trabajas en proyectos similares dentro de un contexto consistente (metodología, lista de stakeholders, equipo de desarrollo, herramientas para gestionar los requisitos).
Por analogía, puedes aumentar la precisión de la evaluación de un problema grande dividiéndolo en partes más pequeñas y luego estimando cada una de ellas individualmente. Este método puede utilizarse cuando tu gerente piensa que el tiempo estimado para realizar una tarea parece demasiado elevado.
Divide la tarea en subtareas, evalúa cada una y podrás convencer al manager de que la estimación inicial era correcta, o tú mismo verás las discrepancias dentro de la previsión. Cuanto más grande sea la tarea, más factores desconocidos habrá y más difícil será estimar el tiempo necesario para cumplirla. Por lo tanto, debemos desglosarla, pieza por pieza.
Por ejemplo, es difícil decir cuánto tiempo tomará preparar un documento de "Visión". Dividamos el documento en secciones, definamos una lista de tareas para cada sección y, como resultado, obtenemos tanto un plan de trabajo como una evaluación general del volumen de trabajo potencial.
2. Estimación paramétrica
El siguiente método es la estimación paramétrica. Por ejemplo, necesitas redactar un SRS (Especificación de Requisitos de Software o Software Requirement Specification en inglés) que contenga 20 casos de uso. Basándote en tu experiencia (¿recuerdas el método de evaluación por analogía?), sabes que redactar un caso de uso toma en promedio un día y medio.
Usando cálculos simples, descubres que puedes redactar todos los casos de uso en 30 días laborales. En este caso, el parámetro es la complejidad de redactar un caso de uso. Este parámetro podría ser el número de formularios de pantalla, procesos de negocio que necesitas describir o el número de entidades al compilar un diccionario de datos, etc.
3. Estimación de tres puntos
La estimación de tres puntos, también conocida como PERT, consiste en determinar estimaciones optimistas, pesimistas y realistas (utilizando cualquiera de los métodos mencionados anteriormente) y luego aplicar la fórmula mágica:
Puntuación = (optimista + pesimista + (4 x realista)) / 6.
En lugar de “4”, puedes sustituir cualquier otro coeficiente, siempre y cuando cambies simultáneamente el valor del denominador.
4. El método Delphi
Se utiliza una evaluación experta si delegas la estimación de tiempo a una persona que pueda realizarla mejor que tú, o si lo haces junto con ella. Pero ¿qué pasa si hay varios expertos? Aquí puede ayudar el método Delphi.
Supongamos que tenemos una lista de tareas y un grupo de expertos que están estimando el tiempo que tomará completarlas. Los expertos evalúan las tareas de manera independiente, se analizan sus calificaciones y, si todos los expertos dan calificaciones iguales o apenas diferentes, obtenemos un resultado consistente.
Si sus estimaciones no son todas iguales, los expertos reciben información sobre las opiniones de los otros especialistas y pueden justificar su propio punto de vista.
Después de esto, se realiza otra ronda de evaluación independiente. Aquellos que trabajan con Scrum dirán: “¡Pero esto es planificación poker!” Sí, la planificación poker en Scrum es una implementación del método Delphi. Usando este método, puedes organizar el trabajo de los expertos en cualquier cuestión, no solo en la evaluación de la intensidad laboral.
Aquí tienes un ejemplo de cómo usar el método Delphi y dividir una tarea en partes. En mi equipo, el número de analistas de negocios variaba entre 3 y 6. Lo principal que estábamos estimando eran las historias de usuario.
Dividimos el trabajo con cada uno en tres actividades: identificación, especificación, y discusión + acuerdo. Antes de la sesión de planificación grupal para las tareas de BA, estimamos de forma independiente la complejidad de cada historia que debemos describir.
Obtuvimos puntuaciones durante la sesión y las comparamos. Si difieren significativamente, discutimos las estimaciones de cada componente, aclaramos la razón de la discrepancia y volvemos a votar.
Si para alguien la tarea es más fácil debido a su experiencia en el tema, entonces esa persona recibe esa historia de usuario y su estimación de la intensidad laboral es aceptada (una implementación suave del principio ‘si estás dispuesto a completar una tarea en un plazo determinado, adelante y demuéstralo’).
5. El método Rolling Wave
Intuitivamente, cuanto mayor sea el volumen de trabajo que estimamos, mayor será la imprecisión. Además, puede haber dependencias entre las tareas que necesitamos estimar. Por ejemplo, hasta que no terminemos la tarea A, es difícil estimar con precisión la complejidad de la tarea B. Sin embargo, se nos pide que evaluemos toda una lista de tareas.
Supongamos que necesitas redactar un documento de "Visión". Has decidido la estructura del documento, definido un plan de trabajo a alto nivel y dado una estimación aproximada de que tomará 35 días. Luego describes en detalle lo que harías durante los próximos cinco días: identificar a los principales stakeholders, formular una declaración del problema y determinar una lista de procesos que debe afectar tu sistema.
Con un esfuerzo increíble, logras terminar tu trabajo dentro de la estimación inicial de cinco días. Pero también te das cuenta en el proceso de que 35 días no serán suficientes para toda la tarea. La experiencia adquirida al interactuar con personas interesadas (o no tan interesadas) y una mejor comprensión de los límites del sistema te permite reevaluar la complejidad del trabajo restante y preparar un plan detallado para los próximos 5-7 días, etc.
Así, este método asume que tienes un plan de alto nivel para el largo plazo y un plan detallado para el corto plazo. El plan de alto nivel se revisa regularmente en función de los logros de los hitos.
La desventaja de este enfoque es que tu estimación inicial puede cambiar significativamente (generalmente hacia arriba). La ventaja es que no pospones la noticia desafortunada de que todo no estará listo a tiempo hasta el final. Esto significa que tu manager puede tomar medidas preventivas o correctivas.
Cuantas más veces recorras el camino de dar una estimación, completar el trabajo, comparar el plan con el ya hecho y analizar las razones de las discrepancias, mejor podrás evaluar la complejidad de tu trabajo futuro.
"Bailando con Osos"
Cuando hablo de planificación, pienso en el libro de De Marco "Bailando con Osos". Tiene el siguiente gráfico:
En el eje X están las fechas, donde la fecha N es el tiempo que nos llevará completar el proyecto si todo va bien. Y en el eje Y está la probabilidad de que el proyecto se complete. Dado que tenemos muchos riesgos, la probabilidad de cumplir con el plazo es bastante baja.
Cuantas más veces pases por el ciclo anterior, mejor comprenderás los riesgos que puedes enfrentar y, por lo tanto, qué ajustes aplicar a tus estimaciones de tiempo.
En uno de mis proyectos, la identificación de este problema se abordó sistemáticamente. JIRA acumulaba datos sobre las estimaciones iniciales de la complejidad de las tareas y el tiempo que finalmente se tardó en completarlas.
Dos meses después resultó que, al evaluar la intensidad laboral, en promedio, mis colegas subestimaban consistentemente el tiempo necesario en un 25%. Al aplicar el coeficiente adecuado al planificar, pudimos reducir el número de horas extras forzadas y cumplir más frecuentemente con los plazos que habíamos previsto para nuestro cliente.
Evalúa, toma en cuenta los riesgos y elige técnicas adecuadas para tu proyecto.
El artículo fue publicado originalmente aquí.
*Gobov ha sido reconocido dos veces por los “Premios IT de Ucrania” como el mejor analista de negocios del país (2013 y 2016). También es el primer analista ucraniano que ha aprobado exámenes de certificación de organizaciones líderes en análisis de negocios e ingeniería de requisitos, como CBAP (IIBA), PMI-PBA (PMI) y CPRE (IREB).
