archivo

Archivo de la etiqueta: llave en mano

Tenemos los extremos:

– En los contratos llave en mano el riesgo lo asume el proveedor: “Estas son los objetivos, las condiciones y el dinero… ¡suerte!”.

– En los contratos por horas el riesgo lo asume el cliente: La baja productividad y esas horas que se pierden en el limbo de las horas de los proyectos de desarrollo de software (que debe de ser, por cierto, muy grande, para dar cabida a tantas).

Ambos extremos, en frío, sin matices, deben ser evitados y sin embargo con muy pocos matices son los que se utilizan de manera mayoritaria y ambas partes: clientes y proveedores tratan de arrimar el ascua a su sardina, muchas veces sin tener en cuenta que lo que a priori parecen ventajas se puede convertir después en inconvenientes.

La llave en mano es demoledora cuando se falla en las estimaciones y ten seguro que será así, estadísticamente se suele ser demasiado optimista con las mismas y más optimista será si el cliente es el que se ha encargado de hacerlas. Y no es cuestión solo de pesimismo o de optimismo, la clave está en que no se dispone de información suficiente para poder hacer una estimación medianamente realista y el problema lo tenemos en que ese conocimiento se obtiene conforme vamos avanzando en el proyecto.

Cuando el error es sensible nos encontramos en una situación de Death March Project, en la que será necesario replantear el triángulo de hierro o el proyecto fracasará sin remedio y con gran desgaste entre las partes.

Y el problema no es solo fallar más o menos con las estimaciones sino también en la definición de los objetivos por un lado porque a lo largo del contrato pueden cambiar, pero sobre todo por la interpretación de cuál es el nivel de acabado que tienen que tener los mismos para darse por satisfechos: para el cliente pocas veces será suficiente para el proveedor será justo lo contrario.

Las bolsas de horas ofrecen una flexibilidad extrema pero soy de la opinión de que para optar por esta opción el cliente debe confiar muchísimo en el proveedor y más que en el proveedor en las personas que van a intervenir en el proyecto.

Incluso en las condiciones más favorables para aplicar esa estrategia es beneficioso para ambas partes la definición de objetivos como podría ser por ejemplo facturar por iteración.

Como veis es difícil encontrar una fórmula en la que se consiga el equilibrio pero tal vez sea más sencillo encontrar soluciones en las que el riesgo se comparta.

En la serie de artículos sobre Contratación Ágil podéis ver algunas posibles soluciones a aplicar, teniendo siempre en cuenta que independientemente de la fórmula utilizada, si las personas se quieren entender se entienden (y al contrario), pero dado que nadie puede garantizar a priori que quiénes toman las decisiones van a estar durante todo el proyecto (las personas vienen y van), es conveniente que exista un marco de referencia:

Contratación ágil I.
Contratación ágil II.
Contratación ágil III.
Contratación ágil IV.
Contratación ágil V.

Podemos discutir el porcentaje pero no el fondo de la siguiente reflexión de Larry Bernstein: “Sólo entre el 40 y 60% de los requisitos de un sistema se conoce al comienzo del proyecto. El resto emerge con el uso. Barry Boehm acuñó el término requisitos emergentes para describirlos”.

Y no se trata de requisitos que aparecen por arte de magia sino que son consecuencia de la evolución que existe entre lo que el usuario cree que quiere y lo que realmente necesita y de la separación que existe entre la visión abstracta de un producto y su implementación real.

De ese porcentaje inicial de requisitos previsibles, una parte importante de los mismos tiene a su vez que ser perfilada también con la utilización del sistema.

Esto al final nos hace ver que los desarrollos llave en mano y/o los ciclos de vida en cascada no se adaptan a esta realidad y por ese motivo no suelen ofrecer buenos resultados y si lo consiguen es porque todas las partes en alguna parte del proceso de desarrollo se dan cuenta de que es necesario llegar a un acuerdo para que el producto se dirija hacia lo que realmente se necesita y no hacia lo que inicialmente era previsible.

Para Fred Brooks: “Incluso la mejor planificación no es tan omnisciente como para hacer las cosas bien a la primera”.

Eso es importante tenerlo en cuenta si pretendes contratar un software llave en mano o si te quieres encerrar en las limitaciones de un análisis de requisitos.

Lo puedes tratar de hacer de la mejor forma posible, con un espíritu de colaboración fantástico con el área usuaria, con estudios de mercado y/o de otros productos similares, con grandes técnicos, pero al final, la realidad y el camino lo marca el software que estás desarrollando y hasta que este no se empieza a utilizar en un contexto real por parte de los usuarios no se obtendrá el feedback necesario para acercar el producto a las expectativas reales que se tienen de él.

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.

¿Quién expone más con esta estrategia?, ¿el cliente?, ¿el proveedor? De entrada podría pensarse que el cliente porque no cierra un alcance definido, solo lo esboza y puede darse el caso de que se acabe con el presupuesto y no se consigan los objetivos generales que se han marcado.

Es posible que esto suceda, como también es posible que suceda con una visión opuesta, la de la llave en mano, en donde se pretende mantener fijo el alcance, ya que en el momento en que las cuentas no cuadran para el proveedor y supera el umbral de las pérdidas admisibles, querrá empezar a querer recortar ese alcance y/o solicitar más dinero, todo eso en un contexto de desgaste en el que además, la productividad y calidad de los trabajos se verá afectada, impactando a su vez en los costes. Esto que cuento no es ciencia ficción, quiénes hayáis trabajado en este tipo de contratos sabéis de lo que estoy hablando.

La clave está en definir unas condiciones contractuales en las que ambas partes compartan el riesgo, pero para llegar a eso es importante que en el cliente se entienda que con la incertidumbre que es inherente a todo proyecto de desarrollo de software, cualquier estimación inicial terminará siendo papel mojado conforme vayan avanzando los trabajos y que lo realmente importante es ir trabajando de la mano del proveedor (y el proveedor de la mano del cliente) para ir incrementando el valor del producto en cada iteración, de manera coherente a la inversión que se está realizando.

Los proyectos de desarrollo de software tipo “llave en mano” son una fuente continua de fracasos, salvo excepciones (que las hay), se salvarán aquellos proyectos en los que se haya acertado en su valoración, hayan tenido una cierta estabilidad en el desarrollo (sin cambios significativos en procesos, interlocutores, etc…) y en los que tanto cliente como proveedor hayan estado acertados y hayan colaborado en la consecución de un objetivo común que no es otro que desarrollar un sistema que satisfaga las expectativas de los usuarios.

Sin embargo, lo normal es que estos proyectos no vayan bien y terminen por dejar descontentos sobre todo al cliente, pero también dejarán descontentos a muchos proveedores, de los cuales algunos se sentirán así por no haber cumplido con las expectativas del cliente y otros porque el proyecto han tenido pérdidas (como he dicho en numerosas ocasiones, desgraciadamente un número significativo de proveedores les da igual el cliente y solo miran los números).

En este artículo no analizo quién es el principal culpable del fracaso (entre otras cosas porque eso es algo que habría que analizar caso a caso) sino en señalar como una de las principales causas el enfoque de proyecto llave en mano en el que se espera que a partir de una previsión inicial de coste, se haya acertado en la misma y que todo en el proyecto haya discurrido con normalidad para alcanzar los objetivos marcados.

Cuanto más grande sea el proyecto, más probabilidad existirá de que el coste estimado sea erróneo y que existan contingencias en el desarrollo que provoquen desviaciones.

Hay que tener en cuenta que un proyecto llave en mano el proveedor está vendido si el cliente así lo quiere, pero también lo está el responsable técnico del cliente ante sus usuarios. ¿Por qué está vendido? Porque si no se gestiona adecuadamente los costes de los cambios de especificaciones en el desarrollo, al final todo quedará en un montón de actas de reuniones, correos y conversaciones que no son más que papel mojado y palabras que no valen para nada.

¿Solución? Enfoque iterativo incremental con valoración y priorización de los diversos requisitos bajo un marco de actitud ágil.

El feedback y tener capacidad para dar respuesta rápida al mismo es esencial, como también lo es dividir el desarrollo del sistema en incrementos donde la capacidad de error en las previsiones se minimice. Por otro lado, se debe establecer un mecanismo en el que los usuarios sean conscientes del coste del cambio y hacerse responsables de ellos y en el que los proveedores se responsabilicen de su trabajo y se centren más en el producto y en el cliente que en salvar los números del proyecto.

Existen diferentes formas de implementar este tipo de solución, podéis tener más información en la serie de artículos que dediqué a la contratación ágil:

Contratación ágil I
Contratación ágil II
Contratación ágil III
Contratación ágil IV
Contratación ágil V