Qué Vida Ésta

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á sea debatible el orden de la lista que propone el Standish Group, pero creo que los factores más importantes sí están incluídos. Sólo añadiría la gestión y planificación del mantenimiento necesario una vez acabado el proyecto, algo que muchas veces se olvida o se minimiza.

En cualquier caso, al final todo se puede tomar con humor. Hay una viñeta que describe de forma muy gráfica todo este galimatías, la dejo por aquí enlazada en Flickr.

Referencias y más:

http://www.stylusinc.com/Common/Concerns/SoftwareProjectsFailure.php

http://en.wikipedia.org/wiki/Harvard_Mark_I

http://www.flickr.com/photos/cappellmeister/5921913/