Productividad de ingeniería más allá de las líneas de código
Toda medida individual de productividad de programadores termina midiendo otra cosa y empeorando lo que pretendía mejorar. Lo que sí se puede medir son los obstáculos, y eso alcanza para mejorar mucho más.
Cada tanto alguien propone medir la productividad de los programadores: líneas de código, commits por semana, puntos de historia, pull requests cerrados. Todas las variantes fracasan del mismo modo, y el problema no es la elección de la métrica.
El problema es que el trabajo que más valor aporta casi nunca produce volumen: borrar código que sobra, evitar un proyecto innecesario, desbloquear a otras tres personas, elegir la solución simple. Medir volumen individual premia exactamente lo contrario.
Por qué falla cada intento
| Métrica individual | Qué mide en realidad | Qué conducta genera |
|---|---|---|
| Líneas de código | Verbosidad | Código largo y duplicado; borrar pasa a ser negativo |
| Cantidad de commits | Estilo personal de commitear | Commits partidos artificialmente |
| Puntos de historia | Cómo estima ese equipo | Inflación de estimaciones, sprint a sprint |
| Pull requests cerrados | Tamaño promedio de los cambios | Cambios más chicos pero también más triviales |
| Horas conectado | Presencia | Actividad simulada y desconfianza |
| Tickets cerrados | Qué tipo de tickets te tocaron | Elegir los fáciles y evitar los difíciles |
Antes de seguir, predecí
Qué sí se puede medir
| Dimensión | Qué mirar | Por qué sirve |
|---|---|---|
| Flujo del sistema | Las cuatro métricas de entrega: frecuencia, tiempo, fallas, recuperación | Son del equipo, no de la persona, y señalan el cuello de botella |
| Fricción del día a día | Cuánto tarda el build, cuánto la suite de tests, cuántas veces falla sin motivo | Cada minuto acá se multiplica por el equipo entero y por día |
| Interrupciones | Horas de trabajo sin fragmentar por persona y por semana | Es la variable que más afecta el trabajo cognitivo y la que más fácil se ignora |
| Espera | Tiempo que un cambio pasa sin que nadie lo toque | Suele ser la mayor parte del tiempo de entrega |
| Experiencia declarada | Una encuesta corta y periódica: qué te frenó esta semana | Es la única forma de ver los obstáculos que ningún sistema registra |
| Efecto en el producto | Uso real de lo entregado a las cuatro semanas | Evita el equipo eficientísimo construyendo lo que nadie usa |
Cuando piden medir personas
El pedido de medir productividad individual casi nunca viene de mala intención: viene de que alguien afuera del equipo no tiene ninguna visibilidad y quiere una. La respuesta útil no es negarse, es ofrecer lo que sí responde esa preocupación.
| La preocupación real detrás del pedido | Qué ofrecer en su lugar |
|---|---|
| «No sé en qué está trabajando el equipo» | Una vista del trabajo en curso y lo entregado, actualizada sola |
| «Siento que vamos lento» | El tiempo de entrega descompuesto: dónde espera un cambio |
| «¿Estamos entregando lo que importa?» | Uso de lo entregado y métricas de producto |
| «Creo que hay alguien que no rinde» | Eso es una conversación de desempeño con su líder, no una métrica |
| «Necesito justificar el presupuesto» | Efecto de lo entregado en tiempo, plata o riesgo |
La misma semana, medida de cuatro formas
Una semana de un equipo de cuatro. Empecemos por lo que es fácil de contar.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica