La conversación suele empezar con una pregunta razonable: ¿cuándo creen que puede estar?
El equipo todavía no conoce todos los detalles. Hay decisiones técnicas pendientes, alguna dependencia externa y partes del problema que recién va a comprender cuando empiece a trabajar. Sin embargo, necesita responder. Analiza lo que sabe, compara con experiencias anteriores y hace una estimación: probablemente unas seis semanas.
Alguien anota la fecha. Unos días después aparece en un roadmap. Más tarde, en una presentación. Quizás alguien la utiliza para organizar una campaña, coordinar otro equipo o hablar con un cliente. Hasta que, en algún momento, vuelve a Ingeniería convertida en algo ligeramente diferente:
—Recuerden que nos comprometimos para el 15.
Es difícil identificar el momento exacto en que ocurrió la transformación. Ingeniería había intentado expresar cuánto creía que podía llevar un trabajo todavía incierto. La organización recibió una fecha alrededor de la cual podía empezar a tomar decisiones.
La estimación se convirtió en una promesa.
Este conflicto es tan habitual en desarrollo de software que construimos alrededor suyo toda una colección de explicaciones: Negocio no entiende cómo funciona Ingeniería, los developers no saben estimar, Producto compromete fechas sin consultar, Ingeniería siempre se cubre. Todas pueden contener algo de verdad, pero probablemente describan síntomas de un problema más interesante.
Porque cuando una organización convierte sistemáticamente las estimaciones en compromisos, los equipos aprenden. Y empiezan a protegerse.
El nacimiento del colchón
Supongamos que un equipo analiza un desarrollo y considera que, con la información disponible, podría llevar alrededor de seis semanas. También sabe que aparecerán problemas que todavía no puede anticipar, que alguna dependencia puede demorarse y que ciertas decisiones técnicas pueden resultar más difíciles de lo esperado.
Pero sabe algo más: conoce a su propia organización. Sabe que la fecha que diga probablemente será recordada más adelante como un compromiso.
Entonces hace algo perfectamente comprensible: agrega margen. Las seis semanas se convierten en ocho.
No necesariamente porque el equipo quiera trabajar menos ni porque intente engañar a nadie. Está tratando de incorporar incertidumbre a una conversación que, por experiencia, sabe que después tenderá a olvidar que esa incertidumbre existía. El colchón funciona como una especie de seguro: si todo ocurre como estaba previsto, sobrará tiempo; si aparece alguno de los problemas que todavía no puede anticipar, habrá margen para absorberlo sin incumplir la fecha.
La estrategia parece prudente. El problema aparece cuando esas ocho semanas dejan de representar una estimación protegida y se convierten en el tiempo disponible para hacer el trabajo.
El trabajo también mira el calendario
Cyril Northcote Parkinson formuló originalmente su conocida ley en un ensayo satírico sobre la administración pública: el trabajo tiende a expandirse hasta ocupar el tiempo disponible para realizarlo (Parkinson, 1961). No hace falta convertir la ley de Parkinson en una regularidad física para reconocer algo valioso en la observación.
Si un equipo dispone de dos semanas para resolver un problema, toma determinadas decisiones. Si dispone de seis, puede tomar otras. Puede investigar una alternativa adicional, refinar una arquitectura, extender una discusión, ampliar el alcance, resolver una deuda técnica relacionada o postergar una decisión que, bajo una restricción temporal mayor, habría tenido que cerrar antes.
El tiempo disponible, entonces, no solamente contiene el trabajo. También puede influir sobre la manera en que ese trabajo se realiza.
Por eso el colchón tiene una propiedad problemática: una vez incorporado públicamente a la estimación, deja de ser completamente un colchón. Pasa a formar parte del horizonte normal dentro del cual el equipo organiza su actividad.
Las seis semanas que el equipo creía necesitar se convirtieron en ocho para protegerse de la incertidumbre. Pero ahora el equipo dispone de ocho semanas, y es perfectamente posible que termine utilizándolas.
Cuando eso ocurre aparece un fenómeno particularmente interesante. La organización observa el resultado y concluye que la estimación era correcta: tardaron ocho semanas. El equipo observa exactamente el mismo resultado y puede llegar a una conclusión igualmente razonable: menos mal que agregamos margen, porque finalmente necesitamos las ocho semanas.
Los dos encuentran evidencia para confirmar aquello que ya creían. Y el sistema queda preparado para repetir el comportamiento.
Estimar un futuro que todavía no existe
Sería cómodo resolver el problema diciendo que Ingeniería debería estimar mejor. Sin embargo, hay una dificultad más profunda: cuando estimamos un desarrollo de software estamos intentando anticipar el resultado de un trabajo que, precisamente porque todavía no fue realizado, contiene información que todavía no tenemos.
Herbert Simon estudió este problema mucho más allá del software. Su concepto de racionalidad limitada parte de reconocer que las decisiones reales ocurren bajo restricciones: no conocemos todas las alternativas, no podemos anticipar completamente sus consecuencias y nuestra capacidad para procesar información también es limitada (Simon, 2011).
Una organización no puede esperar a tener información perfecta para decidir. Si lo hiciera, muchas decisiones solo podrían tomarse cuando ya fuera demasiado tarde para que fueran útiles. Ingeniería enfrenta una dificultad parecida: tampoco puede conocer completamente un desarrollo antes de hacerlo.
Hay algo casi paradójico en exigir precisión absoluta sobre un trabajo de conocimiento. Si pudiéramos describir anticipadamente cada problema que vamos a encontrar, cada decisión que habrá que tomar y cada solución necesaria para construir un sistema, una parte significativa del trabajo ya estaría hecha.
Estimar, por lo tanto, no consiste en descubrir una fecha que está escondida en algún lugar esperando que alguien suficientemente competente la encuentre. Consiste en producir una expectativa razonable utilizando información necesariamente incompleta.
El problema es que la organización necesita hacer algo con esa expectativa. Tiene que coordinar equipos, asignar presupuesto, ordenar prioridades, gestionar dependencias, planificar lanzamientos o hablar con clientes.
La incertidumbre de Ingeniería se encuentra entonces con la necesidad organizacional de decidir. Y una distribución de posibilidades termina convertida en una fecha.
Además, somos malos imaginando cuánto tardaremos
La incertidumbre no es el único problema. Daniel Kahneman describe, a partir del trabajo desarrollado junto con Amos Tversky, la falacia de la planificación: nuestra tendencia a construir previsiones demasiado cercanas a escenarios favorables y a subestimar cuánto demorarán los proyectos, incluso cuando existe experiencia previa que debería advertirnos lo contrario (Kahneman, 2012).
Cuando pensamos cuánto llevará un desarrollo solemos mirar hacia adentro del problema. Hay que modificar este servicio, construir esta pantalla, integrar aquella API y hacer determinadas pruebas. Construimos mentalmente una historia razonable sobre cómo debería desarrollarse el trabajo.
Lo que entra con más dificultad en esa historia es precisamente aquello que todavía no conocemos: la reunión que habrá que repetir, la dependencia que no estaba documentada, el comportamiento inesperado del sistema existente, la persona que estará de vacaciones, la decisión que parecía tomada y habrá que discutir nuevamente.
La estimación enfrenta entonces una dificultad doble. No solamente intentamos conocer un futuro incierto; además, tenemos sesgos que pueden llevarnos a imaginar ese futuro con demasiado optimismo.
Agregar margen parece, nuevamente, una respuesta razonable. Y volvemos al mismo lugar, porque una vez que ese margen se convierte en tiempo disponible puede empezar a ser consumido.
Entonces aprendemos a negociar
Después de suficientes iteraciones ocurre algo todavía más profundo. Negocio descubre que Ingeniería agrega colchón, e Ingeniería descubre que Negocio sabe que agrega colchón.
La conversación cambia.
Imaginemos que un equipo considera que determinado trabajo probablemente lleve cuatro semanas. Sabe, sin embargo, que cualquier número que comunique puede convertirse después en un compromiso, así que dice seis. Quien recibe la estimación también tiene experiencia y sabe que Ingeniería suele protegerse frente a la incertidumbre, por lo que responde preguntando si realmente no podrían hacerlo en cinco.
La próxima vez el equipo recuerda que sus seis semanas fueron negociadas hasta cinco. Frente a un trabajo similar ya no tiene incentivos para decir seis: quizás diga siete.
Cada actor está respondiendo razonablemente al comportamiento que espera del otro. El problema es que la naturaleza de la conversación cambió.
Ya no estamos estimando. Estamos negociando.
Y seguimos llamando estimación al número que aparece al final.
Esto deteriora algo más importante que la precisión de una fecha: deteriora la calidad de la información que circula por la organización. Cuando un equipo dice seis semanas queriendo decir cuatro más protección, la organización ya no sabe qué representan realmente esas seis semanas. Cuando un stakeholder pide cuatro esperando obtener cinco, Ingeniería tampoco sabe cuál es la verdadera restricción del negocio.
Ambos empiezan a comunicarse estratégicamente. Cada uno modifica la información que entrega anticipando qué hará el otro con ella.
El mecanismo puede estabilizarse e incluso producir la sensación de que funciona. Los proyectos reciben fechas, los roadmaps se completan y las negociaciones terminan en algún número aceptable para ambas partes.
Pero ese equilibrio tiene un costo.
El costo invisible
Supongamos que un equipo podría completar razonablemente cierto conjunto de trabajos en cuarenta semanas efectivas a lo largo del año. Para protegerse de la incertidumbre, incorpora sistemáticamente un veinte por ciento de margen a sus estimaciones.
Si ese margen funcionara verdaderamente como reserva, no habría necesariamente un problema. Algunos proyectos consumirían parte de él, otros no, y la variabilidad tendería a compensarse. El colchón cumpliría la función para la cual fue creado.
Pero si el tiempo asignado modifica también la manera de realizar el trabajo, una parte de ese margen puede dejar de funcionar como protección y convertirse en capacidad consumida.
Ese costo es particularmente difícil de observar. No aparece en ningún presupuesto como un gasto extraordinario, no genera un incidente y probablemente tampoco produzca una alerta en ningún dashboard. Simplemente hacemos menos cosas con la misma cantidad de personas.
Y después intentamos resolver el problema de capacidad contratando más personas.
La paradoja es considerable: creamos colchón porque queremos proteger nuestros compromisos y podemos terminar reduciendo la capacidad de la organización para cumplirlos.
Esto no significa que todos los proyectos vayan a consumir inevitablemente todo margen disponible. La ley de Parkinson nació como una observación satírica, no como una ley física. Pero nos obliga a formular una pregunta que muchas conversaciones sobre estimación omiten: ¿qué efecto produce sobre el comportamiento del equipo el tiempo que le asignamos?
Una estimación no ocurre fuera del sistema que intenta describir. Una vez comunicada, entra en él.
Poner más personas tampoco arregla necesariamente el problema
Cuando una fecha empieza a correr peligro aparece otra respuesta conocida: agreguemos gente.
Fred Brooks mostró hace décadas por qué en desarrollo de software esa relación no es lineal. Incorporar personas a un proyecto atrasado puede retrasarlo todavía más porque aparecen costos de incorporación, comunicación y coordinación; además, no todas las tareas pueden dividirse arbitrariamente entre más personas (Brooks, 1995).
La observación de Brooks completa una imagen incómoda. No podemos conocer perfectamente cuánto llevará el trabajo; agregar margen puede modificar cuánto termina llevando y, si nos atrasamos, tampoco podemos asumir que agregar capacidad reducirá proporcionalmente el tiempo.
La relación entre personas, trabajo y tiempo es bastante menos mecánica de lo que nuestros planes suelen sugerir.
Sin embargo, necesitamos planificar.
Ese es el problema real.
La organización necesita fechas
Sería fácil terminar el argumento diciendo que debemos dejar de pedir fechas. También sería una respuesta bastante infantil.
Las organizaciones necesitan coordinar el futuro. Hay contratos, presupuestos, campañas, dependencias, regulaciones, clientes, otros equipos, decisiones de inversión y personas que necesitan actuar hoy sobre cosas que ocurrirán mañana.
Un equipo puede convivir durante algún tiempo con la frase “todavía no sabemos”. Una organización completa, muchas veces, no.
El problema, entonces, no es que la organización quiera fechas. El problema aparece cuando intentamos satisfacer esa necesidad fingiendo que tenemos un grado de certeza que en realidad no poseemos. Y aparece también cuando Ingeniería responde a esa presión escondiendo la incertidumbre dentro de estimaciones infladas.
En ambos casos perdemos información.
Estimación, compromiso y límite no son lo mismo
Quizás parte del problema sea que utilizamos una fecha para responder preguntas diferentes.
Preguntar cuánto creemos que puede llevar es una pregunta sobre estimación. Preguntar para cuándo necesitamos tenerlo expresa una necesidad del negocio. Preguntar cuánto tiempo estamos dispuestos a invertir antes de reconsiderar la solución establece un límite. Y preguntar qué podemos comprometernos razonablemente a entregar abre una conversación sobre compromiso.
Las respuestas pueden coincidir, pero no tienen por qué hacerlo.
Si Ingeniería estima ocho semanas y el negocio necesita algo en cuatro, discutir inmediatamente si la estimación “puede bajarse” quizás sea empezar por el lugar equivocado. La diferencia entre ambos números contiene información.
Tal vez haya que reducir alcance. Tal vez exista otra solución. Quizás haya una parte que permita capturar valor antes. Puede haber incertidumbres que podamos despejar rápidamente o dependencias que podamos eliminar. También puede ocurrir que la fecha de cuatro semanas no sea realmente una restricción, sino simplemente una preferencia que nunca fue explicitada como tal.
La conversación interesante empieza cuando dejamos de negociar el número y tratamos de entender qué representa.
¿Qué parte del alcance genera valor? ¿Qué podemos aprender antes? ¿Qué alternativa cabe dentro del tiempo disponible? ¿Qué ocurre realmente si tardamos ocho semanas? ¿Qué decisión necesita tomar hoy la organización y qué información necesita para tomarla?
Separar estas preguntas no elimina la incertidumbre. Pero evita esconderla dentro de una cifra.
El problema no está en la estimación
Cuando miramos solamente el último número es tentador buscar al culpable. Ingeniería estima mal, Producto presiona demasiado, Negocio no entiende software o algún manager prometió algo que no debía.
Pero el mecanismo que describimos puede funcionar incluso cuando todos intentan hacer razonablemente bien su trabajo.
La organización necesita una fecha e Ingeniería sabe que existe incertidumbre. Para protegerse frente a aquello que todavía no conoce, el equipo incorpora margen a su estimación; pero la organización recibe ese número como un compromiso y organiza sus decisiones alrededor de él. Una vez convertido en tiempo disponible, el margen puede empezar a ser consumido por el propio trabajo. Cuando la organización descubre que las estimaciones contienen ese colchón, comienza a presionarlas; Ingeniería anticipa esa presión y, la próxima vez, tiene todavía más razones para protegerse.
En algún momento dejamos de intercambiar información sobre el trabajo.
Empezamos a intercambiar posiciones.
Quizás ese sea el verdadero problema. No que alguien esté estimando mal, sino que construimos un sistema en el que todos tienen buenos motivos para distorsionar la información.
Arreglarlo requiere algo bastante más difícil que encontrar una técnica de estimación mejor. Requiere construir una organización donde decir “no sabemos todavía” no sea equivalente a no hacerse responsable; donde una estimación pueda cambiar sin que eso signifique que alguien incumplió su palabra; donde una necesidad real de negocio pueda expresarse como una restricción explícita en lugar de esconderse detrás de una negociación sobre números; y donde Ingeniería pueda reconocer la incertidumbre sin utilizarla como justificación para incorporar márgenes que después se convierten silenciosamente en capacidad consumida.
Porque necesitamos fechas y también necesitamos reconocer la incertidumbre. Ninguna organización puede prescindir completamente de una de las dos.
La madurez quizás no consista en elegir entre certeza e incertidumbre.
Consiste en aprender a trabajar con ambas sin mentirnos.
Referencias
Brooks, F. P., Jr. (1995). El mítico hombre-mes: Ensayos acerca de la ingeniería de software (ed. aniversario).
Kahneman, D. (2012). Pensar rápido, pensar despacio. Debate.
Parkinson, C. N. (1961). La ley de Parkinson y otros estudios de administración. Ariel.
Simon, H. A. (2011). El comportamiento administrativo. Errepar.