También es verdad que no hay “predicción” que resista, sólo hay que ver las estadísticas de los proyectos que terminan en plazo y coste.

Por eso utilizando una metodología tradicional, en el mejor de los casos, para evitar los riesgos derivados de la “predicción”, el cliente pagará un “colchón” de, digamos, ¿un 30%?, o incluso, como he llegado a ver, un 50%.

Porque imagino que multiplicar por 50 tendrá un margen suficiente para evitar riesgos.

Es una lástima que el cliente tenga que pagar un colchón de una estimación imprecisa y obtener un producto que en muchos casos no quería (porque no sabía lo que quería con exactitud).

Todo dependerá de la relación de confianza que tengas con el cliente, pero algunos preferirán pagar por el trabajo realizado (en forma de iteraciones cortas de tiempo) en lugar de pagar “colchones”. ;-)

De esa manera, el cliente sabe (utilizando extranets de seguimiento) que va a pagar por el valor justo del servicio y el proveedor evitará los riesgos derivados de intentar adivinar el futuro (todos ganan).

Además, con la aproximación ágil, si el cliente no está satisfecho en alguna de las iteraciones, puede parar el proyecto. Esto también es una ventaja que puede facilitar la venta del modelo.

No se, de cualquier manera es un tema complejo. ;-)

Yo me conformaría con obtener una valoración que un equipo humano con una cualificación media (¿que entiendo por media? pues vaya usted a saber) pueda cumplir.

Y por cierto. Lo de las metodologías ágiles (ya escribiré algún otro post sobre el tema)están muy bien para clientes con el bolsillo tambiñen ágil, es decir, que va gastando iterativamente hasta que obtiene algo decente. Pero cuando el alcance y el precio son cerrados… ¡ah querido amigo!

- ¿Esta estimación la ha hecho el equipo que va a hacer el trabajo?
- ¿Cuánto tiempo lleva trabajando junto este equipo?
- ¿Este equipo ha medido su capacidad real y ha utilizado esta medida para hacer la estimación?
- ¿Qué conocimientos tiene el equipo de las herramientas, tecnologías, etc. que se van a utilizar?

Si las respuestas a estas preguntas no son satisfactorias, entonces el cálculo es pura fantasía, es una mentira. ;-)

Las estimaciones o más bien “predicciones” en el desarrollo de software no son muy diferentes de las predicciones meteorológicas. En ambas existen un gran número de variables y factores desconocidos (teoría del caos).

Uno de los mayores beneficios propuestos por las metodologías ágiles (Scrum, Extreme Programming, …) es la estimación mejorada. En lugar de tratar de proporcionar una estimación precisa de todo el proyecto, estos métodos proporcionan una forma de realizar la estimación a corto plazo, maximizar la funcionalidad entregable de manera continua y proporcionar variables de control a largo plazo.

El desarrollo de un producto software modifica sus propios requisitos. Tan pronto como los clientes ven la primera versión, descubren lo que quieren para la segunda versión, … o mejor dicho lo que realmente querían en la primera. Y este aprendizaje es valioso, ya que posiblemente no podría haber tenido lugar sobre la base de la especulación. Este aprendizaje sólo puede venir de la experiencia.

¿Qué pasa si vemos la “debilidad” de los requisitos como una oportunidad y no como un problema?

De las cuatro variables de control (calidad, coste, tiempo y alcance), podríamos ver el alcance como la más fácil de controlar. Debido a su “debilidad”, podríamos ir dándole forma. Si se acerca una fecha de entrega, siempre se puede aplazar algo menos prioritario para la siguiente versión (o iteración). No intentando abordar demasiada funcionalidad, se puede conservar la capacidad de entregar con la calidad requerida en el tiempo estimado.

Además, entregando más frecuentemente se puede garantizar que el cliente va a tener el mejor producto posible en el mínimo tiempo (Build half a product, not a half-ass product). ;-)

Y pienso que esto es lo que deberíamos inculcar a nuestros clientes para que poco a poco se fuera estableciendo una relación de confianza basada en nuestra experiencia con ellos, que llevara a estimar iteraciones de tiempo en lugar de proyectos completos, ofreciendo al final un mejor resultado de las cuatro variables que indudablemente se traduciría en captación y retención de más clientes satisfechos.