Escapar de la llave en mano, ¿quién asume el riesgo?
Buena parte de la contratación del software está basada en acuerdo llave en mano en la que se pacta un precio cerrado para desarrollar un producto en base a unas especificaciones, por regla general, no muy detalladas de lo que se pretende hacer.
En muchos casos, el proyecto parte de una situación de Death March Project que dará lugar, si es que se consigue llegar, al menos, a ese punto, a un producto que no satisfará las necesidades y expectativas del usuario y en medio de todo eso se habrá producido un desgaste importante entre los diferentes implicados en el proyecto.
Los defensores de esta estrategia de contratación se centran en que el riesgo se traspasa al proveedor que es quien asume unas condiciones y como tal, debe cumplir lo pactado. Sin embargo es algo que termina volviéndose en contra también del cliente, que se debería conformar, con las especificaciones que dé en la fase de captura de requisitos, sin posibilidad de modificarlas posteriormente (la llave en mano y el desarrollo en cascada son compañeros de viaje).
¿Qué pasa? Pues que acertar a la primera es muy complicado y conforme vaya avanzando el desarrollo y los responsables funcionales vayan viendo partes del producto funcionando, surgirá la necesidad de realizar cambios sobre las especificaciones o incluso la necesidad de incrementar el alcance inicialmente previsto.
En ese momento entran en juego las negociaciones y dependerá de la voluntad de las partes que las mismas lleguen a un punto donde sea posible todavía entregar un producto que cumpla unas condiciones mínimas.
Desde mi punto de vista creo que, a pesar de ser legítima, una situación de partida en la que una de las partes trata de echar sobre la otra todo el riesgo no es positiva para un proyecto por sus propias características inherentes: incertidumbre, carácter evolutivo del desarrollo y las diferentes contingencias, casuísticas y problemas que suele haber en los mismos.
Jummp 