Liderazgo · Métricas
Cómo mido la salud de un equipo de ingeniería.
Sigo tres grupos de números: qué tan rápido entrega el equipo, qué tan sanos están el equipo y sus sistemas, y si el trabajo llega a los usuarios. Ahora que los asistentes de IA escriben buena parte del código, importa una cuarta pregunta: ¿la IA realmente está mejorando al equipo, o solo lo mantiene más ocupado?
Acompaña cada métrica de velocidad con una de calidad o de salud, e incluye al menos un número que los usuarios reconozcan. Apóyate en marcos establecidos como DORA y SPACE en lugar de inventar el tuyo. Para juzgar a los asistentes de IA, mira el lead time, la tasa de fallas por cambio y el tiempo de revisión, nunca las líneas de código.
Las métricas que sigo
| Grupo | Métrica | La pregunta que responde |
|---|---|---|
| Entrega | Lead time de los cambios | ¿Cuánto pasa desde un commit hasta que corre en producción? |
| Entrega | Frecuencia de despliegue | ¿Con qué frecuencia podemos desplegar de forma segura? |
| Entrega | Tasa de fallas por cambio | ¿Con qué frecuencia un despliegue causa un problema? |
| Salud | Relación entre lo comprometido y lo entregado en el sprint | ¿Entregamos lo que nos comprometimos a entregar? |
| Salud | Tiempo de incorporación | ¿Qué tan rápido un ingeniero nuevo entrega su primer cambio real? |
| Salud | Conciliación de datos | ¿Nuestros sistemas coinciden entre sí? |
| Impacto | Core Web Vitals | ¿El producto es rápido para los usuarios reales? |
| Impacto | Tiempo de entrega de reportes | ¿Cuánto pasa desde una pregunta de negocio hasta una respuesta confiable? |
Parte de marcos establecidos
No necesitas inventar un sistema de medición. Dos marcos cubren casi todo lo que importa:
- Las métricas DORA, del programa DevOps Research and Assessment de Google: frecuencia de despliegue, lead time de los cambios, tasa de fallas por cambio y tiempo para restaurar el servicio. Miden qué tan bien entrega software un equipo.
- El marco SPACE mira la productividad de forma más amplia: satisfacción y bienestar, desempeño, actividad, comunicación y colaboración, y eficiencia y flujo. Recuerda que la actividad por sí sola nunca cuenta toda la historia.
Mi lista usa DORA para la entrega y agrega los números de salud e impacto que importan en el tipo de plataformas que construyo.
Cómo se vieron los números en la práctica
- Impacto en Fincaraiz. Durante la migración a microservicios, nuestro número de cara al usuario fue el Largest Contentful Paint. Lo mantuvimos por debajo de 3 segundos, igual que el sitio anterior, lo que protegió tanto la experiencia de usuario como las posiciones en buscadores.
- Conciliación en la distribución de leads. En nuestro sistema B2B de distribución de leads, conciliamos cada lead de nuestros reportes con el CRM del aliado y mantuvimos una coincidencia del 100%.
- Tiempo de entrega de reportes en Cedar Planters. Al construir la plataforma de datos, la pregunta clave era qué tan rápido una pregunta de negocio se convertía en un tablero confiable.
Medir el impacto de los asistentes de IA
La mayoría de los equipos ya usa asistentes de programación con IA. La tentación es medirlos por volumen: más pull requests, más líneas, más tickets cerrados. Esos números suben con facilidad y demuestran muy poco. Lo que yo miro en cambio:
| Qué mirar | Señal sana | Señal de alerta |
|---|---|---|
| Lead time de los cambios | Baja, y se mantiene | Se programa más rápido pero el lead time no se mueve |
| Tasa de fallas por cambio | Estable o a la baja | Sube a medida que se despliega más código |
| Tiempo de revisión | Estable | Los pull requests se acumulan esperando revisión |
| Retrabajo | Estable | Más código se reescribe o se revierte poco después de integrarse |
| Satisfacción de los desarrolladores | La gente dice que dedica menos tiempo a tareas repetitivas | La gente siente que revisa más de lo que construye |
Un patrón común es que el cuello de botella se mueve: la IA acelera la escritura de código y la fila se traslada a la revisión y las pruebas. No es un fracaso, pero significa que la siguiente mejora está en el proceso de revisión, no en generar más código.
Cómo obtenerlas
La mayoría de estos números ya vive en tus herramientas. Los datos de despliegue y de lead time salen de tu pipeline de CI/CD y del historial de Git en GitHub o GitLab; los del sprint, de Jira o un gestor similar; el rendimiento web, del monitoreo de usuarios reales y de Google Search Console. Si no quieres construir tableros por tu cuenta, las plataformas de analítica de ingeniería combinan estas fuentes por ti. Cada una se enfoca en algo distinto:
| Plataforma | En qué es mejor | Úsala cuando |
|---|---|---|
| DX | Combina encuestas periódicas a los desarrolladores con datos de tus sistemas para medir la experiencia y la productividad, incluida la adopción y el impacto de las herramientas de IA | Quieres saber dónde pierden tiempo los ingenieros y si los asistentes de IA realmente ayudan, no solo lo que dice el pipeline |
| LinearB | Analítica de entrega a partir de Git y las herramientas de proyecto: métricas DORA, cycle time por etapa, tamaño de los pull requests y tiempo de revisión, además de automatizar partes del flujo de pull requests | Quieres encontrar y resolver cuellos de botella en la entrega, sobre todo en la revisión de código |
| Swarmia | Métricas DORA y de flujo, una vista de cómo se reparte el esfuerzo entre funcionalidades nuevas, mantenimiento y trabajo no planeado, y acuerdos de trabajo del equipo con recordatorios en Slack | Quieres una vista del flujo y el foco a nivel de equipo, y ayuda para sostener los hábitos acordados |
Elijas la que elijas, empieza por la pregunta que quieres responder, acuerda con el equipo qué se va a medir y por qué, y despliégala primero a nivel de equipo. Las opciones gratuitas también llegan lejos: los insights de GitHub y GitLab, y los reportes de cycle time y de control de Jira. Los asistentes de IA también sirven aquí: dale a uno una exportación de tus tickets o pull requests, pídele que encuentre dónde se va el tiempo y después verifica el patrón tú mismo.
Cómo las uso
- Un número que se mueve en la dirección equivocada abre una conversación con los ingenieros involucrados. Los datos muestran dónde; ellos explican por qué.
- Miro tendencias a lo largo de sprints y versiones, no valores aislados.
- Las métricas describen el sistema, nunca el desempeño individual. En el momento en que la gente se siente juzgada por un número, empieza a optimizar el número.
Cuando un número de entrega se mueve en la dirección equivocada, así encuentro la causa: Encontrar cuellos de botella en la entrega con lead time y cycle time.
Recibe mis próximos casos y artículos en la Búsqueda de Google.