Medición de ROI

Módulo 8 · Metodología de entrega · Lección 3 de 7

Al terminar esta lección podrás capturar las líneas base correctas antes del Día 1, dar seguimiento a la productividad en cuatro categorías de métricas y construir una historia de ROI que se sostenga en un readout (informe de resultados) ante el CIO.

Lo que no mides antes del Día 1 no puedes demostrarlo al Día 30.

El periodo de medición

La captura de la línea base es el momento de recopilación de datos más importante del engagement

La historia de ROI se escribe antes del Día 1. Si no tienes una línea base, tienes una anécdota.

El modo de fallo habitual es empezar el piloto primero e intentar reconstruir la línea base a partir de la memoria o de estimaciones después del hecho. Esa reconstrucción siempre se impugna: los patrocinadores recuerdan el pasado como mejor o peor según quieran que el piloto tenga éxito. Una línea base capturada es un dato objetivo; una línea base estimada es una negociación.

Para la mayoría de los engagements de Claude Code bastan dos o tres puntos de datos: el tiempo de ciclo de PR desde el ticket hasta el merge para el caso de uso objetivo, las horas autorreportadas en la categoría de tarea específica y una puntuación de NPS o satisfacción de los desarrolladores. Las dos primeras son objetivas; la tercera es orientativa. Captura las tres antes del inicio.

Regla de medición. Una línea base capturada después de que empieza el piloto ya está contaminada. La recopilación de datos es trabajo previo, no posterior.

Marco de métricas

Cuatro categorías de métricas de productividad y cómo recopilarlas

Estas cuatro categorías provienen del playbook de habilitación de Claude Code. Úsalas para estructurar tanto la línea base como el scorecard del Día 30.

Categoría	Métricas	Cómo se captura	Qué indica
01 · Productividad del desarrollador	Tiempo de desarrollo de nuevas funcionalidades, velocidad de prototipado y tasa de aceptación del código sugerido	Analítica de PR, JIRA o datos de sprint	La historia central de productividad
02 · Calidad del código	Tasa de éxito en la primera revisión, velocidad de corrección de fallos de seguridad y cambios en la cobertura de código	Datos de revisión de PR y herramientas de análisis estático	Indica si la velocidad llegó con un costo en calidad
03 · Uso y adopción	Usuarios activos diarios y semanales, porcentaje que usa Claude Code tras 30 días y horas dentro de la herramienta	Analítica de uso de Claude	Muestra si la adopción es real o solo nominal
04 · Sentimiento y cultura	NPS de desarrolladores, retroalimentación cualitativa e interés de otros equipos	Encuestas breves (3–5 preguntas)	Indicador anticipado para decisiones de expansión

flowchart LR
    A["Línea base antes del Día 1"] --> B["Medición durante el piloto en cuatro categorías"]
    B --> C["Métrica titular: antes y después"]
    C --> D["Traducción a lenguaje de negocio"]
    D --> E["Scorecard del Día 30"]

Cerrar el ciclo

Un número titular. Una implicación de negocio.

El readout del Día 30 tiene un único propósito: darle al patrocinador un número que pueda repetir en su próxima reunión de liderazgo.

1. Fija la métrica titular. Elige, de las cuatro categorías, la métrica que refleje con más fidelidad el caso de uso del piloto. Para un piloto de migración es el tiempo de ciclo de PR; para una construcción de funcionalidades, el tiempo que va de la especificación al código funcionando. Preséntala como una comparación de antes y después.
2. Añade una traducción de negocio. Convierte la métrica a lenguaje de negocio. “El tiempo de ciclo de PR bajó un 34 %” se convierte en “el equipo de ingeniería puede entregar el equivalente a 1,4 veces las funcionalidades en el mismo sprint”. La traducción es lo que cita el CIO.
3. Construye el scorecard del Día 30. Una sola página con: un párrafo con la historia del caso de uso, la métrica titular con antes y después, métricas de apoyo de las otras tres categorías, anécdotas de champions y un objetivo propuesto para el Día 60. Este es el deck de Activation Summary.

Comprueba tu comprensión

Escenario: la revisión de ROI de Voxfield

Voxfield es un piloto de 30 días en una empresa SaaS empresarial. El caso de uso: la velocidad de desarrollo de nuevas funcionalidades. Día 28. Los datos ya están listos. Tres decisiones, hasta 6 puntos. Cada opción vale 2 puntos (mejor), 1 (parcial) o 0 (incorrecta).

Decisión 1 · Métrica titular

Los datos muestran: el tiempo de ciclo de PR bajó de 8,2 días a 5,4 días (34 % de mejora). La satisfacción de los desarrolladores pasó de 6,2 a 7,8 sobre 10. Las líneas de código producidas por desarrollador y por semana aumentaron un 55 %.

¿Qué métrica encabeza el readout del Día 30? Elige una opción.

• A. Tiempo de ciclo de PR: 34 % de mejora, de 8,2 a 5,4 días
• B. Satisfacción de los desarrolladores: de 6,2 a 7,8
• C. Líneas de código: aumento del 55 %

Ver respuesta

Opción correcta: A (2 puntos). Opción parcial: B (1 punto). Opción incorrecta: C (0 puntos).

• A. Tiempo de ciclo de PR: 34 % de mejora (2 puntos, mejor opción): objetiva, auditable y directamente vinculada al caso de uso. El CIO puede verificarla con las herramientas existentes. Retroalimentación: +2. El tiempo de ciclo de PR es el titular correcto. Es objetivo, está directamente vinculado al caso de uso y existe en las herramientas actuales. El CIO puede verificarlo de forma independiente.
• B. Satisfacción de los desarrolladores: de 6,2 a 7,8 (1 punto, parcial): señal real, pero blanda. Úsala como evidencia de apoyo, no como titular. Retroalimentación: +1. Las puntuaciones de satisfacción son evidencia de apoyo, no un caso de negocio. Úsalas en el readout, pero ancla la presentación en la métrica objetiva.
• C. Líneas de código: aumento del 55 % (0 puntos): engañosa. Más código más rápido no significa entregar funcionalidades más rápido. El tiempo de ciclo de PR cuenta la historia real. Retroalimentación: +0. Las líneas de código son una métrica de vanidad que Claude infla de forma natural. Abrir con ella invita a preguntas sobre la calidad que socavan el resto de los datos.

Decisión 2 · Traducción de negocio

El titular es “el tiempo de ciclo de PR bajó un 34 %”. Ahora tradúcelo a lenguaje de negocio para el readout ante el CIO.

¿Qué traducción es la más defendible? Elige una opción.

• A. Los desarrolladores son un 34 % más productivos
• B. Claude Code está transformando nuestra cultura de ingeniería
• C. El equipo entrega funcionalidades en 5,4 días que antes tomaban 8,2, lo que equivale a acelerar la hoja de ruta en aproximadamente un 35 % para este caso de uso

Ver respuesta

Opción correcta: C (2 puntos). Opción parcial: A (1 punto). Opción incorrecta: B (0 puntos).

• A. Los desarrolladores son un 34 % más productivos (1 punto, parcial): exageración. El tiempo de ciclo de PR es una señal de productividad, no la productividad total del desarrollador. Retroalimentación: +1. “Un 34 % más productivos” es una exageración frecuente. El tiempo de ciclo de PR es una señal de productividad. Una traducción más cuidadosa protege tu credibilidad si otras métricas se mantienen planas.
• B. Claude Code está transformando nuestra cultura de ingeniería (0 puntos): afirmación no verificable. Pertenece a un comunicado de prensa, no a un caso de negocio. Retroalimentación: +0. El lenguaje de transformación sin datos que lo respalden es la forma más rápida de perder la confianza del patrocinador. Mantén el lenguaje preciso y las afirmaciones acotadas.
• C. De 8,2 a 5,4 días, equivalente a acelerar la hoja de ruta en un 35 % (2 puntos, mejor opción): precisa, acotada al caso de uso y traducible directamente a velocidad de la hoja de ruta. Retroalimentación: +2. Preciso y acotado. Esta traducción vincula la métrica directamente con resultados de negocio (velocidad de la hoja de ruta) y está matizada de forma adecuada (“para este caso de uso”). Un CIO puede citarla en su próxima reunión de liderazgo.

Decisión 3 · Recomendación de expansión

Los datos del piloto son sólidos. El CTO pide tu recomendación para los próximos 30 días.

¿Cuál es la recomendación de expansión adecuada? Elige una opción.

• A. Extender el mismo caso de uso a 20 desarrolladores, más un nuevo caso de uso con su propia línea base
• B. Desplegar Claude Code a los 60 desarrolladores de inmediato
• C. Hacer otro piloto de 30 días con los mismos 8 desarrolladores antes de expandir

Ver respuesta

Opción correcta: A (2 puntos). Opción parcial: B (1 punto). Opción incorrecta: C (0 puntos).

• A. Expansión controlada con un nuevo caso de uso (2 puntos, mejor opción): la historia de ROI existente sigue acumulando evidencia mientras la Fase 2 genera datos nuevos. Retroalimentación: +2. La expansión controlada con una línea base para el nuevo caso de uso es el movimiento correcto. La historia de ROI original sigue acumulando evidencia mientras la Fase 2 arranca limpia. Así es como se ve un programa con confianza.
• B. Desplegar a los 60 desarrolladores de inmediato (1 punto, parcial): captura el impulso, pero pierde la estructura de medición limpia. Los datos de uso serán amplios pero superficiales. Retroalimentación: +1. El despliegue completo es tentador cuando el impulso es alto, pero cambia calidad de medición por amplitud. Considera si el CTO necesita un caso de negocio para el despliegue más amplio antes del próximo ciclo presupuestario.
• C. Otro piloto de 30 días con los mismos 8 desarrolladores (0 puntos): innecesario. Los datos son suficientes, y retrasar supone perder el impulso del patrocinador. Retroalimentación: +0. Un segundo piloto idéntico desperdicia el impulso y señala incertidumbre sobre el primer conjunto de datos. Los datos son sólidos. Pasa a la expansión.

Ver cierre del escenario

5–6 puntos · Veredicto: Listo para el readout. Abriste con datos objetivos, los tradujiste con precisión y diseñaste una expansión controlada. Ese es un readout del Día 30 que impulsa la renovación.

3–4 puntos · Veredicto: Lectura sólida. Tienes bien las intuiciones, pero falta algo de precisión. Vuelve a leer la sección de traducción de negocio: la diferencia entre una métrica y una afirmación de negocio es lo que te lleva al Día 60.

0–2 puntos · Veredicto: Revisa los fundamentos de medición. La captura de la línea base y la traducción de ROI son los entregables centrales de la línea de medición. Estas decisiones determinan si el readout del Día 30 impulsa la expansión o queda archivado.

Artefacto del curso: Delivery Plan Pack

Al terminar el curso tendrás un Delivery Plan Pack completo. Esta lección aporta la sección de scorecard de ROI.

1. Nombra la métrica titular e indica el valor de la línea base del Día 1.
2. Escribe en una frase la traducción de negocio de tu métrica titular: ¿cómo se relaciona esta métrica con la velocidad de la hoja de ruta, la capacidad de ingeniería o el costo?
3. Enumera las tres métricas de apoyo que vas a seguir de las cuatro categorías (Productividad del desarrollador, Calidad del código, Uso y adopción, Sentimiento y cultura).
4. Esboza la estructura del scorecard del Día 30: historia del caso de uso, comparación de la métrica titular, métricas de apoyo, una anécdota de champion y el objetivo del Día 60.

Ideas clave

• La línea base se captura antes del Día 1. Una línea base tomada después de que empieza el piloto ya está contaminada.
• Las cuatro categorías (productividad, calidad, uso y adopción, sentimiento) sirven tanto para la línea base como para el scorecard.
• Las métricas objetivas (tiempo de ciclo de PR, sistemas de tickets, analítica de uso) pesan más que las autorreportadas o las encuestas.
• Un aumento en las líneas de código no demuestra una entrega más rápida; la métrica que cuenta la historia real es el tiempo de ciclo de PR.
• El readout del Día 30 necesita un titular y una traducción de negocio: un número que el patrocinador pueda repetir en su próxima reunión de liderazgo.

Siguiente: Despliegue por fases y gestión del cambio