Cómo armar un sistema de métricas para ingeniería que le importe al negocio (Parte 2/3)

4 minute read

Cómo armar un sistema de métricas para ingeniería que le importe al negocio

Este es el segundo de tres posts basados en un trabajo de consultoría que hice para una fintech de pagos en LATAM. Los nombres, datos y detalles fueron modificados. En el post anterior hice el diagnóstico organizacional. Aquí va lo que sigue: cómo armar el sistema de métricas que sostiene ese diagnóstico en el tiempo.

Un diagnóstico es una foto. Las métricas son el video. Sin un sistema que mida de forma continua, el diagnóstico se vuelve obsoleto en semanas.

Términos clave:

  • Velocity: story points completados por sprint
  • Sprint Completion Rate: porcentaje de tickets comprometidos que se completaron
  • Carry-over rate: porcentaje de tickets que pasan al siguiente sprint sin completarse
  • Deployment Frequency: cantidad de deploys por semana por servicio
  • Lead Time: tiempo desde el commit hasta producción

KPIs semanales y fórmulas

Velocidad

  • Cycle Time P50/P75 = percentil de (fecha done - fecha inicio) por squad
  • Velocity = story points completados por sprint
  • Sprint Completion Rate = tickets completados / tickets comprometidos × 100
  • Carry-over rate = tickets que pasan al siguiente sprint / total comprometidos × 100

Calidad

  • CFR = deploys con incidente / total deploys × 100
  • MTTR = promedio (incidente resuelto - incidente detectado) en horas

Flujo

  • Flow Efficiency = tiempo activo / (tiempo activo + tiempo de espera) × 100
    • Tiempo activo = tiempo en estado “In Progress” o “Coding”
    • Tiempo de espera = tiempo en estados “Blocked”, “In Review”, “Waiting for deploy”
  • Deployment Frequency = deploys / semana / servicio

Composición del sprint

  • % Bugs = tickets de bugs / total tickets × 100
  • % Features = tickets de features / total tickets × 100
  • % Deuda técnica = tickets de correcciones / total tickets × 100
  • % Interrupciones = tickets que entraron después de iniciar el sprint / total tickets × 100
  • Tickets en progreso = tickets iniciados no terminados
  • Tickets bloqueados = tickets con impedimento activo

Negocio

  • Revenue at Risk por squad = suma de (Deploys × CFR) × (GMV/semana) × Severidad × (MTTR/168)
  • Engineering Leverage = revenue generado / costo de ingeniería
  • Tasa de aceptación = transacciones aceptadas / total × 100

Salud técnica

  • Uptime / Disponibilidad = porcentaje de tiempo que el servicio está operativo
  • Latencia de APIs = tiempo de respuesta promedio (P50/P95)
  • Tasa de error en transacciones = transacciones fallidas / total × 100

Alertas para el CTO

No todas las métricas necesitan atención inmediata. La clave es definir umbrales claros para que el CTO sepa cuándo actuar y cuándo solo observar.

Rojas (acción inmediata)

  • CFR > 15%
  • MTTR > 4 horas
  • Sprint Completion Rate < 50%
  • % Interrupciones > 30%

Amarillas (review semanal)

  • Cycle Time P75 > 12 días
  • Flow Efficiency < 25%
  • Engineering Leverage < 1.5x
  • Deployment Frequency < 1/semana
  • % Bugs > 25%

Conexión entre métricas de ingeniería y resultados de negocio

Esta es la tabla que todo líder de ingeniería debería poder presentarle a su CTO. Si no puedes explicar cómo lo que mides en ingeniería afecta al negocio, las métricas no van a generar tracción.

Métrica de ingeniería Impacto en el negocio
CFR + MTTR Revenue at Risk
Cycle Time Tiempo al mercado, cumplimiento de acuerdos con clientes
Deployment Frequency Velocidad de entrega de features
Flow Efficiency Tiempo productivo vs tiempo perdido
Sprint Completion Predictibilidad de entregas
Engineering Leverage ROI del equipo
Uptime / Disponibilidad Transacciones perdidas
Latencia de APIs Experiencia del cliente, abandono
Tasa de error Transacciones fallidas
Tasa de aceptación Lógica de negocio funcionando correctamente

Estructura del dashboard

Cada audiencia necesita ver cosas distintas. Un dashboard que le sirve al EM no le sirve al CTO, y viceversa.

Vista Ejecutiva (CTO — semanal)

  • Revenue por squad
  • Revenue at Risk por squad
  • Engineering Leverage
  • Alertas rojas y amarillas activas

Vista de Squad (EM — diario)

  • Tendencia de cycle time
  • Flow efficiency
  • Sprint Completion Rate
  • Composición del sprint (features vs bugs vs deuda vs interrupciones)

Vista de Servicio (EM — diario)

  • Deployment Frequency
  • Lead Time
  • CFR
  • MTTR

Vista de Producto (PM — diario)

Estas métricas vienen del equipo de producto, no del diagnóstico de ingeniería. Pero son las que completan la historia.

  • Transacciones procesadas
  • Transacciones aceptadas vs rechazadas
  • Tasa de conversión
  • GMV procesado

Ownership

  • El EM actualiza métricas de squad y servicio semanalmente
  • El CTO revisa la vista ejecutiva en la reunión semanal

Implementación pragmática

No empieces con tooling sofisticado. La tentación de armar un dashboard bonito desde el día uno es grande, pero lo importante es validar que las métricas que elegiste realmente cuentan la historia correcta.

  • Semana 1-2: Spreadsheet manual para validar que las métricas tienen sentido y que los datos son accesibles
  • Semana 3-4: Script que hace pull de las APIs (Jira/Linear, GitHub, PagerDuty) a Google Sheets
  • Mes 2+: Dashboard en Metabase o Looker si el volumen lo justifica

Fuentes de datos

  • Jira/Linear — cycle time, velocity, sprint completion, composición del sprint
  • GitHub — deployment frequency, lead time, PRs
  • PagerDuty/Datadog — CFR, MTTR, incidentes, uptime, latencia
  • Tracking manual — flow efficiency (hasta tener tooling que lo automatice)
  • Base de datos / Analytics — transacciones, GMV, conversión, tasas de error y aceptación

Este es un primer approach con contexto reducido. Al entrar en la organización y estudiar de cerca los equipos y los datos reales, puedes ajustar qué métricas priorizar y cómo presentarlas. Pero como punto de partida, este sistema ya te da visibilidad.

Las métricas no son el objetivo — son la herramienta para tener mejores conversaciones. Cuando el CTO puede ver en un vistazo qué squads están en riesgo y por qué, las decisiones se toman más rápido y con mejor información.

En el próximo post: el plan de ejecución a 90 días que pone todo esto en marcha.

Si quieres profundizar en las métricas que usé como referencia, revisa el framework DORA.

You May Also Enjoy