archivo

Archivos diarios: marzo 31, 2012

En el desarrollo de software hay una circunstancia paradójica, mientras que el universo digital que se implementa en cada software está compuesto finalmente por unos y ceros, el conjunto de relaciones entre las personas que participan en el proyecto funcionará mejor cuanto más alejada se encuentre su percepción y sus opiniones de valores extremos, olvidando toda la gama de posibilidades que hay en medio.

Son tantas la variables que intervienen en el proceso de desarrollo, son tantas las que definen un contexto que limitar las visiones de una situación a valores extremos no es algo objetivo, por mucho que creas que lo es. Lo más probable es que no hayas reflexionado lo suficiente y/o no tengas suficiente información.

No quiero decir que no tengas la razón pero lo mismo no te has parado a analizar que pueden existir matices que hagan que tu opinión esté más fundamentada. A veces los matices no cambian lo sustancial pero otras veces son lo suficientemente significativos para que te permitan ampliar la comprensión de una situación y ser más receptivo a escuchar otros puntos de vista o entender determinadas explicaciones.

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