El papel que juegan las personas en ambos aspectos es bien conocido. Si se dispone de un equipo de proyecto con motivación, buena formación técnica y habilidad para comprender las necesidades del cliente y a la vez lograr que se valore el trabajo realizado, podría parecer que hemos alcanzado el éxito.
Sin embargo, una empresa que se dedique a la ejecución de proyectos de desarrollo no puede quedarse solamente en conseguir formar buenos equipos de trabajo, si es que realmente quiere poder sobrevivir a medio plazo. Con el tiempo los retos que se presenten irán siendo cada vez más complicados y los equipos de proyecto serán más heterogéneos.
Llegará un día en el que se planteará un proyecto muy importante, con un cliente aún más importante y el director general preguntará: “¿Podemos ejecutar este proyecto en 9 meses?”. Y en ese momento, en lugar de respuestas más o menos voluntaristas como un “sí” ingenuamente optimista o el erróneo “podemos intentarlo” o incluso el “haremos todo lo posible por conseguirlo”, la respuesta más acertada sería algo parecido a esto: “nuestra compañía nunca ha logrado ejecutar un proyecto de ese tamaño en menos de 11 meses y la media de tiempo es de 13 meses” [McConnell – Rapid Development, 1996].
El uso de métricas en el desarrollo de software es una de las prácticas que menos beneficio emocional proporciona a corto plazo, pero mayores ventajas aporta a medio y largo plazo en cuanto a control de coste, tiempo y calidad del software. Y no me refiero a las métricas que se puedan utilizar en un proyecto concreto para un cliente determinado, sino al conjunto de métricas que se deben emplear de forma horizontal en todos los proyectos.
Como suele ser habitual, las actividades que más beneficio aportan son aquellas que se distinguen por ser menos gratificantes en los inicios de su aplicación. No es fácil conseguir el compromiso de un equipo de proyecto para que participe activamente en la generación de datos para esas métricas. Como decía un entrenador estadounidense de la liga universitaria de baloncesto, “todos quieren estar en un equipo campeón, pero nadie quiere venir a practicar”.
Las compañías que son conscientes de la importancia de usar métricas en sus proyectos de desarrollo son las que predominan. Las que no lo hacen simplemente ejecutan proyecto tras proyecto como si fuese siempre el primero y cuando llega el desastre en alguno de ellos, lo achacan a la mala suerte, a la mala gestión o al bajo conocimiento técnico del equipo.
Sorprendentemente todo el mundo está de acuerdo en que medir es importante y que es clave para mejorar la calidad y la productividad. Pero entonces, ¿por qué el uso de métricas es uno de los aspectos que menos atención se presta en los proyectos de desarrollo? La respuesta es que no es lo mismo conocer el camino que andar el camino. Efectivamente, no es nada sencillo hacerlo. La definición de los datos que se han de utilizar para las métricas, así como la forma en que se van a obtener esos datos es ciertamente difícil de conseguir y homogeneizar cuando hablamos de varios proyectos, equipos de trabajo distintos y tecnologías diferentes.
En primer lugar, es indispensable disponer de un ecosistema de aplicaciones que dé soporte a cada uno de los procesos involucrados en el desarrollo del proyecto (estimación y planificación, programación, pruebas, análisis, gestión de peticiones/incidencias…) y que exista cierto grado de integración entre ellas para poder obtener datos y relacionarlos, destacando que es más importante contar con un reducido conjunto de datos que se obtengan de forma clara y rápida, que contar con muchos que requieran un trabajo excesivo.
En segundo lugar, hay que aplicar lo que ya aprendió el SEL (Software Engineering Laboratory) de la NASA tras 20 años midiendo proyectos de desarrollo. Hay que invertir más tiempo analizando datos que recopilando esos mismos datos.
Y, por último, no hay que olvidar que el desarrollo es una actividad llena de intangibles y los datos fríos en ocasiones ocultan valiosas lecciones que conviene no olvidar. Por ello es importante acompañar esos análisis con las opiniones y comentarios de las personas implicadas, que permitan obtener una visión cualitativa y cuantitativa, lo más completa posible del trabajo realizado en cada uno de los proyectos.
Las organizaciones que interioricen esto y sigan fielmente su propia hoja de ruta para mejorar la calidad del software que desarrollan lograrán un incremento de la productividad que se cifra en torno al 15% anual durante los primeros 4 años.
