¿Tu empresa mide la productividad de los desarrolladores? ¿Qué mide realmente?

Casi todas las organizaciones quieren saber si sus equipos de desarrollo son productivos, y muchas creen que ya lo miden. Cuentan puntos de historia, tickets cerrados, líneas de código, horas dedicadas. La pregunta interesante no es si esas cifras se recogen, sino qué miden en realidad. Porque con frecuencia lo que parece una medida de productividad es, mirado de cerca, una medida de actividad, y no es lo mismo. Confundir ambas cosas no es un detalle técnico: cambia el comportamiento de los equipos, casi nunca para bien.

Actividad no es productividad

El primer malentendido es tratar la cantidad de trabajo realizado como si fuera valor generado. Un equipo puede cerrar muchos tickets, escribir mucho código y completar muchos puntos de historia, y aun así no mover ni una sola aguja que importe al negocio o al usuario. La actividad es fácil de contar. El valor es difícil de medir. Y por esa comodidad tendemos a medir lo fácil y llamarlo productividad.

El problema de fondo es que el trabajo de desarrollo de software no es una línea de producción donde más unidades equivalen a más resultado. Es trabajo de conocimiento, donde a menudo la mejor contribución es escribir menos código, eliminar complejidad, o dedicar un día a pensar antes de teclear. Medir la producción de líneas en ese contexto es como medir la calidad de un libro por el número de palabras.

La ley de Goodhart y por qué las métricas se corrompen

Hay un principio que todo el que mide equipos debería tener grabado. La antropóloga Marilyn Strathern lo formuló de forma memorable en 1997: cuando una medida se convierte en objetivo, deja de ser una buena medida. Es la conocida ley de Goodhart. En cuanto una cifra se usa para evaluar y premiar, las personas empiezan a optimizar la cifra en lugar de aquello que la cifra pretendía representar.

Los ejemplos en desarrollo de software son casi cómicos si no fueran caros. Si se mide por líneas de código, aparecerá código innecesariamente largo. Si se mide por tickets cerrados, los tickets se trocearán en pedazos minúsculos y se cerrarán deprisa. Si se mide por puntos de historia, la estimación se inflará hasta que el equipo "rinda" más sin hacer más. En todos los casos, la métrica sube y el valor real se estanca o empeora. Peor aún, medir al individuo por su producción individual erosiona la colaboración, porque ayudar a un compañero deja de ser rentable en la cuenta personal.

W. Edwards Deming, uno de los padres de la gestión de la calidad, ya advertía décadas atrás de que gestionar una organización solo por cifras visibles es uno de los errores más costosos, porque las cifras más importantes suelen ser desconocidas o imposibles de conocer. Su crítica a los objetivos numéricos impuestos sigue siendo vigente en cada cuadro de mando que confunde lo medible con lo importante.

Qué proponen los marcos serios

La buena noticia es que existe pensamiento riguroso sobre esto, y conviene apoyarse en él en lugar de improvisar métricas caseras.

La investigación de DORA, recogida por Nicole Forsgren, Jez Humble y Gene Kim en Accelerate (2018), identificó un conjunto de métricas de entrega que sí se correlacionan con el rendimiento de la organización. Se centran en el flujo y la estabilidad: cada cuánto se despliega, cuánto se tarda desde que se escribe un cambio hasta que llega a producción, con qué frecuencia un cambio provoca un fallo, y cuánto se tarda en recuperarse. Lo relevante de estas métricas es que miden capacidades del sistema de trabajo, no la producción de individuos, y que equilibran velocidad con estabilidad, de modo que no se puede hacer trampa acelerando a costa de romper cosas.

Más recientemente, el marco SPACE, desarrollado por Forsgren y otros en 2021, dio un paso importante al insistir en que la productividad del desarrollo es multidimensional y no puede capturarse con una sola cifra. Propone mirar a la vez la satisfacción y el bienestar de las personas, el rendimiento del sistema, la actividad, la comunicación y la colaboración, y la eficiencia del flujo. Su mensaje central es que cualquier métrica aislada engaña, y que medir solo la actividad, la dimensión más fácil, es precisamente la peor elección si se toma sola.

Mik Kersten, en Project to Product (2018), aporta otra pieza al desplazar el foco de la producción a la entrega de valor a través del flujo completo, midiendo cuánto valor cruza el sistema y cuánto tiempo se pierde en esperas y bloqueos. La pregunta deja de ser "¿cuánto produce cada persona?" y pasa a ser "¿con qué fluidez convierte la organización una idea en valor entregado?".

Para qué medimos, la pregunta que casi nunca se hace

Antes de discutir qué métrica es mejor, conviene detenerse en una pregunta previa que muchas organizaciones se saltan: ¿para qué queremos medir?

No es lo mismo medir para ayudar a un equipo a entender y mejorar su propio trabajo que medir para comparar personas y decidir bonus o despidos. El mismo dato cambia por completo de naturaleza según su propósito. Usado por el propio equipo como espejo para mejorar, una métrica de flujo puede ser valiosísima. Usada por la dirección para rankear individuos, esa misma métrica se corrompe de inmediato, porque activa la ley de Goodhart y destruye la confianza.

La distinción práctica es sencilla de enunciar y difícil de sostener. Las métricas deberían servir para aprender, no para juzgar personas. En cuanto se convierten en herramienta de evaluación individual, dejan de informar y empiezan a deformar. Un liderazgo maduro usa los datos para hacer mejores preguntas, no para repartir culpas.

El contexto de la IA: la tentación de medir lo que la IA infla

La irrupción de la inteligencia artificial ha añadido una dimensión nueva y urgente a este viejo debate, porque ha vuelto trivial inflar justamente las métricas de actividad que ya eran malas.

Con asistentes de IA, generar grandes cantidades de código es más fácil que nunca. Si una organización mide por líneas producidas o por volumen de commits, la IA disparará esas cifras sin que ello signifique más valor. Al contrario, puede significar más código que mantener, más complejidad y más deuda futura. Medir la productividad por output en la era de la IA es un error amplificado, porque la máquina produce output a raudales y el valor sigue dependiendo del criterio humano que decide qué merece existir.

La investigación empieza a matizar el entusiasmo. Los informes recientes de DORA observan que adoptar IA sin las prácticas adecuadas alrededor no garantiza mejoras en el rendimiento de entrega, y puede tensionar la estabilidad. La lección enlaza con todo lo anterior: si medimos lo fácil, la IA nos dará más de lo fácil. La pregunta que de verdad importa no cambia con la IA, solo se vuelve más apremiante. No es cuánto código producimos, sino cuánto valor entregamos y con qué salud del equipo y del sistema lo hacemos.

Medir la productividad de los desarrolladores no es imposible, pero exige resistir la comodidad de contar lo fácil y llamarlo valor. Las cifras de actividad son tentadoras porque están a mano y parecen objetivas, y son peligrosas por lo mismo, porque su apariencia de objetividad esconde que miden lo que no importa y deforman lo que tocan.

Quizá la mejor prueba para cualquier métrica que estemos usando sea preguntarnos con honestidad qué comportamiento provoca en el equipo. Si empuja a producir más señal y menos valor, a competir en lugar de colaborar, a maquillar en lugar de mejorar, entonces esa métrica está trabajando en nuestra contra por muy bien que suene en un informe. Medir bien no es medir mucho, sino medir aquello que, mirado, hace que el equipo trabaje mejor.

¿Y en tu empresa? ¿Se mide la productividad de los desarrolladores? Y si te paras a mirarlo con calma, ¿qué mide realmente eso que medís?

Bibliografía

Deming, W. E. (2000). Out of the Crisis. MIT Press.
Doerr, J. (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio.
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of Developer Productivity. ACM Queue, 19(1).
Google Cloud / DORA (2024). Accelerate State of DevOps Report 2024.
Kersten, M. (2018). Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press.
Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
Strathern, M. (1997). 'Improving ratings': audit in the British University system. European Review, 5(3), 305-321.