Los KPIs de ingeniería que importan de verdad
Una vez asistí a una reunión de junta en la que un VP de Ingeniería presentó un dashboard con doce métricas. Líneas de código por desarrollador. Número de PRs por sprint. Story points completados. Todo en verde. La junta asintió.
Dos meses después, el producto seguía sin poder dar de alta a un cliente sin un parche manual, los despliegues se rompían una semana sí y otra no, y dos ingenieros senior habían empezado a hacer entrevistas en otras empresas.
El dashboard medía actividad. Nadie medía si la organización de ingeniería estaba sana, era productiva o estaba mejorando. Esa es la trampa: los equipos eligen las métricas fáciles de recopilar en lugar de las que les dicen algo útil.
Las métricas que sí te dicen algo
Métricas DORA: tu línea base de entrega
Ya he escrito en profundidad sobre las métricas DORA, así que no voy a repetir aquí todo el argumento. Pero las cuatro métricas DORA — frecuencia de despliegue, lead time de los cambios, tiempo medio de restauración y tasa de fallos en cambios — son lo más parecido que tenemos a una medida científicamente validada del rendimiento en la entrega de software.
Siguen siendo los cimientos. Si no las estás midiendo, empieza por ahí antes de añadir nada más. Te dicen si tu equipo puede entregar con fiabilidad y recuperarse rápido, que es la base de todo lo que viene después.
Cycle time: de la idea a producción
El cycle time es más amplio que el lead time de DORA. Mide el recorrido completo desde «decidimos construir esto» hasta «está en producción y los usuarios lo están tocando». Eso captura las decisiones de producto, los traspasos de diseño, las aclaraciones de la especificación: todos los cuellos de botella ajenos al código que los equipos de ingeniería heredan.
Cuando el cycle time es alto pero el lead time de DORA es bajo, el problema no es la ejecución de ingeniería. Es todo lo que ocurre antes: especificaciones poco claras, aprobaciones lentas, cuellos de botella en diseño o demasiadas cosas en marcha a la vez. El cycle time revela el lastre organizativo, no solo el del pipeline.
Mídelo registrando el momento en que un ticket pasa de «listo para desarrollo» a «desplegado». La mayoría de las herramientas de gestión de proyectos lo muestran con una configuración mínima.
Incidentes con impacto en clientes
No todos los incidentes son iguales. Un job en segundo plano que falla y se reintenta con éxito no es lo mismo que tener el checkout caído 40 minutos un viernes por la tarde. Lo que importa es la frecuencia y la gravedad de los incidentes que los usuarios notan de verdad.
Mide dos cosas:
- Frecuencia de incidentes — ¿cuántos incidentes con impacto en clientes hay al mes?
- Distribución de gravedad — ¿son SEV-1 (críticos para el negocio) o SEV-3 (degradación menor)?
Un equipo con dos SEV-3 al mes está en una posición radicalmente distinta a la de un equipo con dos SEV-1 al mes, aunque el recuento sea idéntico. Agregar sin distinguir la gravedad no significa nada.
La tendencia importa más que el número absoluto. ¿Los incidentes disminuyen con el tiempo? ¿La gravedad va a la baja? Eso te dice si tus inversiones en fiabilidad están funcionando.
Tiempo hasta el primer valor de las nuevas incorporaciones
Esta métrica está infravalorada y casi nadie la mide: ¿cuánto tarda un ingeniero recién llegado en poner algo significativo en producción?
No «cuánto tarda en mergear la corrección de una errata». Cuánto tarda en entregar un trabajo de verdad: una funcionalidad, un bug fix con impacto en el negocio, una mejora de infraestructura con sustancia.
Si tus nuevos ingenieros tardan seis semanas en entregar su primera contribución real, tienes un problema de onboarding, un problema de complejidad en la base de código, o ambos. Los mejores equipos que he visto consiguen que las nuevas incorporaciones entreguen en la primera semana. No porque tomen atajos, sino porque han invertido en documentación, en experiencia de desarrollador y en una propiedad del código clara.
Esta métrica también te dice algo sobre la calidad de tu contratación. Si un ingeniero tarda tres meses en ser productivo sea cual sea su seniority, el problema probablemente es tu entorno, no la persona.
Satisfacción y compromiso del equipo de ingeniería
Lo sé: suena blando. Pero la retención de ingenieros es una de las partidas de coste más caras que no estás midiendo, y cuando alguien presenta su dimisión, el daño ya está hecho. En mi experiencia, reemplazar a un ingeniero senior te cuesta seis meses de salario y doce meses de contexto.
Lanza una encuesta de pulso trimestral. De cinco a siete preguntas: ¿crees en lo que estamos construyendo? ¿Tienes las herramientas para hacer tu mejor trabajo? ¿Sientes que estás creciendo? ¿Recomendarías este equipo a un amigo? Sigue las tendencias. Una tendencia a la baja durante dos trimestres es una alarma de incendios.
Las métricas peligrosas
Algunas métricas no es que no ayuden: dañan activamente a los equipos cuando la dirección les presta atención.
Líneas de código. Un desarrollador que borra 500 líneas de código muerto y simplifica un módulo ha hecho un trabajo más valioso que el que escribió 500 líneas nuevas para resolver un problema que podría haberse evitado. Medir líneas de código incentiva el bloat.
Recuento de commits. Fácil de amañar, trivial de inflar, y no te dice nada sobre la calidad ni el impacto del trabajo. Un desarrollador peleándose con un problema arquitectónico difícil puede tener tres commits en una semana. Uno produciendo boilerplate puede tener treinta. Los tres commits probablemente valen más.
Métricas de output individual. Clasificar a los desarrolladores por número de PRs o de tickets cerrados crea una competencia que destruye la colaboración. Las mejores culturas son de equipo. El ranking individual empuja a la gente hacia el comportamiento de héroe y la aleja de las revisiones de código, de la mentoría y de ayudar a desbloquear a los compañeros.
Horas registradas. Miden presencia, no productividad. Los ingenieros senior suelen hacer su trabajo de más impacto en muy pocas horas. Si mides horas, estás gestionando una cadena de montaje.
Cómo presentar métricas a la dirección sin que acaben amañadas
La junta quiere saber tres cosas: ¿el equipo es efectivo? ¿Está mejorando? ¿Dónde están los riesgos?
Esta es la estructura que uso:
Rendimiento de entrega — métricas DORA, con tendencia trimestral. Enseña la dirección, no solo el número. «Nuestra frecuencia de despliegue pasó de semanal a diaria este trimestre, y la tasa de fallos en cambios bajó del 22% al 11%.» Esa es una historia que la junta puede seguir.
Calidad y fiabilidad — incidentes con impacto en clientes, con tendencia mensual y desglose por gravedad. Si los incidentes suben, explica por qué (un área de producto nueva, retos de escalado) y qué estás haciendo al respecto.
Salud del equipo — tiempo hasta el primer valor de las incorporaciones recientes, más las tendencias de compromiso. Son indicadores adelantados. Un equipo sano, con buen onboarding y compromiso alto, entregará. Un equipo quemado con un onboarding roto es un riesgo, aunque el output actual parezca correcto.
Un aviso importante: presenta métricas de equipo, nunca métricas individuales. En el momento en que un miembro de la junta vea una lista de desarrolladores ordenada por rendimiento, te pedirá que gestiones según esa lista. Y entonces la métrica se convierte en el objetivo, el objetivo se amaña y has perdido la señal por completo.
Mantén el dashboard en cinco o seis métricas. Si necesitas doce métricas para explicar cómo va ingeniería, es que no entiendes cómo va ingeniería.
La métrica detrás de la métrica
Toda métrica es un proxy. Las métricas DORA son un proxy de la capacidad de entrega. El recuento de incidentes, un proxy de la fiabilidad. Las puntuaciones de compromiso, un proxy del riesgo de rotación. Ninguna captura el cuadro completo por sí sola.
La verdadera habilidad del liderazgo de ingeniería está en saber de qué proxies fiarse, cuándo investigar más a fondo y cuándo un número te está diciendo lo que quieres oír en lugar de lo que está pasando de verdad.
En Conectia, cuando integramos ingenieros senior en un equipo, a menudo se convierten en el catalizador de una medición mejor — no porque instalen dashboards, sino porque traen el hábito de preguntar «¿cómo sabemos que esto está funcionando?». Han visto suficientes equipos para distinguir qué señales importan y cuáles son ruido. Esa mentalidad no te la da ninguna métrica.
¿Quieres ingenieros que aporten el criterio de saber qué medir y qué ignorar? Habla con un CTO.
