Medir la velocidad de ingeniería sin caer en métricas de vanidad
"¿Qué tan rápido va el equipo?" es una pregunta justa con muchas respuestas malas. Líneas de código, commits, story points quemados — son fáciles de medir y fáciles de manipular, y ninguna te dice si el producto realmente avanza.
Medir bien la velocidad importa más a medida que los equipos adoptan tooling de IA, porque las herramientas inflan justo los números que ya eran engañosos. Así distingues actividad de progreso.
Qué se equivocan las métricas de vanidad
- Líneas de código premia la verbosidad. El mejor cambio suele ser un borrado.
- Conteo de commits o PRs premia partir el trabajo en ruido, no entregar valor.
- Story points miden estimación, no resultados — y se distorsionan en cuanto se usan como objetivo.
La ley de Goodhart hace el resto: cuando una medida se vuelve objetivo, deja de ser una buena medida. Todo lo que pongas en un dashboard y premies, la gente lo optimizará — incluso de formas que dañan el producto.
Señales que correlacionan con entregar
La investigación DORA popularizó cuatro que se sostienen entre equipos:
- Lead time de los cambios — cuánto tarda de "código escrito" a "corriendo en producción". Lead times cortos significan lotes pequeños y feedback rápido.
- Frecuencia de despliegue — cada cuánto entregas. Releases pequeños y frecuentes son más seguros que raros y grandes.
- Tasa de fallo de cambios — cada cuánto un release necesita un fix o rollback.
- Tiempo de recuperación — qué tan rápido te recuperas cuando algo se rompe.
A esas, súmales una que el equipo siente a diario: latencia de revisión — cuánto espera un PR su primera review. Suele ser el mayor freno oculto del flujo.
Acompaña los números con una narrativa
Las métricas te dicen dónde mirar, nunca por qué. Un pico en el lead time puede ser un pipeline inestable, una feature complicada o alguien enfermo. Pregúntale al equipo. La revisión más útil junta unas pocas líneas de tendencia con una explicación humana corta de qué cambió.
La IA sube las apuestas
Cuando un asistente escribe el boilerplate, el volumen de salida sube — pero el volumen nunca fue la meta. Sigue midiendo resultados (entregado, estable, fácil de cambiar) y resiste la tentación de premiar el rendimiento bruto, o tendrás más código y no más producto.
Sigue un conjunto pequeño de métricas de resultado, revísalas mensualmente contra una narrativa, y nunca conviertas un solo número en un objetivo.
Un buen conjunto inicial: lead time, tasa de fallo de cambios y latencia de revisión. Tres señales honestas le ganan a diez que halagan.