“El
Control conduce al cumplimiento; la autonomía conduce al compromiso”
― Daniel H. Pink (Autor de “A Whole New Mind: Why Right-Brainers Will
Rule the Future”)
 |
| Imágen tomada del artículo de Computer.org |
En 1982, Tom
DeMarco escribió su renombrado libro “Controlling
Software Projects: Management, Measurement, and Estimation” (Prentice
Hall/Yourdon Press, 1982). La primera frase del libro, su
primerísima idea, quedó ensamblada en los anales de la industria de software
durante las siguientes décadas y nos ha llegado intacta hasta esta era. Se
trata de su: “No puedes controlar lo que
no puedes medir”.
Este pensamiento influyó de manera certera en los
modelos de calidad, procesos de producción, enfoques de mejora* y herramientas
de construcción de software, quizás como ninguna otra idea de aquellos tiempos.
Pero incluso Tom DeMarco cambió de opinión. En 2009 publicó este artículo en la
IEEE Computer Society: “Software Engineering: An Idea Whose Time Has
Come and Gone?” (Ingeniería de Software: ¿una idea cuyo
momento ha pasado?)” que pueden encontrar haciendo clic aquí.
En el artículo, DeMarco reflexiona sobre si este
consejo era correcto en ese momento, sobre si todavía era relevante (al momento
de escribir ese artículo en 2009) y que si todavía creía que las métricas eran
un deber ser para cualquier esfuerzo exitoso de desarrollo de software. Sus
propias respuestas fueron unos tajantes no,
no y no.
Es bien conocida la historia de que los enfoques
rígidos más tradicionalistas adhirieron completamente a este precepto y crearon
áreas de proceso y de conocimiento dedicadas en su totalidad al
establecimiento, gestión y control de métricas en los proyectos (de software).
A partir de allí, se empezó a medir el éxito o fracaso de los proyectos, en
principio, con tres de esas medidas: el tiempo, el presupuesto y la calidad,
siendo esta última un poco más abstracta y más subjetiva si se quiere. Después,
con muchas otras que no vale la pena mencionar aquí.
Esa institucionalización de métricas derivó a su vez en
algo que con el tiempo se convirtió en uno de los mayores desincentivos para
quienes trasegamos por los laberintos azarosos de la construcción de productos
de software: el trabajo intensivo,
esas largas jornadas de trabajo de doce, dieciséis y más horas diarias durante
largos períodos de tiempo previos a la entrega del producto. Mi amigo y colega Jorge Abad dice en su blog Lecciones-Aprendidas.info
que eso trajo como consecuencia la destrucción de hogares, de familias enteras
y yo le creo.
Esta forma de trabajo extrema, cuya consecuencia
principal, además de la citada por Jorge,
era la de un bajón en productividad, acompañado de una entrega de producto con
mala o malísima calidad, con el tiempo degeneró en algo mucho más grave que es
de todos conocido: desmotivó a las nuevas generaciones a estudiar carreras
relacionadas con la TI: Ingeniería Informática, de Sistemas, de Software y
afines. El mismo Tom DeMarco (¡otra vez!) enunció en su otro libro, “Peopleware : Productive Projects and Teams”
(2ª edición, 1999), que “no trabajamos horas extras en demasía para terminar el
trabajo a tiempo sino para protegernos de culpa
cuando inevitablemente no conseguimos hacer el trabajo a tiempo.” En efecto, lo
hacíamos simplemente para cumplir, no para ser más productivos, ni para mejorar
la calidad del producto. Y a eso nos llevó la fuerza ejercida por el modelo de
Comando y Control y de la medición de cosas que no reflejaban la realidad del proyecto, al menos no la
realidad de las personas que ejecutaban el proyecto.
La reflexión de DeMarco en el artículo que ya he citado
termina también de manera asombrosa para quienes seguimos sus cánones durante
casi tres décadas: “Consistencia y predictibilidad aun son deseables, pero
nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad
de terminar proyectos de software a tiempo y en el presupuesto. Pero esta
nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que
transforme una compañía o cómo esta hace negocios.”
Bien sabemos ya que lo más importante en los proyectos
de software es la entrega continua y frecuente de Valor al negocio, desde el inicio del proyecto. Y que nunca más
apostaremos o usaremos artes adivinatorias para establecer la fecha de entrega,
ni qué parte del producto entregaremos en ese momento, ni cuánto será su costo.
En cambio, empezaremos con planes y alcance iniciales y nos enfocaremos en la
revisión continua de esas restricciones a medida que vamos avanzando.
Finalmente, nuestra meta será siempre entregar el mejor producto posible,
teniendo presente que ningún método con el enfoque de receta de cocina (léase
métodos tradicionalistas) hará mejor lo que es mejor. Esta es la filosofía ágil.
Coletilla
Aquella aciaga
prescripción de DeMarco sobre lo que se puede medir y controlar derivó en
procesos rígidos, tradicionalistas, que dieron poder solo a algunas personas en
la organización; pero lo realmente hermoso, lo humanamente divino, es que los
métodos y las prácticas ágiles dan poder a todo el mundo… o a nadie.
--------------------------------------------------
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”
