Delivery Methodology — Resumen de estudio

Paths: Architect · FDE · 7 lecciones interactivas con simulaciones

Cómo llevar una activación de Claude Code de 30 días de principio a fin: calificar el caso de uso → diseñar el piloto → medir el ROI → gestionar la adopción → habilitar al champion → prevenir fallos → el arco de 30 días. Entregable: el Delivery Plan Pack.

1. Identificar y calificar el caso de uso

• Ganancia marginal: hace lo mismo más rápido (autocompletado, boilerplate). Es real pero difusa y difícil de aislar en 30 días. Sirve para generar impulso, no sostiene un caso de negocio ante el CIO.
• Ganancia estructural: cambia la unidad de trabajo (de 4 personas y 6 semanas a 2 y 2). Es medible antes del Día 30 y sostiene la conversación de renovación.
• Dos modos de activación:
  • Modo 1: 2 días de capacitación. Da señales de adopción, no datos de ROI.
  • Modo 2: programa de 30–45 días con pre-kickoff, definición del caso de uso, punto medio en el Día 20–25 y cierre presentado por el champion. Da datos de ROI porque la medición existe desde antes del Día 1.
• Tres patrones que suelen dar ganancia estructural:
  • Modernización de código (proporción de commits asistidos por Claude).
  • Desarrollo de features nuevas (tiempo de ciclo de PR).
  • Migraciones (de framework, nube o arquitectura; la velocidad se nota en dos semanas).
• 4 criterios de calificación:
  • Volumen: se repite lo suficiente en 30 días.
  • Complejidad: Claude aporta palanca real, no solo velocidad.
  • Medibilidad: hay baseline antes del Día 1; no es negociable.
  • Disposición del equipo: está dispuesto a cambiar su flujo de trabajo.
• "Un caso que pasa en complejidad pero falla en medibilidad no es un candidato a piloto: es un riesgo."
• Simulación Arvana:
  1. B: la migración de Java a Spring Boot (la de tests sobre 82% de cobertura es marginal; mezclar ambas diluye la señal).
  2. A: tiempo de ciclo de PR de ticket a merge.
  3. A: 8–10 desarrolladores dueños del backlog de la migración.

2. Diseño del piloto

• Cohorte: los dueños del caso de uso, no los voluntarios entusiastas (su entusiasmo no se extrapola al resto).
• Alcance: preciso ("migración del módulo de auth a Spring Boot", no "modernización").
• Duración: al menos dos ciclos completos de tarea por desarrollador (25–30 días en una migración).
• Congela el alcance antes del Día 1: lo nuevo que surja va a la Fase 2.
• Criterios de éxito antes de empezar:
  • Baseline.
  • Umbral ("−25% en tiempo de ciclo de PR").
  • Método de medición (git, JIRA, analítica de PRs, mejor que auto-reportes).
  • Fecha.
• Formato: "[Métrica] mejorará en [umbral] respecto del baseline del Día 1 para [fecha]."
• Simulación Kellner:
  1. A: los 8 desarrolladores de la migración de C++ a Rust.
  2. B: tiempo de ciclo de PR con baseline del Día 1.
  3. A: la documentación se registra para la Fase 2 y se protege el alcance.

3. Medición del ROI

• El baseline es el momento de captura de datos más importante. Un baseline reconstruido después del inicio "está contaminado": un baseline estimado es una negociación.
• Toma 2–3 datos antes del kickoff: tiempo de ciclo de PR (objetivo), horas auto-reportadas en la categoría de tarea (objetivo) y NPS del desarrollador (direccional).
• 4 categorías de métricas:
  • Developer Productivity: tiempo de desarrollo de features, velocidad de prototipado, tasa de aceptación de código sugerido.
  • Code Quality: aprobación en primera revisión, velocidad de fixes de seguridad, cobertura.
  • Usage/Adoption: DAU/WAU, % que sigue usándolo a los 30 días, horas en la herramienta.
  • Sentiment: NPS, encuestas de 3–5 preguntas, interés de otros equipos.
• Readout del Día 30: una cifra principal + una traducción a negocio ("−34% en ciclo de PR" → "≈1.4× features por sprint").
  • Scorecard de una página: historia del caso de uso, métrica principal antes/después, métricas de apoyo, anécdotas del champion, meta para el Día 60.
• Simulación Voxfield:
  1. A: liderar con el tiempo de ciclo de PR (8.2 → 5.4 días, −34%). Las líneas de código son una métrica de vanidad.
  2. C: "features en 5.4 días que antes tomaban 8.2 ≈ roadmap 35% más rápido para este caso de uso" (no "34% más productivos").
  3. A: el mismo caso a 20 desarrolladores + un caso nuevo con su propio baseline.

4. Adopción por fases

• La curva:
  • Semana 1: uso supervisado (la velocidad incluso baja; no intervengas por velocidad).
  • Semanas 2–3: más autonomía (plan mode, auto-accept en tareas de bajo riesgo; aquí empieza a importar CLAUDE.md).
  • Semanas 3–4: modo agentic para clases de tarea definidas (se nota la mejora en el ciclo de PR).
  • Día 30 en adelante: patrón institucionalizado.
• Dos dinámicas propias de la IA:
  • El bache de la semana 1 es calibración, no una señal para dar más capacitación.
  • El efecto meseta: se acomodan en 1–2 patrones y dejan de experimentar. Hace falta un catalizador (sesión Code 201, champions).
• ¿Cuándo intervenir?
  • Si está atorado con Claude Code (alucinaciones, prompts, contexto) → ayuda técnica ya.
  • Si usa Claude como autocompletado rápido → es un problema de diseño del flujo (hay que repensar la delegación).
  • Por semana: S1 calibración + primer commit del CLAUDE.md · S2 revisión de delegación, plan mode, Code 201 · S3 auto-accept en clases de tareas, hooks · S4 documentar los patrones.
• "Un desarrollador que dejó de experimentar no es un caso de éxito. La meseta no es adopción."
• Simulación Helios (Día 16):
  1. B: es una meseta (45 min/día de uso con el ciclo de PR plano).
  2. A: Code 201 enfocado en plan mode y auto-accept para subtareas de bajo riesgo.
  3. A: demo de 30 min de Priya (su CLAUDE.md y PRs antes/después).

5. Champion y documentación interna

• El champion es un rol, no un título:
  • Mantiene CLAUDE.md, hace office hours o un canal del equipo, incorpora a gente nueva y escala bloqueos.
  • No es la mesa de ayuda (si es el único experto, el despliegue es frágil).
  • Necesita: CLAUDE.md poblado, un catálogo de 3–5 comandos custom y una vía de escalamiento. El traspaso se hace antes del Día 30.
  • Buen candidato: con influencia en el equipo + motivación propia (no asignado). Los mejores se postulan solos en la Fase 2.
• CLAUDE.md es memoria institucional que Claude lee en cada sesión; 30 min a la semana dan rendimientos compuestos.
• Lo que se entrega: CLAUDE.md de empresa + uno por repo del piloto + catálogo de comandos (con frontmatter, parámetros y ejemplos).
• "La calidad del despliegue 90 días después de irte la decide el CLAUDE.md que entregues."
• Verdadero o falso (las tres son falsas):
  • "El champion debe ser el más técnico" → importan más la influencia y la motivación.
  • "CLAUDE.md debe quedar final y estable" → es un documento vivo.
  • "Los comandos custom son opcionales en equipos pequeños" → son obligatorios.

6. Los 6 modos de falla (ninguno técnico)

• Cierre limpio = 4 artefactos:
  1. Delivery Plan Pack (calificación, piloto, scorecard de ROI, plan del champion).
  2. CLAUDE.md + catálogo de comandos.
  3. Readout del Día 30 (enviado 48 h antes).
  4. Champion nombrado con vía de escalamiento (y la fecha del check-in a los 30 días).
• Ejercicio de riesgos: sin baseline, sin champion y sin comandos custom. No son riesgos: 4 de 12 todavía supervisados, +20% en ciclo de PR, 3 usuarios intensivos (son candidatos a champion).

7. La activación de 30 días

1. Pre-kickoff: calificar, cohorte, baseline desde el control de versiones, borrador de CLAUDE.md. Salida: baseline + CLAUDE.md + cohorte + fecha.
2. Semana 1 (onboarding): instalación con la configuración aprobada, modo supervisado, office hours el Día 3–4. Salida: toda la cohorte activa.
3. Semanas 2–3 (piloto activo): touchpoints del CoE los días 8 y 15 (30 min, revisión de uso, una acción de coaching por cada desarrollador atorado, actualizar CLAUDE.md). Identificar al champion en la semana 3. Salida: ≥ la mitad fuera del modo supervisado.
4. Semana 4: métricas frente a criterios, readout y narrativa para el CIO, traspaso al champion. Salida: readout enviado, 4 artefactos listos.
5. Día 30 — showcase de 30 min con el sponsor presente (si no puede, se reprograma):
   • Demo en vivo (10 min) de 2–3 desarrolladores en etapas 3–4, con código real.
   • Métricas (10 min), empezando por la cifra principal y frente a los criterios acordados (si alguno no se cumplió, dilo antes de que pregunten).
   • Renovación (10 min): Fase 2, el champion, los próximos 90 días y una decisión concreta.
6. Office hours (60 min): la primera la lleva el consultor, en la segunda el champion co-facilita y en la tercera la dirige el champion. Ese es el mecanismo real de traspaso.
7. Todo en el calendario antes del kickoff.