Cuando hablamos del desarrollo de software, una de las cosas que al parecer resultan más complicadas es estimar el esfuerzo y tiempo que una tarea va a tardar en completarse, no se diga un proyecto completo. La ambigüedad de los requerimientos iniciales, la experiencia de los involucrados, las herramientas potenciales y la curva de aprendizaje son siempre factores que hacen que los números varíen de persona a persona.
Adicionalmente al momento de discutirlo con otras personas, muchas veces alguna de las partes involucradas caemos en la maldición del conocimiento (no recordar lo que implica desconocer un tema en el que tenemos ya algo de experiencia) lo cual conlleva el desestimar o no comprender las razones para la diferencia de estimación contra las expectativas.
El lado feo de las estimaciones
Como en muchas otras áreas de la vida, las expectativas son un área problemática. Es complicado el que una
El problema con las estimaciones es que
- Son creencias
- Cambian
- Expiran
- Se convierten en objetivo del PM
Son creencias
Inicié este post mencionando parte de este aspecto, y ahora lo extenderé con una analogía espero que conocida. Cada uno tenemos una idea de cuánto nos tomaría caminar 10 kilómetros, en base a la experiencia que tenemos (si corremos regularmente, podemos tener hasta la medida de minutos por kilómetro en base al ritmo que deseamos), a las condiciones que nos imaginamos en que se llevará a cabo (por la mañana es más facil caminar que a medio día), las herramientas con que contaremos (si es de día no necesitamos lámparas o aditamentos reflejantes especiales), etc.
Cambian
Conforme voy ganando más experiencia en la tarea o proyecto, la idea que tengo irá cambiando. Si llevo un tramo plano y después de la primera curva veo que el resto es un monte, me daré cuenta que mi tiempo se elevará, aún cuando no sepa exactamente cuanto. Al empezar a subir el monte conoceré más de sus condiciones, lo cual probablemente me hará reconsiderar mi predicción (si alguna vez haz corrido Chupinaya, con su desnivel de aproximadamente 1000msnm, la analogía se te hará conocida).
Expiran
La idea que tengo al día de hoy respecto al esfuerzo que me toma caminar esos 10K, muy probablemente expirará por ahí después del 6 de enero, terminando el Guadalupe-Reyes (Si alguien no está familiarizado con la expresión, me refiero a que en México del 12 de Diciembre al 6 de Enero normalmente se considera la “temporada alta” de comida por los festejos que se engloban en esas fechas, lo cual nos lleva a muchos a ganar algunos centímetros de abdomen).
Se convierten en objetivo del PM
Cuando menciono PM, la M se refiere a Manager y la P puede ser Project, Product, Program. El rol generalmente se encarga de “controlar” el desarrollo del proyecto. El detalle en esta interacción es que cuando un líder o equipo da una fecha, se convierte en el objetivo del PM, muchas veces sin importar lo que pase, incluso a veces cuando la persona que hizo la estimación ya no forma parte del equipo, o quizá nunca lo fue.
Más complicaciones
Uno de los escenarios que más he visto es el que acabo de mencionar, cuando la estimación la realiza una persona diferente a la que realizará el trabajo. Un grado más de complicación a esto es cuando el equipo responsable de la misión no ha trabajado junto. Nunca.
Otro problema recurrente es cuanto el equipo tiene recursos asignados parcialmente. Esto es, que estan trabajando en múltiples proyectos. Al día de hoy no conozco a nadie que me haya dicho que puede trabajar exactamente 30% de su día en una tarea y 70% en otra. Además, cada equipo ve a sus integrantes como parte completa, no como un porcentaje solamente, lo que agrava la interacción y las posibilidades de medición de esfuerzo para poder estimar.
Si todo es tan malo, ¿para qué estimar?
Porque mi jefe lo pide; normalmente es la respuesta que obtenemos. No importa que trabajemos de manera ágil, en algún punto alguien necesita saber para cuando se va a terminar el proyecto.
En primer lugar, existe una complejidad muy grande en poder definir lo que el proyecto abarca. Súmale entender lo que hay en la cabeza de cada quien. Y cada cierto tiempo, se agregan más elementos al backlog.
De este modo, construir software se asemeja más a un proceso de aprendizaje que a uno de construcción. El aprendizaje puede expandirse infinitamente. De este modo, quizá es mejor preguntarle al jefe (o a su emisario) ¿Cuánto quieres invertir en este proyecto antes de cancelarlo?
No tengo fondos infinitos
O tengo un presupuesto limitado. O tengo que definir si el costo vale la pena. O tu competencia cobra menos. Hay muchas variantes de la exigencia de poder definir un costo estimado para el proyecto a desarrollar. La pregunta contraparte de esta que podemos hacer es ¿cuanto vale este proyecto para ti? Tristemente creo que si no nos avientan un zapatazo, el valor que nos den es tan imaginario como la estimación, además de ser menor a lo que realmente puede costar una parte del desarrollo.
Una posible solución (o varias)
Una manera de atacar esta situación es dar un rango de fechas: el proyecto estará terminado entre Enero y Diciembre del 2018. De inicio los rangos podrán ser muy amplios, y conforme el equipo vaya trabajando y conociendo más acerca del proyecto, el rango podrá hacerse más corto.
Para justificar la estimación propuesta, es muy valioso que como responsable de la estimación comuniques:
- Las suposiciones en las que te basas
- Las restricciones para que sea válida
Es importante recordar que no hay estimación perfecta. Pero estas técnicas pueden ser de utilidad y deben repetirse en cada iteración para ir ajustando y estar cada vez más cerca.
De este modo lo que reportemos a PMs, jefes, clientes, etc., podrá ser más preciso y citando a Jim Rohn, con ello podremos ir construyendo una mayor credibilidad.
