Llave en mano

Al menos en mi experiencia y entorno, los proyectos llave en mano son comunes. Me refiero por proyectos llave en mano a esos donde se compromete un precio y calendario con el cliente, y luego de ganar algo así como una compulsa de precios, comienza el desarrollo del software.

Estimar correctamente es un punto clave en este tipo de proyectos: una mala estimación hace perder dinero, tiempo, enojar al cliente por problemas de calendario y todo eso lleva a una caída en la calidad que aumenta los costos y hace enojar aún más al cliente.

Scott Ambler tiene una opinión bastante clara y razonada sobre los proyectos llave en mano. Ambler dice cosas ciertas: este tipo de proyectos te lleva a escribir todos los requerimientos de entrada, a pensar un diseño y una arquitectura y a implementar un mecanismo bastante restrictivo de gestión del cambio. Todo eso herético desde el punto de vista del desarrollo ágil. Yendo un poco más allá de mi último comentario, algo improcedente y sarcástico, se puede argumentar con razonable facilidad que intentar elucidar todos los requerimientos y pensar una arquitectura de un software que no existe antes de hacer siquiera una parte es una estrategia que traerá problemas, más temprano que tarde.

Por otra parte, no es un secreto que las estimaciones hechas a priori suelen diferir bastante del esfuerzo finalmente necesario.

Por eso, puedo estar de acuerdo con que la idea del proyecto cerrado es una idea perniciosa (puedo pensar en más de un ejemplo donde todos pierden: el cliente queda disconforme y el proveedor gastó más de lo que había proyectado).

Mirando desde el otro lado, si pensamos como el cliente, no es difícil entender por qué se desea saber por adelantado cuanto va a salir la joda: vamos, quien contrataría a un arquitecto (de casas y edificios) que dijera 'bueno, a medida que me vas pidiendo que construya algo en la casa, que agregue algo, te voy diciendo el precio'?. No vale argumentar que una casa es diferente al software, estoy hablando de dinero, que es bastante parecido en todos los ámbitos: quien se embarcaría en un proyecto sin tener idea de cuanto saldría y sin tener al menos la expectativa de tener dinero suficiente para no ahogarse a la mitad del río?. Yo no.

Aunque, como comenta Ambler, los proyectos cerrados puedan ser caros para el cliente porque el proveedor no tiene más remedio que cotizarle el riesgo e implementar algún mecanismo de control de cambio (efectivamente, como él dice, son mecanismos que tratan de impedir el cambio y no controlarlo). Más aún, con un mecanismo eficaz para impedir el cambio es altamente probable que el sistema construido diverja de las necesidades del usuario. Pero aún así, la previsibilidad financiera ( saber de antemano cuanto me va a costar) es terriblemente atractiva. Lo que se está pagando (lo que tanto cliente como proveedor están pagando), es la falta de información.

Se podría contra-argumentar que la idea de una metodología con foco en el control de cambios no es impedir el cambio, sino cobrarle al cliente por el mismo. No está mal, en definitiva, y eso nos acercaría a una estrategia ágil, donde ante cada cambio cobraríamos el diferencial de implementarlo ( costo de implementar lo nuevo menos el costo de no implementar lo que ya es necesario y no está implementado), lo que, incluso, penalizaría el cambio en etapas tardías del proyecto. Estaría incluso mejor si pudiéramos definir claramente, y por adelantado, qué es un cambio: no se puede cambiar lo que no se definió y el problema, muchas veces, no es que se haya definido un aspecto de un desarrollo en forma errónea, sino que no se lo ha definido de ninguna manera.

Claramente, necesitamos una solución. La solución ideal: que la industria se aleje de los proyectos cerrados, que el cliente nos contrate un equipo determinado por un tiempo pre-acordado y que adoptando el ciclo de vida de XP trabajemos haciendo lo que el cliente pide: pide más, hay más iteraciones. El problema es que parece demasiado bueno para nosotros, los informáticos, como para que se transforme en una práctica muy extendida.

A mitad de camino, tenemos la 'gestión de aplicaciones', o el servicio donde uno como proveedor implementa requerimiento a requerimiento. Es una buena idea, pero se necesita una confianza importante en la performance del equipo del proveedor. No es algo que un cliente le contrataría a un proveedor que recién conoce, me parece. Tampoco es, entiendo, demasiado común para desarrollos desde cero, sino que se adapta mejor a mantenimientos evolutivos y correctivos, donde, en definitiva, es más fácil estimar el esfuerzo de cada modificación.

Yo me imagino que la solución debería venir por alguna forma estándar en la industria de medir la performance de los grupos de trabajo en algo así como unidades estándares de software (que no sean lineas de código, por supuesto) producidas por unidad de tiempo. Volviendo al ejemplo del arquitecto ágil (el de casas y edificios) citado más arriba, creo que tal vez lo contrataríamos si pudiéramos acordar entre ambos, antes de comenzar el proyecto, una forma transparente de estimar los costos: nos aseguraremos que el arquitecto no se va a aprovechar de nuestra situación cuando sea muy caro abandonar el proyecto o cambiar de caballo. Que forma tendrían esas 'unidades estándares de software' (no de trabajo, sino de software)? Ni idea.