Las estimaciones no son para tomarse como última palabra, firmadas en sangre, un juicio final. Deben ser vistas como una guía para conocer el rumbo de un proyecto.
Deben ser creadas en entornos donde haya suficiente información para realizarlas, con el suficiente espacio y análisis para intentar sacar a luz los imprevistos(que siempre los habrá).
Aceptar la incertidumbre que existe al crear software. Todos los involucrados deben saber que existe y aceptarla. Cuando esto ocurre saldrán soluciones para abordar los problemas a encontrar al desarrollar un software.
Cuando se aceptan las estimaciones como algo concreto, que no está expuesto a factores externos que afecten el normal de desarrollo todos salen perjudicados. Pero quien más sale perjudicado es el desarrollador:
Cliente frustrado porque no se entregó X a tiempo que se dijo
Jefe frustrado porque no se están cumpliendo los tiempos y el cliente demuestra el descontento
Gestor de proyectos frustrado porque no le están cumpliendo los tiempos y el jefe y el cliente le demuestran su descontento
Desarrollador cansado de trabajar horas extras, tener que enfocarse en cantidad y no en calidad, gestor de proyectos y jefe encima demostrando el descontento al no estimar bien ni cumplir lo indicado.
Estimamos mal porque por una parte, muchas veces, desconocemos las implicaciones no visibles de una nueva tarea o requerimiento y en otra parte porque somos demasiado confiados al estimar.
Según el libro Thinking Fast and Slow de Daniel Kahneman, hay dos sistemas. Sistema I y Sistema II.
Sistema I se encarga de hacer análisis rápido de información mediante patrones previamente vividos.
Sistema II se encarga de hacer análisis concienzudo de la información a una velocidad mucho menor.
Ambos conviven para que como seres humanos podamos sobrevivir pero a la hora de estimar, generalmente, prevalece el Sistema I. Y lo hace porque generalmente se nos piden estimados para responder en cuestión de segundos, no horas.
¿Solución?
Ser conscientes de que somos demasiado confiados al estimar, aceptar lo cambiante y la incertidumbre que hay al realizar software y adoptar mecanismos para registrar y analizar estimaciones pasadas.
Llevar registro y control de estimaciones, no para decidir una fecha de entrega o saber si el proyecto está atrasado sino para mejorar al estimar. Así se puede entrenar el Sistema I para que esté más afinado cada que intervenga en estimaciones.
Lista de artículos
Resumen General
Coding, Fast and Slow: Developers and the Psychology of Overconfidence