Mi primer libro sobre métricas, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982) jugó un rol importante en la forma en la que muchos ingenieros de software cuantificaron el trabajo y planificaron sus proyectos. En retrospectiva, me pregunto, ¿fue un buen consejo en ese momento, todavía es un buen consejo relevante en la actualidad, y todavía creo que las métricas son algo fundamental para el éxito de un desarrollo de software? Mis respuestas son no, no y no.
Para mi, el libro es una curiosa combinación de cosas que usualmente son verdaderas, pero combinadas en un mensaje general que está equivocado. Es como si el jóven autor del libro nunca hubiera encontrado una métrica que no le gustara. El mensaje del libro parecería ser: las métricas son buenas, más sería deseable, y más todavía sería lo mejor. Hoy todos comprendemos que las métricas de software cuestan dinero y tiempo, y deben usarse con una moderación cuidadosa. Además, el desarrollo de software es inherentemente distinto a las ciencias naturales como la medicina, y por lo tanto sus métricas son mucho menos precisas para capturar las cosas que intentan describir. Deben tomarse con cierto esceptisismo, en vez de confiar en ellas ciegamente.
Deseos de controlar
La frase del libro más citada es su primer oración: "No podemos controlar lo que no podemos medir". Esta frase contiene una verdad real, pero cada vez estoy más incómodo con su uso. De forma implícita en la oración (y de hecho también en el título de libro) está que el control es un aspecto importante, quizás el más importante, para cualquier proyecto de software. Pero no es así. Muchos proyectos avanzaron sin mucho control y lograron crear productos maravillosos, como Google Earth o la Wikipedia.
Para comprender el rol real del control necesitamos distinguir entre dos tipos de proyectos completamente distintos:
- El Proyecto A, que cuesta cerca de un millón de dólares y produce valor por 1.1 millones de dólares.
- El Proyecto B, que cuesta cerca de un millón de dólares y produce valor por más de 50 millones de dólares.
Resulta evidente que el control es realmente importante para el Proyecto A, y casi no tiene importancia para el Proyecto B. Esto nos lleva a la extraña conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y no importa tanto en proyecos útiles. Esto nos sugiere que mientras más nos enfocamos en el control, es más probable que estemos luchando por entregar algo de muy poco valor.
Para mi, la pregunta que es mucho más importante que cómo controlar un proyecto de software es ¿por qué demonios estamos haciendo tantos proyectos que entregan un valor tan marginal?
¿Realmente estoy diciendo que está bien llevar adelante proyectos sin control o con relativamente poco control? Casi. Estoy sugiriendo que primero necesitamos seleccionar proyectos en donde no importe tanto el control preciso. Después necesitamos disminuir nuestras expectativas sobre cuánto vamos a poder controlarlos, sin importar qué tan asiduamente nos dediquemos al control.
Una anología incómoda
Imaginemos que estamos tratando de criar un hijo adolescente. La idea de intentar controlar a nuestro hijo ya debería resultarnos rara. Y sin embargo, el riesgo de no controlarlo es el más alto de todos. Si fallamos en nuestra tarea, si fallamos completamente, podemos arruinar vidas. Entonces, es absolutamente necesario no perder por completo el control. Somos como un esgrimista aprendiendo a sostener la espada como si fuera un pájaro: muy fuerte y lastimaremos al ave, muy flojo y se nos escapará volando.
Ahora apliquemos el "No podemos controlar lo que no podemos medir" a nuestro adolescente. La mayoría de las cosas que importan -honor, dignidad, disciplina, personalidad, fortaleza bajo presión, valores, ética, capacidad, lealtad, humor, bondad- no se pueden medir. Vamos guiando a nuestro hijo lo mejor que podemos sin´muchas métricas de feedback. Es dificil; ser padre es dificil. Obtenemos algo de mediciones en la forma de "notas escolares", y nos sentimos agradecidos. Pero también sabemos que las notas de matemática de nuestro hijo son un mejor indicador de logros que las notas de Literatura, porque es más facil medir el conocimiento de matemática. Y esta "nota" en cuestión es probable que nos diga mucho más sobre el maestro que sobre nuestro hijo.
Entonces, ¿cómo gestionamos un proyecto sin controlarlo? Bueno, gestionamos las personas y controlamos el tiempo y el dinero. Por ejemplo, le decimos a los líderes de los equipos: "Tengo una fecha objetivo en mente, y no la pienso compartir con ustedes. Un día voy a venir y les voy a decir que el proyecto termina en una semana, y ustedes tienen que estar listos para empaquetar todo y entregar lo que tienen como producto final. Su trabajo consiste en avanzar de forma incremental por el proyecto, agregando piezas al total en órden de su valor relativo, y hacer integración, documentación y pruebas de aceptación también de forma incremental a medida que avanzan".
Podría parece como una prescripción para métodos ágiles, pero hoy en día estoy demasiado alejado de la construcción de software como para hacer recomendaciones a nivel de métodos. En cambio, voy por un enfoque de gestión, uno que podría llevar al equipo a adoptar prácticas ágiles, o al menos hacia los aspectos incrementales de la escuela ágil.
Hasta aquí vengo discutiendo sobre el componente de las métricas en la ingeniería de software. ¿Qué pasa con el resto? Estoy llegando a la conclusión que la Ingeniería de Software es una idea que ya es obsoleta. Todavía creo que tiene mucho sentido para crear sofware. Pero esto no es lo que la ingeniría de software significa hoy. El término agrupa a un conjunto específico de disciplinas que inluyen procesos definidos, inspecciones, ingeniería de requerimientos, matrices de seguimiento, métricas, controles de calidad precisos, planificación y seguimiento rigurosos, y estándares de codificación y documentación. Todo esto para lograr prácticas consistentes y predictibilidad.
La consistencia y la predictibilidad todavía son deseables, pero nunca fueron las cosas más importantes. Por ejemplo, durante los últimos 40 años nos venimos torturando por nuestra incapacidad de terminar un proyecto de software en tiempo y en presupuesto. Pero como anticipé, esto nunca debería haber sido nuestra meta suprema. El objetivo más importante es la transformación, crear software que cambie al mundo o que transforme a una organización o a cómo hace negocios.
Tuvimos bastante éxito en la transformación, a menudo operando fuera de un entorno controlado. El desarrollo de software es y siempre será algo experimental. La construcción propiamente dicha del software no es necesariamente experimental, pero sí lo es su concepción. Y allí es donde debería estar nuestro foco. Y es donde siempre debería haber estado.
