Estimando proyectos
Sin duda la tarea más complicada con la que se encuentra un programador es la de estimar el tiempo que le va a tomar una tarea. En mi experiencia me he encontrado con que esto suele costar mucho más esfuerzo que el hecho de llevarla a cabo. Y es que, en mi opinion, la mayor parte de las veces la tarea de planificar y estimar tiempos es erronea desde todos los niveles.
El primer error habitual es confundir estimaciones con necesidades. Es muy habitual encontrarse con una situación como la siguiente:
Manager mal estimador: Hola. Tenemos una demo el miércoles y necesito que me digas cuando vas a tener el software listo para probarlo.
Desarrollador mal estimador: ¡No me jodas! ¡Pero si no funciona nada!
MME: Pues tenemos la demo el miércoles.
DME: Buffff…. Ya veré como me las arreglo. A ver si para el lunes te lo tengo listo.
MME: Ok. Más o menos me da tiempo a probarlo para tener todo listo.
DME: Me pongo a ello.
¿Cuantas veces hemos visto una escena similar? ¿Y cuantas ha terminado en desastre? Probablemente haya veces que, milagrosamente, todo haya salido bien pero nuestra misión es hacer que todo vaya lo mejor posible el mayor número de veces así que vamos a ver los errores que podemos detectar:
- Confundir necesidades con estimaciones: Que yo necesite algo para mañana no quiere decir que pueda tenerlo hecho para mañana. Es triste pero es así. Si necesito tener un hijo en 4,5 meses no puedo contratar a 2 mujeres para conseguirlo. Lamentablemente no podemos manejar el tiempo a nuestro antojo.
- No priorizar: Íntimamente relacionado con lo anterior. Tal vez, en el absurdo ejemplo del hijo, no sea necesario que el hijo sea mio sino que me vale con adoptar. Así puedo tener algo que, si bien no cumple con todos los requisitos iniciales, puedo llegar a tiempo.
- Estimar sin incertidumbre: Es imposible decir “para el día X lo tengo hecho” sin arriesgarte a tirarte cientos de horas extras no remuneradas o a retrasarte. Podemos saber con bastante certeza la fecha mínima para terminar algo pero nunca podemos saber la fecha máxima para la que vamos a terminar algo. De todos modos tenemos que ser operativos así que sería más correcto estimar siempre con un nivel de incertidumbre, aunque sea solo a título informativo. Es más constructivo decir: “a un X% lo tengo para el día Y”. Siempre pueden surgir imprevistos. Casos que no tuviste en cuenta en un principio y que complican la tarea o, sencillamente, tener un mal día. Todo eso pasa y es necesario tenerlo en cuenta.
Todo esto se resume en un sencillo punto. Cuando estimamos tiempos tenemos que pensar en dos fases. La primera es intercambiar información y la segunda tomar decisiones. ¿No creeis que sería más interesante lo siguiente?
Manager buen estimador: Hola. Tenemos una demo el miércoles y necesito que me digas cuando vas a tener el software listo para probarlo.
Desarrollador buen estimador: ¡No me jodas! ¡Pero si no funciona nada!
MBE: Pues tenemos la demo el miércoles. ¿Cuanto tardarías en tener todo listo?
DBE: Pues al 40% te lo podría tener para el viernes.Pero lo más probable es que sea para el lunes.
MBE: ¡Joder! ¡Siempre igual! (Nunca he dicho que no se queje. Solo que sea buen o mal estimador) ¿Que es lo que no funciona?
DBE: Pues se encontró un fallo grave en el dispensador de palomitas y estabamos refactorizando el código.
MBE: Buffff…. las palomitas son imprescindibles. ¿Solo falla eso?
DBE: El módulo de refrescos tampoco funciona bien. En algunos casos sirve las bebidas calientes.
MBE: ¡Bah! Eso da igual. Ya lo tengo en cuenta en la demo.
DBE: Pues teniendo en cuenta eso yo creo que incrementamos bastante las posibilidades. Si me pudiese echar una mano alguien más podemos asegurarnos más o menos al 90% que lo tenemos a tiempo.
MBE: Veré lo que puedo hacer pero no creo que sea problema.
Mejor ¿no? Si es que a veces nos buscamos los problemas nosotros solos.
Referencias:
