Despliegue por fases y gestión del cambio

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

Al terminar esta lección podrás leer la curva de adopción, reconocer las dos dinámicas propias de los despliegues de herramientas de IA y decidir cuándo intervenir y cuándo dejar que el proceso avance.

La adopción es una curva. Todo piloto la sigue.

La progresión

De supervisado a agéntico: una progresión predecible

Cada adopción de Claude Code sigue una curva de tres fases. Las fases no varían mucho de un cliente a otro; la duración y la profundidad de cada una sí varían mucho.

1. Semana 1: uso supervisado. Los desarrolladores ejecutan Claude con aprobación manual para cada acción. Están construyendo confianza en el resultado y calibrando su estilo de prompts. La velocidad suele ser más lenta que sin Claude. Es lo esperado. No intervengas en la velocidad durante la Semana 1.
2. Semanas 2–3: autonomía creciente. Los desarrolladores empiezan a aprobar más acciones por adelantado y a ejecutar Claude en fragmentos de trabajo más grandes. Aumenta el uso del modo plan. Algunos empiezan a explorar el modo auto-accept en tareas de bajo riesgo. Aquí es donde la calidad del CLAUDE.md empieza a importar.
3. Semanas 3–4: modo agéntico para clases de tarea definidas. Los desarrolladores identifican tipos de tarea específicos en los que el resultado de Claude es fiable y se los delegan con mínima supervisión. La mejora del tiempo de ciclo de PR se hace visible aquí.
4. Día 30 en adelante: patrón institucionalizado. El uso es rutinario, no experimental. El equipo ha desarrollado normas informales sobre qué delegar, cómo supervisar y cómo preparar el contexto de Claude para nuevos tipos de tarea. Es el estado objetivo, y no puede forzarse antes.

stateDiagram-v2
    [*] --> Supervisado
    state "Semana 1: uso supervisado" as Supervisado
    state "Semanas 2–3: autonomía creciente" as Autonomia
    state "Semanas 3–4: modo agéntico para clases de tarea definidas" as Agentico
    state "Día 30 en adelante: patrón institucionalizado" as Institucionalizado
    Supervisado --> Autonomia
    Autonomia --> Agentico
    Agentico --> Institucionalizado

Lo que es diferente en la adopción de IA

Dos dinámicas que no aparecen en los despliegues de herramientas ordinarias

Si tratas Claude Code como un despliegue de SaaS, vas a leer mal los datos tempranos e intervendrás en los momentos equivocados.

La caída de la semana 1: la velocidad baja antes de acelerar. Los desarrolladores están aprendiendo un nuevo modelo de interacción, no solo una herramienta nueva. El ciclo de prompts, las decisiones de supervisión y el criterio sobre qué delegar necesitan tiempo para calibrarse. El uso parecerá bajo y el resultado parecerá inconsistente. No es una señal para intervenir con formación. Es una señal de que la calibración está ocurriendo.

El efecto meseta: el uso se estabiliza en niveles subóptimos sin un catalizador. Tras la caída de la semana 1, muchos desarrolladores encuentran un nivel de uso cómodo y dejan de experimentar. Han aprendido uno o dos patrones de delegación que funcionan y se quedan con ellos. Sin intervención activa del champion o sin una sesión estructurada de las semanas 2/3 (Code 201, profundidad de observabilidad), la meseta puede parecer adopción, pero el techo es mucho más bajo de lo que debería ser. Aquí es donde importa habilitar al champion.

Cuándo intervenir

Un desarrollador está atascado. La pregunta es si ayudar ahora o esperar.

La intervención equivocada en el momento equivocado hace retroceder la adopción. Hay una prueba sencilla: determinar si el desarrollador está atascado en un problema de Claude Code o en un problema de diseño del flujo de trabajo.

• Si no logra que Claude haga lo que quiere (resultados alucinados, fallos de prompts, problemas de contexto), es un bloqueo técnico: hay que ayudar ahora.
• Si hace las mismas tareas de siempre y Claude es solo un autocompletado más rápido, es un problema de diseño del flujo de trabajo: hay que replantear el patrón de delegación, no la técnica de prompting.

flowchart TD
    A["Desarrollador atascado"] --> B{"¿Qué tipo de bloqueo es?"}
    B -->|"Problema de Claude Code: alucinaciones, fallos de prompts o contexto"| C["Intervención técnica: ayudar ahora"]
    B -->|"Problema de flujo: mismas tareas de siempre, Claude como autocompletado"| D["Replantear el patrón de delegación"]

Qué hacer en cada semana:

• Intervenciones de la Semana 1: calibración técnica, configuración del CLAUDE.md y primer commit del CLAUDE.md. No presiones por la velocidad.
• Intervenciones de la Semana 2: revisión del patrón de delegación, fomento del modo plan y sesión Code 201. Vigila la meseta.
• Intervenciones de la Semana 3: modo auto-accept para clases de tarea definidas, configuración de hooks y estructuración de tareas agénticas. Busca los equipos cuyo uso sigue creciendo frente a los que se estancaron.
• Semana 4: documenta los patrones de uso. ¿Qué funcionó? ¿Qué se rompió? ¿Qué debería decir el CLAUDE.md del equipo que todavía no dice?

Regla de adopción. Un desarrollador que ha dejado de experimentar no es una historia de éxito. La meseta no es adopción.

Comprueba tu comprensión

Escenario: Helios Software, Día 16

Helios Software. Día 16 de un piloto de 30 días. 10 desarrolladores. Caso de uso: migración de Java a Kotlin. Los datos empiezan a llegar. Tres decisiones, hasta 6 puntos. Cada opción vale 2 puntos (mejor), 1 (parcial) o 0 (incorrecta).

Decisión 1 · Lectura de los datos

El tiempo de ciclo de PR está plano frente a la línea base. Los datos de uso muestran que los desarrolladores promedian 45 minutos al día en Claude Code. Los patrones de prompts no han cambiado desde la Semana 1.

¿Qué te dice esto? Elige una opción.

• A. La adopción está fallando: Claude no ayuda con las tareas de migración
• B. El equipo está en meseta y necesita una sesión Code 201 para avanzar en los patrones de delegación
• C. Es demasiado pronto para sacar conclusiones

Ver respuesta

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

• A. La adopción está fallando (0 puntos): los datos de uso contradicen esto. 45 minutos diarios son un uso real. El patrón no ha evolucionado; no se ha colapsado. Retroalimentación: +0. 45 minutos de uso diario indican que la herramienta forma parte de su flujo de trabajo. El problema es el techo, no el suelo. Lee el patrón, no solo el número principal.
• B. Meseta y sesión Code 201 (2 puntos, mejor opción): un tiempo de ciclo de PR plano con uso constante es la firma de la meseta. La herramienta forma parte del flujo de trabajo, pero el techo no se ha elevado. Retroalimentación: +2. Meseta es la lectura correcta. El uso es real, pero el techo de la delegación no ha subido desde la Semana 1. El Día 16 es exactamente el momento de intervenir antes de que se cierre la ventana de medición.
• C. Es demasiado pronto (1 punto, parcial): el Día 16 no es demasiado pronto. Es justo cuando la meseta se vuelve visible. Esperar al Día 25 deja tiempo insuficiente para intervenir. Retroalimentación: +1. El Día 16 no es demasiado pronto. Tienes dos semanas de datos que muestran un patrón consistente. Esperar hasta el Día 25 te deja cinco días para cambiar una trayectoria de 30 días.

Decisión 2 · Elección de la intervención

Has identificado una meseta. ¿Qué intervención rompe mejor la meseta en el Día 16? Elige una opción.

• A. Programar una sesión Code 201 centrada en el modo plan y el auto-accept para subtareas de migración de bajo riesgo
• B. Compartir ejemplos de lo que están logrando otros equipos con Claude Code
• C. Aumentar la frecuencia de los seguimientos a una reunión diaria

Ver respuesta

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

• A. Sesión Code 201 sobre modo plan y auto-accept (2 puntos, mejor opción): aborda directamente el techo de la delegación. Los desarrolladores aprenden a estructurar las tareas para una ejecución con mayor autonomía. Retroalimentación: +2. Code 201 aborda directamente el techo de la delegación. El modo plan y el auto-accept para clases de tarea definidas son las habilidades concretas que rompen la meseta del uso supervisado.
• B. Compartir ejemplos de otros equipos (1 punto, parcial): contexto útil, pero no cambia el patrón de delegación. Úsalo como encuadre motivacional junto con la sesión Code 201. Retroalimentación: +1. Los ejemplos externos son una motivación útil, pero no cambian el diseño del flujo de trabajo. Úsalos como contexto al inicio de una sesión Code 201, no como intervención independiente.
• C. Aumentar la frecuencia de los seguimientos a una reunión diaria (0 puntos): la monitorización no cambia el comportamiento. La meseta es un problema de diseño del flujo de trabajo, no de visibilidad. Retroalimentación: +0. Más monitorización produce más datos sobre la meseta, pero no la disuelve. El problema es el diseño del flujo de trabajo, y la solución es una sesión de habilidades bien dirigida.

Decisión 3 · Activación del champion

Después de la sesión Code 201, una desarrolladora (Priya) ha avanzado con rapidez. Su tiempo de ciclo de PR ha bajado un 40 % frente a la línea base. El resto del equipo sigue en meseta.

¿Cómo aprovechas el progreso de Priya? Elige una opción.

• A. Pedir a Priya una demostración de 30 minutos con su configuración de CLAUDE.md, sus patrones de delegación y dos ejemplos de PR de antes y después
• B. Incluir a Priya en tu informe semanal para el CTO
• C. Pedirle a Priya que haga de mentora de cada desarrollador de forma individual

Ver respuesta

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

• A. Demostración de 30 minutos de Priya (2 puntos, mejor opción): la demostración entre pares es la palanca de adopción más eficaz. Es concreta, creíble y replicable por los compañeros. Retroalimentación: +2. La demostración entre pares es la intervención de adopción con mayor palanca disponible. El CLAUDE.md y los patrones de delegación de Priya son lo que el equipo necesita ver: no un caso de éxito, sino un método replicable.
• B. Incluirla en el informe semanal para el CTO (1 punto, parcial): buena para la gestión de stakeholders, pero no cambia los patrones de uso del equipo. Úsala junto con la demostración entre pares, no en lugar de ella. Retroalimentación: +1. La visibilidad ante el CTO es importante para la gestión del engagement, pero no cambia cómo trabajan los otros nueve desarrolladores. Ambas acciones son útiles; la demostración entre pares debe ir primero.
• C. Mentoría individual para cada desarrollador (0 puntos): escala mal. El tiempo de Priya rinde más en una sola demostración grupal que en diez sesiones uno a uno. Retroalimentación: +0. La mentoría individual no escala y aparta a Priya de su propio trabajo. Una única demostración grupal bien estructurada es más eficiente y más efectiva.

Ver cierre del escenario

5–6 puntos · Veredicto: Listo para la adopción. Leíste bien los datos, elegiste la intervención correcta y activaste al champion en el momento adecuado. Ese es un piloto que alcanza su techo antes del Día 30.

3–4 puntos · Veredicto: Dirección correcta. Identificaste la meseta, pero el momento o el mecanismo de la intervención necesitan afinarse. Vuelve a leer la sección de las dos dinámicas: la meseta es el escenario más común entre los días 15 y 20, y la respuesta debe ser rápida y específica.

0–2 puntos · Veredicto: Revisa las dinámicas de adopción. El efecto meseta no es un fracaso, sino una etapa predecible. Aprender a leerla y responder a ella es lo que separa a un consultor de un gestor de proyectos.

Ideas clave

• La adopción es un problema de diseño, no de entusiasmo. La curva de tres fases ofrece el lenguaje para describir lo que ocurre y el mapa de intervenciones para responder.
• La caída de la semana 1 es calibración, no fracaso: no intervengas con formación por la velocidad en esa semana.
• La meseta es predecible y se puede abordar. Sin un catalizador, el uso se estabiliza por debajo de su potencial.
• Antes de intervenir, distingue entre un problema de Claude Code (ayuda técnica inmediata) y un problema de diseño del flujo de trabajo (replantear la delegación).
• Un desarrollador que dejó de experimentar no es un éxito. La meta es el patrón institucionalizado, que no puede forzarse antes del Día 30.

Siguiente: Habilitación de champions y documentación interna