Los KPIs de Ingeniería que Realmente Importan
Una vez asistí a una reunión de junta directiva donde un VP de Ingeniería mostró un dashboard con doce métricas. Líneas de código por desarrollador. Cantidad de PRs por sprint. Story points completados. Todo estaba en verde. La junta asintió.
Dos meses después, el producto aún no podía incorporar un cliente sin una solución manual, los despliegues fallaban cada dos semanas y dos ingenieros senior habían empezado a hacer entrevistas en otros lugares.
El dashboard medía actividad. Nadie medía si la organización de ingeniería era saludable, productiva o estaba mejorando. Esa es la trampa: los equipos eligen métricas que son fáciles de recopilar en lugar de métricas que les digan algo útil.
Las Métricas que Realmente Te Dicen Algo
Métricas DORA: Tu Línea Base de Entrega
He escrito sobre las métricas DORA en profundidad antes, así que no repetiré el argumento completo aquí. Pero las cuatro métricas DORA — Frecuencia de Despliegue, Lead Time para Cambios, Tiempo Medio de Restauración y Tasa de Fallos en Cambios — son lo más cercano que tenemos a una medida científicamente validada del rendimiento en la entrega de software.
Siguen siendo la base. Si no las estás midiendo, empieza por ahí antes de añadir nada más. Te dicen si tu equipo puede entregar de forma fiable y recuperarse rápidamente, lo cual es la línea base para todo lo que viene después.
Cycle Time: De la Idea a Producción
El cycle time va más allá del lead time de DORA. Mide el recorrido completo desde "decidimos construir esto" hasta "está en producción y los usuarios lo están usando". Esto captura las decisiones de producto, los traspasos de diseño, la aclaración de especificaciones: todos los cuellos de botella que no son 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 está en la ejecución de ingeniería. Está en todo lo anterior: especificaciones poco claras, aprobaciones lentas, cuellos de botella en diseño, o demasiadas cosas en progreso a la vez. El cycle time revela el lastre organizativo, no solo el lastre del pipeline.
Mídelo con marcas de tiempo de cuando un ticket pasa de "listo para desarrollo" a "desplegado". La mayoría de las herramientas de gestión de proyectos pueden mostrar esto con una configuración mínima.
Incidentes con Impacto en Clientes
No todos los incidentes son iguales. Un trabajo en segundo plano fallido que reintenta con éxito no es lo mismo que el checkout caído durante 40 minutos un viernes por la tarde. Lo que importa es la frecuencia y gravedad de los incidentes que los usuarios realmente sienten.
Mide dos cosas:
- Frecuencia de incidentes — ¿cuántos incidentes con impacto en clientes hay por mes?
- Distribución de gravedad — ¿son SEV-1 (críticos para el negocio) o SEV-3 (degradación menor)?
Un equipo que tiene dos SEV-3 por mes está en una posición fundamentalmente diferente a uno que tiene dos SEV-1 por mes, aunque el recuento sea idéntico. Agregar sin gravedad no tiene sentido.
La tendencia importa más que el número absoluto. ¿Están disminuyendo los incidentes con el tiempo? ¿Está bajando la gravedad? Eso te dice si tus inversiones en fiabilidad están funcionando.
Tiempo-hasta-Primer-Valor para Nuevas Incorporaciones
Esta está subestimada y casi nadie la mide: ¿cuánto tiempo tarda un nuevo ingeniero en entregar algo significativo a producción?
No "cuánto tiempo hasta que fusionan una corrección de tipografía". Cuánto tiempo hasta que entregan un trabajo real: una funcionalidad, un bug fix con impacto en el negocio, una mejora de infraestructura significativa.
Si a los nuevos ingenieros les lleva seis semanas entregar su primera contribución real, tienes un problema de onboarding, un problema de complejidad de la base de código, o ambos. Los equipos de élite logran que las nuevas incorporaciones entreguen en la primera semana. No porque recorten esquinas, sino porque han invertido en documentación, experiencia del desarrollador y propiedad clara.
Esta métrica también te dice algo sobre la calidad de las contrataciones. Si un ingeniero tarda tres meses en ser productivo independientemente de su seniority, el problema probablemente es tu entorno, no la persona.
Satisfacción y Compromiso de Ingeniería
Lo sé: suena blando. Pero la retención de ingeniería es una de las líneas de coste más caras que no mides, y cuando alguien presenta su dimisión, el daño ya está hecho. Reemplazar a un ingeniero senior cuesta seis meses de salario y doce meses de contexto.
Realiza 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? Registra las tendencias. Una tendencia a la baja durante dos trimestres es una alarma de incendios.
Las Métricas Peligrosas
Algunas métricas no solo son inútiles — dañan activamente a los equipos cuando el liderazgo les presta atención.
Líneas de código. Un desarrollador que elimina 500 líneas de código muerto y simplifica un módulo ha hecho un trabajo más valioso que uno que escribió 500 líneas de código nuevo para resolver un problema que podría haberse evitado. Medir líneas de código incentiva el bloat.
Recuento de commits. Fácil de manipular, trivialmente inflado y no te dice nada sobre la calidad o el impacto del trabajo. Un desarrollador trabajando en un problema arquitectónico difícil podría tener tres commits en una semana. Un desarrollador produciendo boilerplate podría tener treinta. Los tres commits probablemente valen más.
Métricas de rendimiento individual. Clasificar a los desarrolladores por recuento de PRs o tickets cerrados crea competencia que destruye la colaboración. Las mejores culturas están orientadas al equipo. La clasificación individual empuja a las personas hacia el comportamiento de héroe y alejándose de las revisiones de código, la mentoría y ayudar a los compañeros de equipo a desbloquearse.
Horas registradas. Mide presencia, no productividad. Los ingenieros senior a menudo hacen su trabajo más impactante en las menos horas. Si mides horas, estás gestionando una línea de montaje.
Presentar Métricas al Liderazgo Sin Que Se Manipulen
La junta quiere saber tres cosas: ¿Es efectivo el equipo? ¿Está mejorando? ¿Dónde están los riesgos?
Esta es la estructura que uso:
Rendimiento de entrega — métricas DORA, con tendencia trimestral. Muestra la dirección, no solo el número. "Nuestra frecuencia de despliegue aumentó de semanal a diaria este trimestre, y la tasa de fallos en cambios bajó del 22% al 11%." Eso es una historia que la junta puede seguir.
Calidad y fiabilidad — incidentes con impacto en clientes con tendencia mensual, con desglose de gravedad. Si los incidentes aumentan, explica por qué (nueva área de funcionalidades, desafíos de escalado) y qué estás haciendo al respecto.
Salud del equipo — tiempo-hasta-primer-valor para las incorporaciones recientes, más tendencias de compromiso. Estos son indicadores adelantados. Un equipo saludable con un onboarding sólido y alto compromiso entregará. Un equipo agotado con un pipeline de onboarding roto es un riesgo, aunque el output actual parezca bien.
Una cosa de la que hay que tener cuidado: presenta métricas a nivel de equipo, nunca métricas individuales. En el momento en que un miembro de la junta vea una lista clasificada del rendimiento de los desarrolladores, te pedirá que gestiones por esa lista. Y entonces la métrica se convierte en el objetivo, el objetivo se manipula y habrás 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, 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 para la capacidad de entrega. Los recuentos de incidentes son un proxy para la fiabilidad. Las puntuaciones de compromiso son un proxy para el riesgo de retención. Ninguna captura el panorama completo por sí sola.
La habilidad real en el liderazgo de ingeniería es saber qué proxies confiar, cuándo investigar más y cuándo un número te está diciendo lo que quieres oír en lugar de lo que está pasando realmente.
En Conectia, cuando integramos ingenieros senior en un equipo, a menudo se convierten en el catalizador para una mejor medición — no porque instalen dashboards, sino porque traen el hábito de preguntar "¿cómo sabemos que esto está funcionando?". Han visto suficientes equipos para saber qué señales importan y cuáles son ruido. Esa es una mentalidad que no puedes obtener de una métrica.
¿Quieres ingenieros que aporten el criterio para saber qué medir y qué ignorar? Habla con un CTO — nuestros ingenieros senior de LATAM han trabajado en suficientes equipos para saber qué KPIs realmente mueven la aguja.
