La futilidad de estimar problemas complejos
Por qué no deberías creerte las estimaciones. Diferencia entre problemas sencillos y complejos. Ventajas y riesgos del proceso de estimación.
Hay un dicho popular en la subcultura de producto e ingeniería de software que viene a decir algo así como “estimar es timar”. Tras llevar más de 20 años en el sector, puedo decir que no le falta razón.
Estudié ingeniería informática allá por el año 2000. Por aquel entonces, te enseñaban a gestionar un desarrollo de software como a quién construye una casa.
Primero limpias el terreno
Luego excavas para poner los cimientos
Construyes la estructura
Añades las tuberías
Etc…
Aparentemente tiene sentido. Si sabes lo que hay que hacer, y cuánto cuesta hacer cada cosa, puedes llevártelo a un excel o un Gaant chart y tener una idea aproximada de cuándo tendrás tu casa. Y así con las siguientes 100 casas.
Luego, claro, te enfrentas al mundo real creyendo que puedes hacer software como quién construye chalets y te das cuenta de que el universo no es tan predecible como te lo habían pintado.
La raíz del problema es que construir una casa es un problema sencillo, mientras que construir software es, en la mayoría de los casos, un problema complejo.
Diferencias entre un problema sencillo y uno complejo
David Snowden es una de las referencias en el mundo de la ciencia de la complejidad, es conocido por ser el creador de Cynefin, un framework para orientarnos en la resolución de problemas.
A modo de resumen, Cynefin define cinco dominios en los que puede existir un problema, dónde cada uno de ellos requiere de una aproximación distinta. Dos de ellos son los dominios sencillos y complejos.
Construir una casa es un problema del dominio sencillo en el que los humanos tenemos, literalmente, miles de años de experiencia. Los pasos a seguir son claros, definidos, dan lugar a pocas sorpresas, y cuando una de estas se da, generalmente es fácil encontrar una solución porque no vas a ser el primero al que le ocurra.
Desarrollar software por el contrario generalmente es un problema del dominio complejo. Salvo que trabajes en una consultora en la que básicamente haces el mismo trabajo para el mismo tipo de cliente una y otra y otra vez, al desarrollar cualquier producto que valga la pena, probablemente te enfrentes a problemas totalmente nuevos sobre el que no hay un cuerpo de conocimiento sólido en el que te puedas apoyar.
Las soluciones a estos problemas no se diseñan como quién diseña los pasos para construir una casa, porque literalmente no sabes lo que te vas a encontrar. Las soluciones a los problemas complejos emergen de las interacciones del sistema a base de prueba y error, no se pueden anticipar de antemano. Literalmente te enfrentas a lo desconocido.
Y sin embargo, todavía hoy nos seguimos engañando pensando que podemos estimar un desarrollo de software como quién estima construir una casa.
El problema de las estimaciones
En el momento entiendes que el desarrollo de software es un problema complejo, tu confianza en las estimaciones cae fuertemente. Tratar de estimar un problema complejo es un acto de funambulismo.
Me gusta poner el ejemplo de un mecánico al que acudes con un problema en el motor de tu coche y al que le exiges que te de un presupuesto sin abrir el capó. Obviamente, ninguno lo haría. O lo que es peor, te daría el presupuesto más alto posible para cubrirse las espaldas.
Cuando le pedimos a un ingeniero de software que estime una historia de usuario, en muchas ocasiones estamos actuando como con el mecánico. Les pedimos que estimen sin darles tiempo a mirar el motor. Y luego queremos pretendemos que las estimaciones se cumplan.
Cuando los años de experiencia te llevan a entender este aspecto, la siguiente revelación viene cuando descubres que la única forma de estimar correctamente una tarea compleja es haciéndola. Es decir, el tiempo para estimarla con un 100% de certidumbre, equivale al tiempo que cuesta resolverla.
Y entonces te das cuenta de la futilidad de estimar en la mayoría de los casos. Y en que el desarrollo de software se parece más a crear una sinfonía que a construir un edificio. El desarrollo de software es más arte que ciencia.
Siguiendo ese razonamiento, en la mayoría de ocasiones, estimar es irrelevante para el éxito de un producto. En muchas ocasiones no es más que una herramienta de autoengaño que utilizamos para simular que tenemos el control y poder dormir más tranquilos por las noches.
Las ventajas de estimar
Si has llegado hasta aquí, verás que mi confianza en las estimaciones es baja, y por lo tanto, no me suelo guiar mucho por ellas.
Sin embargo, para equipos y perfiles junior el acto de estimar tiene ciertas ventajas, siempre que no te creas demasiado el resultado de las mismas.
La principal ventaja es que, mientras no se pierda demasiado tiempo, el ritual de estimación es un buen momento para detectar qué historias o funcionalidades son más o menos complejas.
Todas aquellas estimaciones bajas podemos asumir que son problemas del tipo sencillo en los que el equipo ya tiene cierta experiencia resolviendo. Estas estimaciones sí son creíbles. El problema es que no son relevantes para el devenir del proyecto.
En las estimaciones altas es dónde se revela la incertidumbre. Cuando una de estas aparece, presta atención, porque probablemente se trate de un problema complejo al que el equipo no se ha enfrentado antes y, por tanto, no tiene experiencia en resolver.
Y precisamente porque no tienen experiencia no te puedes creer la estimación. Una semana puede ser un día o un mes. Porque hasta que el ingeniero no se pone realmente con la tarea, hasta que no abre el capó y descubre lo que se va a encontrar, la realidad es que no lo puede saber.
Paradójicamente, estas tareas, inestimables de antemano, son las que en realidad definirán el éxito del proyecto.
Pero volviendo a las ventajas. La ventaja no es obtener un número que te puedas creer y calendarizar. La ventaja es descubrir durante la estimación estas tareas de alta incertidumbre de forma que puedas reaccionar.
A lo mejor descubres que un detalle que considerabas menor es un problema complejo. Es el mejor de los escenarios porque simplemente puedes eliminarlo, como quién quita un espejo del diseño de un cuarto de baño.
En el peor de los casos, el más habitual cuando haces software que merece la pena, descubrirás que el mayor grado de incertidumbre se concentra en el kernel del producto. Precisamente la tarea es valiosa porque nadie la ha hecho antes, y ahí es dónde nace la incertidumbre. Y también donde se encuentra la recompensa.
En estos casos, casi con total seguridad necesitarás dedicar tiempo a tratar de simplificar la consecución de tu objetivo. Si lo que quieres hacer resulta muy complicado, ¿hay formas de validarlo de forma más sencilla? Generalmente tendrás que dividir el problema en subproblemas más pequeños que el equipo pueda desarrollar y validar de forma iterativa.
Otra de las ventajas de estimar es la conversación entre los distintos miembros del equipo durante el proceso. Esto en equipos juniors es importante porque ayuda a que todos los integrantes del mismo se vayan empapando del sistema a través de esas discusiones.
¿Estimar o no estimar?
Como casi siempre, depende. Cuánto más junior sea un equipo, más valioso será el proceso de estimación. Cuánto más reciente sea la creación del equipo, puede que también.
Estimar sólo tiene un par de riesgos:
Creerse las estimaciones
El tiempo que se pierde estimando
Mientras no te creas demasiado las estimaciones por todo lo que he comentado en este artículo, estimar no te hará demasiado daño. Puede que hasta te beneficie.
El otro riesgo es que el proceso de estimación sea muy poco productivo, de forma que se pierda demasiado tiempo en estimar algo que, por lo que ya hemos comentado, tiene poco valor real.
Mientras seas consciente de que las estimaciones son altamente volátiles y no pierdas demasiado tiempo en el proceso, puedes estimar.
La alternativa, el nirvana, es tener ciclos de desarrollo lo más pequeños posibles que te permitan iterar y corregir el rumbo paso a paso. Cuando el máximo tiempo posible qué vas a invertir haciendo cualquier tarea es pequeño, estimar es irrelevante. Todo el tiempo que te ahorras haciéndolo, puedes dedicarlo a probar y experimentar.
Este método de prueba/error, es precisamente la clave para resolver problemas complejos. De hecho, es la base misma de la ciencia, y la forma en la humanidad lleva avanzando durante toda su historia.
Edison, Tesla, Curie, Pasteur, los hermanos Wright… los mayores científicos e inventores de la historia han sido artesanos avanzando experimento a experimento, haciendo pequeños ajustes y comprobando qué cambiaba respecto a la iteración anterior.
Para hacer productos de éxito tienes que ser como ellos. Aceptar la incertidumbre, y adoptar formas de trabajo que permitan reducirla, acortando los ciclos de desarrollo y simplificando procesos.
Edison probó 10000 formas distintas hasta llegar a inventar la bombilla. ¿Hubiera sido capaz de anticipar cuántos intentos necesitaría para descubrirla? ¿Frenó eso a Edison? Afortunadamente no, porque Edison entendía la naturaleza del problema.
Cada vez estoy más convencido de que el desarrollo de software encaja en la definición de un sistema complejo no lineal, tal y como define la Teoría del Caos; principalmente porque las soluciones se construyen sobre abstracciones cada vez más complicadas y cualquier problema sobre las mismas resulta imposible de predecir y estimar de forma fiable.