Modos de fallo comunes y cómo anticiparlos

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

Al terminar esta lección podrás identificar los seis modos de fallo que aparecen de forma consistente en los despliegues de Claude Code, cómo se ve cada uno antes del Día 30 y la acción concreta que lo previene.

La mayoría de los despliegues no fallan por la tecnología. Fallan en el traspaso.

Qué sale mal

Seis modos de fallo. Todos son prevenibles.

Ninguno de estos fallos es técnico. Cada uno es una brecha de proceso que aparece antes del Día 30 y se agrava después de que el consultor se va.

Fallo	Qué ocurre	Prevención
1. No se capturó la línea base	El caso de ROI se derrumba en el readout del Día 30 porque no hay un estado anterior con el que comparar. El patrocinador no tiene un número defendible y la conversación de renovación no puede avanzar.	Sprint de línea base en la semana previa al inicio, innegociable.
2. Champion no identificado	La adopción cae de forma pronunciada entre 30 y 60 días después de que termina el engagement. Nadie es dueño del CLAUDE.md, los nuevos desarrolladores no se incorporan y el despliegue llega a cero en un trimestre.	Nombrar al champion antes del Día 15 e iniciar la preparación del traspaso en la Fase 2.
3. Caso de uso demasiado marginal	Las métricas se ven planas al Día 30, incluso con uso alto. El patrocinador esperaba un impacto transformacional y vio una mejora incremental. El apoyo ejecutivo se evapora y la renovación fracasa por el alcance, no por la ejecución.	Aplicar la calificación estructural frente a marginal de la Lección 1 antes de acotar el piloto.
4. Estancamiento en modo supervisado	El uso es bajo o se estanca después de la primera semana. Los desarrolladores dicen que la herramienta es “lenta” o “no es útil”. El tiempo de ciclo de PR no cambia y el readout del Día 30 no tiene una historia de productividad.	Punto de contacto semanal con el CoE (Center of Excellence) para revisar el uso, y coaching de ajuste al flujo de trabajo para los desarrolladores estancados en la Fase 2.
5. CLAUDE.md sin mantenimiento	Claude vuelve a un comportamiento genérico a medida que la base de código evoluciona más allá de lo que describe el CLAUDE.md inicial. La confianza del equipo se erosiona, los desarrolladores dejan de usar Claude para tareas complejas y la adopción regresa al modo supervisado.	Revisión semanal del CLAUDE.md como responsabilidad nombrada del champion; incluirla en el artefacto del plan del champion.
6. El readout no se vincula al resultado de negocio	El readout del Día 30 presenta métricas de uso y testimonios de desarrolladores, pero ninguna traducción a nivel de negocio. El CIO no se involucra, la conversación pasa del valor al costo y la renovación se estanca en compras.	Alinear la narrativa para el CIO con el patrocinador en la primera semana, usando el marco de la Lección 3.

Cuatro artefactos de un cierre limpio

Si falta cualquiera de estos cuatro artefactos al Día 30, la salud del despliegue a 90 días está en riesgo. La lista es corta por diseño. Cada elemento aborda al menos uno de los seis modos de fallo anteriores.

flowchart TD
    A["Revisión de cuatro artefactos al Día 30"] --> B{"¿Están los cuatro completos?"}
    B -->|"Sí"| C["Cierre limpio"]
    B -->|"No, falta alguno"| D["La salud del despliegue a 90 días está en riesgo"]

• Delivery Plan Pack (completo). Las cuatro secciones: calificación, diseño del piloto, scorecard de ROI y plan de champions. Es el documento que ancla la conversación de renovación y sirve como punto de referencia para acotar la Fase 2.
• CLAUDE.md y catálogo de comandos personalizados. Un CLAUDE.md empresarial poblado, al menos un CLAUDE.md específico del repositorio del piloto y un catálogo de comandos con un mínimo de tres a cinco comandos documentados. Son las herramientas principales que el champion necesita para mantener la calidad del despliegue sin apoyo del consultor.
• Readout del Día 30 con métricas frente a los criterios de éxito. El número titular, los datos de apoyo y la narrativa para el CIO. El readout (informe de resultados) debe estar en manos del cliente 48 horas antes del showcase (sesión del Día 30), no repartirse durante ella.
• Champion nombrado con ruta de escalamiento documentada. Una persona, una descripción de su rol y una línea directa con el consultor para los problemas que excedan el alcance del champion. Incluye la fecha de la revisión a los 30 días posteriores al engagement en la documentación de traspaso antes de irte.

Comprueba tu comprensión

Escenario: ¿qué elementos ponen en riesgo este despliegue?

Una revisión del Día 30 está a dos días de distancia en un piloto de 12 desarrolladores. Revisa el estado del engagement a continuación. Elige los 3 elementos que indican que este despliegue corre el riesgo de no renovarse.

1. Medición de ROI. No se capturó la línea base en la semana previa al inicio. La recopilación de datos previa al piloto se aplazó a la primera semana del piloto.
2. Adopción. Cuatro de 12 desarrolladores siguen en modo supervisado en el Día 28. Seguimiento en las notas de la reunión semanal del CoE.
3. Plan de champions. No hay champion identificado al Día 28. La conversación con el champion todavía no ha ocurrido.
4. Métricas de productividad. El tiempo de ciclo de PR mejoró un 20 % frente a la línea base en la cohorte de migración. Datos de GitHub, semanas 2 a 4.
5. Configuración. No se construyeron comandos personalizados durante el piloto. El CLAUDE.md existe, pero el catálogo de comandos está vacío.
6. Telemetría de uso. Los datos de uso muestran a tres desarrolladores con recuentos semanales de sesiones muy altos. Panel de telemetría de Claude Code.

Ver respuesta

Respuesta correcta: los elementos 1, 3 y 5.

Los tres riesgos son:

• Medición de ROI (etiqueta: alta): sin línea base, el caso de ROI no tiene un estado anterior al que anclarse.
• Plan de champions (etiqueta: alta): el despliegue no tiene un dueño después del Día 30.
• Configuración (etiqueta: alta): el traspaso carece de la infraestructura de configuración que el champion necesita para mantener la calidad.

Los elementos sin riesgo son variaciones normales del piloto:

• Adopción (etiqueta: baja): que algunos desarrolladores sigan en modo supervisado en el Día 28 es lo esperado y no es un riesgo de renovación.
• Métricas de productividad (etiqueta: baja): una mejora del 20 % en el tiempo de ciclo de PR es un buen resultado que debe anclar la narrativa ante el CIO.
• Telemetría de uso (etiqueta: baja): tres desarrolladores con recuentos altos son candidatos a champion, no una señal de riesgo.

Artefacto del curso · Completo: Delivery Plan Pack

Has construido el Delivery Plan Pack completo a lo largo de este curso. Sus cuatro secciones están directamente conectadas con las decisiones del engagement que sostienen:

• Sección de calificación (Lección 1): caso de uso nombrado, ganancia estructural o marginal etiquetada y cuatro criterios puntuados.
• Sección de diseño del piloto (Lección 2): cohorte, alcance, duración y dos a tres criterios de éxito medibles.
• Sección de scorecard de ROI (Lección 3): tres líneas base, métricas de telemetría y el número titular para el CIO.
• Sección de plan de champions (Lección 5): candidato a champion nombrado, tres artefactos de traspaso listados y chequeo de salud posterior al engagement definido.

Ideas clave

• Los seis modos de fallo son de proceso, no técnicos, y todos son prevenibles antes del Día 1.
• Línea base, champion, calificación estructural, revisión semanal del uso, mantenimiento del CLAUDE.md y narrativa alineada con el negocio: cada uno tiene una acción concreta de prevención.
• Un traspaso limpio con los cuatro artefactos completos separa un despliegue que se renueva de uno que se degrada.
• Si falta cualquiera de los cuatro artefactos al Día 30, la salud del despliegue a 90 días está en riesgo.
• Algunos desarrolladores en modo supervisado o recuentos altos de sesiones son variaciones normales del piloto, no riesgos de renovación por sí mismos.

Siguiente: Activación de Claude Code en 30 días