En las películas de ciencia ficción de Hollywood suele escucharse la sentencia: “Hay cosas que el hombre no debería saber”. Sin duda, una de ellas es predecir el futuro. Y eso es justamente lo que nos encontramos los que nos dedicamos al negocio del desarrollo de software cuando tenemos que trabajar en la estimación de un proyecto. Llevo estudiando y practicando, no es lo mismo, esto de estimar un proyecto casi 20 años, y me ocurre lo mismo que decía L. Pasteur sobre lo que ocurría con la ciencia y la religión, cuando afirmaba que «un poco de ciencia te aleja de Dios y mucha ciencia te vuelve a acercar a Él».
Antes de comenzar a conocer y practicar la estimación de proyectos, piensas que es un milagro poder siquiera hacer una estimación más o menos precisa. Con el tiempo aprendes más, aplicas técnicas de libro y piensas que en los siguientes proyectos lo harás mejor. Solo con el paso de los años y tras haber sufrido y sobrevivido a proyectos de diferente complejidad, te das cuenta de que sólo Dios puede hacer una estimación razonable de un proyecto. Pero si esto es así, y puedo afirmar que es una opinión compartida por la inmensa mayoría de los que nos dedicamos a esto, viene una pregunta que todos nos hemos hecho varias veces: ¿Por qué hacemos estimaciones?
En el mundo de los negocios, ese lugar donde habitan dinero y personas, antes de empezar a hacer algo, por norma general alguien quiere saber lo que cuesta hacerlo. Si consigues trabajar en una empresa donde esto no sea así, en primer lugar enhorabuena, te has quitado un montón de problemas de encima, en segundo lugar, ve preparándote para cuando eso cambie, porque ese momento, no tengas ninguna duda, llegará.
Se podría decir que existen dos ramas de pensamiento con respecto a estimar o no un proyecto. De hecho, hace un tiempo hubo una polémica entre dos referentes en los temas del desarrollo y gestión de proyectos como son Ron Jeffries y Steve Mc Connell. El primero abogaba, en pocas palabras, por dejar de hacer estimaciones en los proyectos, dado que eso ocasionaba más perjuicio que beneficio. Por supuesto, Steve Mc Connell, autor de un libro clásico titulado «Software Estimation: Demystifying the Black Art», no podía estar más en desacuerdo y airearon sus distintas opiniones en varios posts e incluso vídeos en Youtube. La polémica está bien recogida y comentada, por si alguien tiene interés en ella, en el blog de Javier Garzás. Realmente muy interesante.
Para mí el cine son 400 butacas por llenar. Alfred Hitchcock
Grados de libertad
Un proyecto se puede definir de forma muy breve como una combinación de tres variables que mantienen un complejo equilibrio:
- Tiempo: número de días desde que arranca el proyecto hasta que se cierra.
- Alcance: el conjunto de funcionalidades o características con las que debe cumplir el sistema al finalizar el proyecto.
- Coste: importe que se carga en el proyecto como consecuencia de los costes asociados a su ejecución.
Estas tres variables son los grados de libertad de un proyecto que además se mantienen relacionados entre sí, durante toda la vida del mismo. Algunas de las combinaciones más frecuentes y problemáticas, por los quebraderos de cabeza que suelen proporcionar son:
- Si mantenemos fijo el Alcance y el Coste, nos queda sólo el Tiempo como grado de libertad para poder maniobrar.
- Si mantenemos fijo el Tiempo y el Coste, el grado de libertad con el que contamos es el Alcance.
Nunca estás entregado a una causa en la que tienes plena confianza. Nadie grita que el sol va a salir mañana por el horizonte. Ya saben que eso ocurrirá. Cuando la gente está entregada a causas, creencias políticas, religiosas o cualquier otro tipo de dogmas o metas, siempre es porque estos dogmas o metas están en duda. Robert Pirsig, Zen and the Art of Motorcycle Maintenance.
El proyecto cerrado es el mal
En el negocio de TI, ya seas una empresa del IBEX35 o una pyme, el 99% de los contratos que se hacen relacionados con desarrollo de software y que son proyectos, se contratan en la modalidad de proyecto cerrado. Su cualidad principal es que las tres variables, tiempo, alcance y coste, se cierran antes de empezar, gracias a un “fino” trabajo de estimación y planificación del proyecto, que suele arrojar un margen de error de entre un 30% y un 300% por dar una horquilla no muy sonrojante, no sea que algún colega lea esto. En resumen, un desastre que lleva ocurriendo año tras año -y se podría decir que ya llevamos más de 30- sin que los marcos “ágiles” hayan podido hacer demasiado, aunque algo han mejorado el panorama, todo hay que decirlo.
Todo comandante en jefe que se comprometa a ejecutar un plan que considera defectuoso es culpable; debe exponer sus razones, insistir en que el plan se cambie y, finalmente, ofrecer su renuncia en lugar de ser el instrumento de la caída de su ejército. Napoleón, Military Maxims and Thoughts.
Consejos para sobrevivir en proyectos cerrados
- Olvidarse de estimaciones de tiempo en número de días fijos. Nada de 70 jornadas. Conviene utilizar intervalos de tiempo junto con un grado de confianza o de probabilidad.
- Proporcionar en las estimaciones de tiempo tres visiones, la optimista, la pesimista y la neutra.
- Hacer una gestión del cambio a modo de bitácora, que todo quede registrado, aunque sea en una lista de sucesos temporales, y flexible, de forma que se puedan “compensar” cambios que representen un incremento del alcance con otros que supongan una rebaja, sin necesidad de hacer cambios contractuales. Habrá que tener estimados, en la medida de lo posible, los cambios de alcance que supongan un sobrecoste.
- Por último, el que para mí es el más importante y el que casi nunca se hace. Dedicar una buena cantidad de tiempo al finalizar el proyecto con toda la información recopilada, para tener una visión clara sobre los factores que han influido en el devenir del proyecto, prestando especial atención a los tres grados de libertad y a dos puntos más que son clave: la calidad de lo generado y los efectos en el equipo de trabajo.
Durante los últimos años, al calor de los marcos de trabajo ágiles como Scrum, ha surgido una opción que empieza a cobrar cierto protagonismo, pero que a mi entender se va abriendo paso aún de forma muy lenta, me refiero a los contratos “ágiles”, basados en un modelo o relación de confianza entre cliente y proveedor, donde el primero -al tener más transparencia sobre el trabajo del segundo que en modelos tradicionales- se siente con la suficiente garantía como para cerrar las variables tiempo y coste, y dejar que el alcance vaya definiéndose en cada uno de los sprints de trabajo que al final se materializan en incrementos del producto.
Para quien esté interesado en profundizar en estas modalidades de contrato, le dejo algunas referencias que pueden servirle como punto de partida:
- Un contrato ágil para Scrum.
- Cómo cocinar tu contrato ágil.
- Cláusulas “ágiles” para contratos tradicionales.
Y, por último, no está de más recordar algo que se aplica como un guante al desarrollo de productos y que conviene no olvidar nunca, independientemente del modelo de contrato:
TERMINADO es mejor que PERFECTO.
Foto: Tumisu