La productividad de les desarrolladores y McKinsey
Recientemente la consultora McKinsey sacó un artículo sobre como medir la productividad de les desarrolladores. Lo interesante para mí no es el artículo en sí, si no el revuelo que se armó alrededor de él. Muy rápidamente varios referentes de la industria salieron a comentar el artículo.
Grady Booch comentó brevemente en un hilo de Twitter (también conocido como X).
Martin Fowler referenció un artículo de su bliki del 2003 donde comenta que no es posible.
Dave Farley le dedicó un vídeo analizando cada un una de las métricas propuestas por el artículo de McKinsey.
Daniel Terhorst-North prometió escribir su análisis sobre el artículo (ver actualización), pero antes hizo referencia a un artículo de su blog sobre Tim, el peor programador que ha conocido, el cuál me recordó a una anécdota del libro Peopleware de Tom DeMarco y Tim Lister donde una Cía quería saber en qué era una persona buena que ha participado en varios proyectos exitosos dentro de la Cía, pero que parecía ser una persona más del montón, la conclusión de los autores es que esa persona era "la mermelada" que unía a los equipos y al igual que Tim era muy difícil de cuantificar su aporte dentro de un equipo.
Kent Beck y Gergely Orosz decidieron analizar en conjunto el artículo dar sus opiniones al respecto y su opinión particular sobre medir la productividad de los desarrolladores. Dividieron sus comentarios sobre el artículo en dos partes y las publicaron en sus respectivos blogs:
La disidencia de opinión entre Beck y Orosz posiblemente sea por diferencias en su recorrido profesional y porque Orosz ha invertido en la startup DX que propone el framework de productividad DevEx.
Por otro parte, John Cutler propone una sencilla actividad midiendo el tiempo ocupado en tareas productivas e improductivas.
Y mirando otra cuestión que surgió en varios hilos de Twitter, Lorin Hochstein escribió que el objetivo del artículo es brindar una herramienta (las propuestas del artículo) para permitir apalancar ciertos cambios dentro de la organización.
¿Y qué pienso yo? Creo que McKinsey quiere hacer nuevos negocios implementando las métricas que propone, después de todo se dedican a la consultoría, habilitando a los managers a realizar ciertos cambios basados en dichas métricas e hizo un buen trabajo cubriéndose al hacer una advertencia sobre los peligros de las métricas al final de artículo, pero propone hacer mediciones polémicas como contribución individual y capacidad individual.
Analizar las contribuciones individuales automáticamente deja afuera a los Tim y medir las capacidades individuales puede resultar algo elusivo y complejo. Una persona puede ser considerada experta con la tecnología Z y no saber algún concepto básico (ej: una variable declarada con var en JavaScript define una variable global; manejo de conflictos en git). Esa falta de conocimiento se hará evidente en caso de necesidad (en los ejemplos: debuggeando un problema productivo o tratando de promover cambios en una rama vieja) y quizás solo evidencia la falta de exposición al problema y no una falta de capacidad. Otro escenario es la comparación entre dos personas, ¿quién posee mayores capacidades? ¿Cómo medimos esas diferencias? ¿Es lo mismo no saber estructuras de control, modelado de problemas con objetos o servicios de tu proveedor de nube favorito?
Porque al final del día la pregunta es, ¿qué harán los líderes de las organizaciones con esa información de las personas? ¿La utilizarán para entender cómo contribuyen dentro de un equipo o para capacitarlas o para decidir si están aptas para una promoción, un bono, un aumento de sueldo o si se deben despedir? Es decir, el problema no son las herramientas en sí mismas, en este caso las métricas, si no para qué se utilizarán y creo que en general se insumirá tiempo, dinero y energía en implementar esas métricas para poder hablar de las segundas.
ACTUALIZACIÓN 2023-10-13
Daniel Terhorst-North publicó este artículo revisando al detalle el artículo de McKinsey. Me parece la crítica más detallada hacia al artículo que ví hasta el momento. Ataca dos argumentos que el encuentra que son los principales:
- El desarrollo de software es una actividad reducible y se puede medir con herramientas reduccionistas.
- El desarrollo de software consiste principalmente en programmar, y cualquier cosa que no sea escribir código en una terminal de computadora es un desperdicio que deberíamos tratar de eliminar.
Estoy de acuerdo con que estas nociones que derivan de ideas de administración cientifíca de la producción en serie no es posible aplicarñas en el desarrollo de software por ser una ante todo una tarea creativa, pero no por ello sin fundamentos, ni sin metodologías o heurísticas.
