5 métricas que todo CTO en Perú debería medir

Tu board te pregunta: "¿Cuándo sale la siguiente versión?" Y tú respondes con una fecha que sabes que probablemente no vas a cumplir. Pasa en el 80% de las empresas tech en Perú. Y pasa porque estás midiendo las cosas equivocadas.

Story points, velocidad, horas estimadas — todo eso te dice cuánto esfuerzo planeas. Ninguna te dice cuánto realmente terminas. Aquí van las 5 métricas que sí importan.

1. Cycle Time

¿Qué mide?

El tiempo desde que alguien empieza a trabajar en una tarea hasta que está en producción. Incluye desarrollo, code review, testing y deploy.

¿Por qué importa?

Es el predictor más fuerte de si vas a cumplir una fecha. Si tu cycle time promedio es 15 días y te quedan 10 días de sprint, ya sabes que cualquier tarea nueva que empieces no va a llegar.

Benchmark

Equipos de alto rendimiento: 2-5 días. Promedio: 7-14 días. Si estás arriba de 14 días, hay problemas sistémicos.

2. Throughput

¿Qué mide?

Cantidad de tareas completadas por unidad de tiempo (generalmente por semana). No story points — tareas terminadas y en producción.

¿Por qué importa?

Throughput estable = equipo predecible. Si una semana completas 8 tareas y la siguiente 2, tienes un problema de variabilidad que hace imposible planificar.

Cómo usarlo

Grafica throughput semanal por 6-8 semanas. Si la variación es mayor al 30%, busca la causa: ¿interrupciones? ¿dependencias externas? ¿cambios de prioridad?

3. Work In Progress (WIP)

¿Qué mide?

Cantidad de tareas que están "en progreso" en cualquier momento. Incluye todo lo que se empezó y no se terminó.

¿Por qué importa?

Ley de Little: Cycle Time = WIP ÷ Throughput. Si quieres reducir cycle time, la forma más directa es reducir WIP. No necesitas que la gente trabaje más rápido — necesitas que trabaje en menos cosas a la vez.

Benchmark

Máximo 2 tareas por developer. Si tu equipo de 8 tiene 30+ tareas en progreso, nadie está terminando nada.

4. Tasa de Cumplimiento de Sprint

¿Qué mide?

Porcentaje de lo que se comprometió al inicio del sprint que realmente se entregó al final.

¿Por qué importa?

Es la métrica que le puedes mostrar a tu CEO para demostrar confiabilidad. "Cumplimos el 90% de lo que prometimos este sprint" es una frase que genera confianza.

Benchmark

Objetivo: 85%+. Si estás abajo de 60%, no estás planificando — estás adivinando.

5. Lead Time para Cambios

¿Qué mide?

Tiempo total desde que se pide una feature hasta que está en manos del usuario. Incluye el tiempo en backlog, no solo el desarrollo.

¿Por qué importa?

Es la métrica que más le importa al negocio. No les importa cuándo empezaste a codear — les importa cuándo pueden usarlo. Si tu lead time es 3 meses, da igual que tu cycle time sea 5 días.

Cómo reducirlo

Backlog más pequeño y priorizado. Si tienes 200 tickets en el backlog, 180 nunca se van a hacer. Mejor tener 20 bien priorizados que 200 acumulando polvo.

Por dónde empezar

No necesitas medir las 5 desde el día uno. Empieza con cycle time y WIP. Son las más fáciles de obtener (tu Jira o GitHub ya tienen la data) y las que más impacto tienen cuando actúas sobre ellas.

En 2 semanas vas a tener un panorama claro de dónde se pierde tiempo. Y con esos datos, las decisiones se toman solas.

¿Quieres saber cómo están tus métricas hoy? Agenda un diagnóstico gratuito y te mostramos tus números en 30 minutos.