Buscar en Gazafatonario IT

jueves, abril 23, 2015

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

“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.”

13 comentarios:

  1. Lamentablemente nuestras organizaciones han crecido muchos roles que se encargan del control y no se ha avanzado efectivamente en trabajar colaborativamente con los desarrolladores de software.

    ResponderBorrar
  2. Que buen Post Lucho, creo que es importante medir y controlar, pero cuando se trata de procesos industriales y/o tareas monótonas; por ejemplo: Sembrar Caña, Construir una Pared, Encofrar columnas de hormigón, etc. En estos casos tiene sentido medir la productividad (horas/hombre u horas/maquina), para poder estimar, predecir y planificar el futuro.

    En las profesiones creativas, que tienen un toque de Arte y otro de Ciencia, como la Ingeniería de Software, donde se pretende plasmar la representación de la realidad en un ente abastracto (software), no tienen ningún sentido medir productividad, ya que descubrir la esencia de la solución, no es proceso monótono o repetitivo, es variable y muchas veces se falla en las primeras interpretaciones, al final lo que deberíamos medir es VALOR entregado y no cantidad de trabajo realizado en el tiempo, que como tu lo mencionaste puede ser de baja calidad, por las presiones de tiempos y el control.

    ResponderBorrar
    Respuestas
    1. ¡Oscar, gracias!

      Tú has dado en el clavo: esto de la medición en la Ingeniería de Software también es una causa de haber tomado prestado en sus inicios prácticas de otras áreas aplicadas, por ejemplo, de la Ingeniería Civil, de la Mecánica o de la Industrial. Imagino que eso fue lo que le pasó de DeMarco por allá a principios de los 80 cuando empezó a escribir su libro.

      Afortunadamente, ya nos dimos cuenta que la Ingeniería de Software tiene su propia personalidad y, aunque es posible tomar prestado prácticas, preceptos y herramientas de otras industrias y áreas, también tiene su propio ecosistema, con un carácter y fisionomía propias que la hace y que nos hace (a quienes la practicamos) únicos.

      Salud@s.

      Borrar
    2. Si lo importante es el valor entregado...¿es válido medirlo? ¿Cómo miden el valor entregado? ¿Cómo generan conciencia en los equipos sobre lo que es valor? Si el manifiesto propone medir 'software funcionando'...es válido medirlo? ¿Cómo miden 'software funcionando'?

      Borrar
    3. Posiblemente, el hecho de medir no sea el malo; la métrica por sí mismo no es el problema. El problema -desde mi punto de vista- es el uso de la métrica con fines punitivos y no con fines de aprendizaje o de mejorar (uso no focal de la herramienta). El problema es medir cosas que no son importantes y que no nos aportan a tomar una decisión y una acción (métricas vanidosas). Una métrica es una herramienta, más puede ser mal utilizada. Considero que parte de nuestra labor como practicantes y coaches ágiles es generar conciencia de qué cosas hay que medir, el por qué, qué preguntas nos ayuda a resolver y qué acciones nos ayuda a enfocar; medir para aprender y accionar...debemos ayudar a transparentar esta información.

      Borrar
    4. ¡Johnny, estamos de acuerdo! Ya aprendimos además que la medición debe hacerse por observación en el gemba y no mediante una encuesta fría respondida muy lejos de donde ocurre la "acción". Muchas gracias por tu participación en el foro, como siempre, tus aportes son valiosísimos para quienes te seguimos.
      ¡Saludos, un abrazo!

      Borrar
  3. Lucho que gran post
    Que valioso darse cuenta que los autores que influienciaron tendencias que hoy tienen a nuestra industria enfrascada en fracasos, cambian de forma de ver las cosas, lo que cuesta es transmitir esta visión a los influenciados.. pero en esas estamos..
    Nos queda mucho trabajo por hacer..
    Pero con argumentos como estos y más aun con los resultados lograremos que menos ingenier@s pierdan sus familias por excesivo tiempo dedicado a jornadas laborales inhumanas en proyectos donde la predectibilidad es inoperante.
    Soltemos el control y busquemos satisfacer objetivos… es más ganador y se genera menos desperdicio

    Pdta: gracias por citarme compa..

    Un abrazo y hasta la próxima

    ResponderBorrar
  4. Es importante matizar el "control" dentro de los proyectos de software; es decir, aún las metodologías ágiles establecen algún sistema métricas para el control del proyecto y la calidad, entiendase Burn down chart, para medir la velocidad y productividad del equipo; ¿para qué son las reuniones diarias y la revisión de sprint si no para establecer algún mecanismo de medición para mejorar el proceso?

    ResponderBorrar
    Respuestas
    1. Carlos, muchas gracias por el comentario.
      Como dice Oscar en una nota más arriba, ¿cómo se mide la productividad de un proceso que todavía tiene mucho de creativo, como el desarrollo de software? Por eso nos gusta que el software funcionando sea la medida universal de progreso. Si en cada iteración entregas un incremento del producto (software) que sea de Valor para el negocio (usuario), que incluso lo pueda poner en producción, que resulte en Retorno de la Inversión, que resuelva parte de un gran problema o varios problemas pequeños, entre otras características, eso permite conocer el estado del proyecto y mejor aun, el estado del producto, permite conocer no solo que se ha hecho, sino qué hace falta, permite conocer también la calidad exacta de lo que va del producto, el nivel de satisfacción y, más que eso, el grado de felicidad del cliente (usuario), ni hablar de la velocidad efectiva del equipo, pero más que ello, el estado de ánimo de los miembros del equipo, entre otros aspectos que miden la realidad del proyecto y que sirven de fundamento para seguir encontrando, vía retrospectivas u otras sesiones de Scrum, encontrar formas mejores de hacer las cosas, el mejoramiento continuo que, como ya sabemos, es el corazón del enfoque ágil, es lo que nos interesa, más que el hacer, encontrar continuamente formas mejores de trabajar.
      Saludos,

      Borrar
  5. Este comentario ha sido eliminado por el autor.

    ResponderBorrar
  6. Estoy de acuerdo que lo valioso es el software útil funionando, sin ambargo, como lo mencioné en mi aportación anterior, ese "incremento de software" es una medida de éxito al final, y es también un indicador de productividad del equipo; es decir, de alguna forma se está mediendo y controlando el proyecto, que se ponga enfasis en otros factores (métricas), eso es otra cosa, el punto es que se sigue midiendo de alguna manera, incluso la motivación del equipo es un indicador que permite retroalimentar el proceso en aras de mejorar. Incluso las metodologías ágiles buscan controlar de alguna manera el cumplimiento de lo comprometido en cada sprint, y eso lleva a los ajustes necesarios para adaptarse a las circusntancias.

    Por lo anterior, comentaba que se debe poner en contexto los conceptos métrica, medición y control.

    ResponderBorrar
    Respuestas
    1. De acuerdo, Carlos. Ese es el punto: ¿las métricas para qué? Si vas a medir el número de errores de un programador por cada mil líneas de código y cosas así para simplemente "calificarlo" a fin de año y ver si le aumentas o bajas el sueldo o lo promueves, estás en el lugar equivocado. Si vas a hacer eso mismo para entonces tomar medidas como entrenamiento y acompañamiento a ese programador, entre otras, entonces sí vale la pena. Pero incluso así, el entrenamiento y acompañamiento debería ser independiente del desempeño de la personaje, el objetivo debe ser siempre buscar formas mejores de hacer las cosas. Allí es donde marcamos la diferencia usando el enfoque Ágil: no concentrarnos tanto en el hacer como en el buscar continuamente formas mejores del hacer. Ese es el corazón de Ágil.

      Borrar
  7. Excelente Post Lucho, de los mejores que te he leído. Vamos derrotando de a poco esas métricas que buscan control y sólo alejan la motivación de los equipos

    ResponderBorrar