“¿Cuánto tardaréis en hacer esto?”
¿Cuántas veces te han hecho esta pregunta? Oh, venga, confiesa cuántas de ésas has estado tentado de decir “Bueno, en mi bola de cristal puedo ver…” pero finalmente has pensado “Bah, no tengo ni idea… pero debo dar una respuesta” o incluso mejor “No tengo ni idea… pero debo dar una respuesta más asertiva”. Te ayudaré con éso.
Necesidades
Primero necesitas entender la razón por la cuál la persona hace esa pregunta.
Algunas veces se trata de alguien que necesita conocer una aproximación del tiempo que se tardará en tener disponible el resultado de esa tarea porque debe organizarse a sí misma o porque debe ayudar a organizarse a otra gente. Por ejemplo, una product manager que debe coordinar a varios equipos para una campaña de marketing.
También puede suceder que la pregunta venga de un dueño de producto para los desarrolladores en el contexto de una reunión de refinamiento. En esos casos, normalmente la necesidad es dar la prioridad adecuada a esa historia de usuario.
Otra situación típica surge cuando debemos hacer un presupuesto, quizás para un proyecto o incluso para un período. Es fácil pensar que si predecimos el tiempo que tardaremos en cada tarea podremos predecir el coste de ese proyecto o el número de proyectos que podremos abordar durante ese período a presupuestar.
Si la pregunta no está relacionada con ninguna de las situaciones anteriores, normalmente está relacionada con algo más emocional. En su inmensa mayoría se trata de impaciencia. Quizás debida a una larga espera o a la presión recibida de otros (más arriba en la jerarquía, que también están impacientes).
Antes de seguir, piensa en qué respuesta podrías dar en cada una de las situaciones anteriores.
Respuesta
Para las primeras situaciones parece que nuestro interlocutor tiene argumentos racionales para solicitarnos esa fecha. Para los últimos, sin embargo, puedes responder amablemente:
“Si realmente necesitas una fecha te la daré, pero si no, la experiencia muestra que es mucho mejor no acelerarse. Escucha, nosotros estamos comprometidos con hacer nuestro trabajo lo mejor y más rápido que podamos, para entregar a tiempo y con la más alta calidad. Para darte una fecha necesitamos detener nuestro trabajo en curso y preparar esa estimación que nos pides, con lo que retrasaremos más aún la entrega de nuestro trabajo en curso y de todo el que está esperando. ¿Aún necesitas esa fecha?”
Si aun así insisten en tener una fecha, todavía podemos rechazar el darles una adivinación, es decir, una estimación basada en una suposición. Yo sugiero usar este término para ayudarles a entender mejor el impacto de su petición: están deteniendo tu trabajo para hacer una actividad que no está relacionada con una necesidad real, y además el resultado será simplemente una suposición no basada en datos, es decir, apenas una opinión. Otro impacto que pueden traer estas peticiones de adivinación es que la gente interrumpida frecuentemente se siente obligada a dar estimaciones optimistas, la mayoría de las veces debido a emergencias en el lado del peticionario. Así que estamos incrementando las probabilidades de dar un número que no encajará con la realidad, normalmente impactando en otros porque ellos gestionarán sus expectativas basándose en información imprecisa.
Por otro lado, para aquellos que realmente sí necesitan una fecha, ésta es la respuesta, asumiendo que estás haciendo Kanban (o midiendo el número de tareas/historias que entregáis y el tiempo que empleáis en cada una).
“Bien, para darte una fecha necesitamos detener nuestro trabajo en curso y preparar una estimación para ti. Consiste en una simulación estadística que pronosticará las fechas que pides basadas en nuestro comportamiento pasado y que depende de nuestra regularidad.”
Estoy bastante seguro de que algunas dudas han surgido en tu cabeza ahora mismo. “¿Qué pasa si mi equipo no es predecible, es decir, si no es regular? ¿Y qué sucede si mi equipo no tiene comportamiento pasado? ¿Cómo demonios puede una simulación dar una estimación en la que yo pueda confiar mejor que en la opinión del equipo?”. De acuerdo, como diría Jack El Destripador: “Vayamos por partes“.
Show me the data
Primero, veamos los datos que estamos recogiendo y cómo los podemos usar para ver si somos predecibles o no. En eDreams ODIGEO, todos los equipos a los que acompañamos en la transformación ágil están haciendo Kanban y usan JIRA para visualizar, gestionar y medir su trabajo. De esta manera, y con la ayuda de un plugin llamado EazyBI (y aunque tiene una UI más mala que un dolor), podemos ver gráficos muy útiles como los que te voy a enseñar a continuación.
Empecemos por este run-chart con las tareas entregadas por un equipo (de hecho, se trata de una agregación de varios equipos) y su correspondiente customer lead time (el tiempo empleado por el equipo correspondiente desde que se comprometieron a trabajar en la tarea hasta el momento en que la entregan). En principio sólo verás una nube de puntos.
¿Puedes ver aquí algún patrón? Seguro que sí, algunos huecos vacíos y yo diría que también muchos defectos (bugs), pero también podrás ver que la mayoría de esas tareas se terminaron en menos de 50 días. De hecho, esto último podemos verlo mucho mejor con otro gráfico.
Aquí podemos ver que el 85% de las tareas entregadas la última semana, tardaron 60 días o menos desde que se comprometieron a trabajar en ellas. Este gráfico también muestra aquellos huecos vacíos (semanas en las que no se entregó nada) que ya vimos en el run-chart, pero también nos permite ver la variabilidad en el trabajo realizado. Si simplemente ignoramos los huecos, entonces veremos algo un poco más estable, alrededor de 50 días. Como ya se intuía en el run-chart.
Te enseño estos gráficos porque quiero que entiendas primero la importancia de la regularidad en la entrega de trabajo acabo cuando damos una estimación, y también para mostrarte cómo podemos usarlos para ayudar a un equipo a entender su comportamiento. En otro artículo podemos comentar sobre cómo mejorar usando estos gráficos. Ahora te enseñaré cómo responder a La Gran Pregunta.
¿Cuánto tardaréis en hacer esto?
Éste es el punto donde vamos a introducir las simulaciones de Monte Carlo (también lo verás escrito como “método de Montecarlo“). Éste es un buen artículo (en inglés) que puedes leer para entender esta técnica en profundidad. Mi propósito ahora es simplemente mostrarte cómo puedes usarlo para responder a La Gran Pregunta con muy poco esfuerzo.
Últimamente, en eDreams ODIGEO estamos usando estas hojas de cálculo (creadas por Troy Magennis) para lanzar las simulaciones. Ahora, además, tenemos esta otra versión casi a estrenar. Está en Google Drive y apenas necesitas hacer una copia, compartirla con tu equipo y demás gente interesada, y comenzar a colaborar. (Por cierto, por favor, si la usas me gustaría tener tu feedback porque así me comprometí con el autor).
Google sheets version of forecasting spreadsheet. Open & save your own copy. #StillTesting Thx. @jmbeas for help https://t.co/SExfdvuxsw
— Troy Magennis (@t_magennis) November 9, 2016
¿Cómo puedes ejecutar tu pronóstico? Simplemente abre y guarda tu copia de la hoja de cálculo. Entonces puedes ir a la pestaña “Forecast” (Pronóstico) y rellenar el dato según tu caso.
Imagina que tienes un backlog con 12 historias en él, y que quieres saber cuándo tu equipo terminará la última. Entonces rellenas el campo “Start Date” (Fecha de inicio) con la fecha de hoy (pon atención al formato de fecha, en mi caso es MM/DD/YYYY) y a la pregunta “2. How many stories are remaining to be completed?” responde 12 en los dos campos (“Lowest guess” / “Highest guess”).
Olvidemos el resto de campos por ahora y vayamos a la sección “4. Throughput” (Producción). En este punto necesitarás saber cuántas historias estáis entregando cada semana. Este métrica es conocida como throughput. Ve entonces a la pestaña “Throughput samples” (Muestras de producción) y rellénala con los datos de tu equipo. Cuantos más datos históricos tengas, mejor, aunque te sorprendería qué pocos ejemplos se necesitan para obtener una simulación con suficiente precisión.
Si no tenéis datos históricos, aún puedes hacer tu pronóstico seleccionando “Estimate” (Estimación). Por supuesto, estará basada en suposiciones. La hoja de cálculo te permite dar un rango para simular vuestra variabilidad.
En la sección “Results” (Resultados), a la derecha, tendrás una tabla con las fechas de finalización (número de semanas) del último item de tu backlog (recuerda, en nuestro ejemplo la decimosegunda historia) y la probabilidad de que ésta sea entregada en esa fecha. Echa un vistazo a este artículo sobre el burn-up chart y seguro que te será fácil dibujar tus pronósticos en una gráfica. Prueba a poner en la misma gráfica el mismo pronóstico para probabilidades diferentes.
Pulsa en la imagen para ver los detalles. Hay muchas más opciones, pero este artículo ya es bastante largo. Si quieres que profundice, dímelo en los comentarios de ahí abajo. 🙂
Sin embargo, antes de acabar, quiero compartir contigo un pensamiento final. Si trabajas para tener un flujo estable, es decir, un throughput con pocas variaciones (ritmo sostenible) y los datos son fiables (autodisciplina), entonces tus pronósticos serán bastante precisos. En cualquier caso, seguro que has oído alguna vez ese lema que dice “Rendimientos Pasados No Garantizan Resultados Futuros”. Un pronóstico sigue siendo éso: un pronóstico, es decir, un intento de predecir el futuro basado en comportamientos pasados, pero en ningún caso es una garantía.