La Frustración En Un Proyecto De Software

La frustración es muchas veces una constante cuando se trata de abordar un proyecto de software, ya sea un proyecto grande o pequeños desarrollos, ya sea interno o externo. Es sorprendente que en un área aparentemente tan predecible, a base de combinaciones de unos y ceros, sea tan difícil hacer predicciones precisas, tanto en tiempo como en coste.

Lo cierto es que el desarrollo de software no es una ciencia tan nueva. Otras disciplinas, como la arquitectura o la fabricación naval, llevan desarrollándose milenios. Podríamos decir que el software comenzó sus andaduras alrededor de 1950, en la época en la que se construyó el Mark I y similares, que constituía el paso de máquinas de cálculo a lo que hoy conocemos por ordenadores modernos.

Hay un estudio basado en una encuesta de Standish Group que da una visión bastante clara de algunos factores que influyen en los problemas con proyectos de software.

Proyectos con problemas y % de respuestas

1 Falta de implicación del usuario 12.8%

2 Especificaciones incompletas 12.3%

3 Cambio en especificaciones durante el desarrollo 11.8%

4 Falta de apoyo del Management 7.5%

5 Incompetencia tecnológica 7.0%

6 Falta de recursos 6.4%

7 Expectaciones irrealistas 5.9%

8 Objetivos poco claros 5.3%

9 Tiempos no realistas 4.3%

10 Tecnología nueva 3.7%

11 Otros 23.0%

No me sorprenden las 4 primeras, que además están íntimamente relacionadas. Hacen referencia a la falta de implicación en general a la hora de afrontar los proyectos de software.

Es difícil obtener información del usuario/cliente a la hora de diseñar el proyecto. Esta fase es fundamental y requiere una capacidad de abstracción importante, pero en muchas ocasiones no se le da la relevancia que tiene. A esto se refiere el punto 1.

Sin esa información será difícil hacer unas buenas especificaciones concretas, y además será fácil que una vez iniciado el proyecto el usuario/cliente quiera cambiarlas o matizarlas, lo cual dará lugar a retrasos al tener que parar para volver a especificar o deshacer lo ya hecho. Tiene que haber un plan de gestión de cambios, que los valore y los impida si no están justificados.

Y es de vital importancia que la dirección del proyecto, del cliente, del usuario, de los desarrolladores… es decir, los altos mandos en general, den poder a los gestores del proyecto y den importancia y promoción al hecho de gestionarlo correctamente. A esto se refiere el punto 4.

Quizá

...