¿Qué es lo más determinante para el éxito, o fracaso, de un proyecto? Las personas

Si hubiese que elegir, de entre las claves que determinan el éxito (o fracaso) de un proyecto software, aquella sobre la que existe más consenso del impacto que tiene, sin duda, yo me aventuraría a decir que esta sería el papel que juegan “las personas”.

En mayor o menor media, prácticamente todo aquel que ha estudiado el éxito o fracaso de un proyecto software ha destacado el papel que las personas, el equipo de desarrollo, juegan en el mismo.

Concluyendo, en la mayoría de ocasiones, con que las personas son el factor más determinante.

Como decía Glass, no hay que olvidar que las personas son las que hacen el software. Las herramientas ayudan, las técnicas también, los procesos, etc. Pero sobre todo esto están las personas. “Las personas son la clave del éxito”, que dijera Davis en su genial libro. El equipo humano que, como decía Cockburn, es el componente no lineal de primer orden en el desarrollo software. Decía McConnell que las personas son lo que tiene más potencial para recortar el tiempo de un proyecto, y que quienes han trabajo en software “han observado las enormes diferencias que hay en los resultados que producen entre desarrolladores medios, mediocres y geniales”.

Después de analizar 69 proyectos Boehm comprobó que los mejores equipos de desarrolladores eran hasta 4 veces más productivos que los peores. Por su parte DeMarco y Lister, en su Peopleware, identifican diferencias de productividad de 5.6 a 1, extraídas de un estudio con 166 profesionales de 18 organizaciones. En la NASA**, observaron diferencias de hasta 3 a 1 en productividad entre sus diferentes proyectos. E incluso mucho antes, en el 74, había ya estudios* que habían observado diferencias de 2.6 a 1 en equipos a la hora de realizar las mismas tareas de desarrollo.

Pero aunque para algunos esto esté muy claro, no siempre es así en todos los proyectos.  Recuerdo que hace años trabajaba en una empresa que desarrollaba productos software… en la que no pensaban exactamente así. Allí se pensaba que los desarrolladores no eran lo más determinante, eran “piezas” intercambiables. Que lo determinante era la parte comercial y la funcional, los técnicos eran una “commodity”. De ahí que gran parte del equipo técnico no tenía el perfil, la cualificación y estudios acordes para desarrollar el software que se les encomendaba, por cierto, una aplicación bastante grande. Los jefes de proyecto, y directores técnicos, jamás habían estudiado alguna carrera técnica. Lo curioso era que, aunque todo el mundo veía los grandes problemas de calidad software y de gestión del proyecto, nadie parecía ver la principal causa de los mismos.

La gente que participa en un desarrollo software, no son como obreros en una cadena de montaje. No son tan fácilmente intercambiables, y el trabajo no es tan repetible como en estos otros trabajos. Más aún si no se ha implantado una calidad software de verdad (no sólo una certificación). Os recomiendo aquí leer el post de fabricar software no es lo mismo que fabricar coches o construir casas.

Referencias
* Weinberg, Gerald M., and Edward L. Schulman. 1974. «Goals and Performance in Computer Programming.» Human Factors, vol. 16, no. 1 (February): 70-77.
** Jon D. Valett, Frank E. McGarry: A summary of software measurement experiences in the Software Engineering Laboratory. Journal of Systems and Software 9(2): 137-148 (1989)