Diseño del piloto

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

Al terminar esta lección podrás diseñar un piloto que produzca una respuesta defendible al Día 30, con la cohorte adecuada, un caso de uso acotado y criterios de éxito fijados antes de que empiece el trabajo.

Un piloto que no se puede evaluar no es un piloto.

¿Quién forma parte del piloto?

La cohorte que eliges determina los datos que obtienes

La selección de la cohorte es una decisión de diseño, no de disponibilidad. El perfil de los desarrolladores del piloto determina directamente lo que el readout (informe de resultados) del Día 30 puede afirmar.

Cohorte incorrecta: participantes voluntarios. Los early adopters y los entusiastas generan datos de uso altos y retroalimentación cualitativa positiva. Pero no representan al desarrollador típico. Las métricas de engagement de este grupo no se extrapolan al resto del equipo y no resisten el escrutinio en un readout ante el CIO.

Cohorte correcta: dueños del caso de uso. Son desarrolladores que ya son responsables del trabajo que el caso de uso aborda. Tienen tickets activos, patrones familiares y una línea base de partida realista. Sus datos de antes y después son atribuibles y defendibles. La historia de métricas se escribe sola.

Alcance y duración

El alcance y la duración son decisiones de diseño, no valores por defecto

El valor por defecto de “ejecutarlo un mes y ver qué pasa” produce datos no concluyentes. Un alcance y una duración explícitos producen un argumento de cierre.

1. Define el caso de uso objetivo con precisión. No “modernización de código”, sino “migración de Java a Spring Boot del módulo de servicio de autenticación”. Cuanto más específico sea el alcance, más limpia será la atribución del ROI.
2. Elige la cohorte según la propiedad, no la disponibilidad. Los desarrolladores que trabajan activamente en el caso de uso acotado, no los que tienen más espacio libre en el calendario.
3. Define la duración según el tiempo de ciclo de las tareas. Debe ser lo bastante larga para que cada desarrollador complete al menos dos ciclos completos de tarea (de ticket a merge). Para la mayoría de los trabajos de migración, 25–30 días bastan.
4. Fija el alcance antes del Día 1. El crecimiento del alcance durante el piloto diluye la historia de ROI. Si surge un caso de uso nuevo, regístralo para la Fase 2 y protege el alcance original.

flowchart LR
    A["1. Definir el caso de uso con precisión"] --> B["2. Elegir la cohorte por propiedad"]
    B --> C["3. Fijar la duración según el ciclo de tarea"]
    C --> D["4. Bloquear el alcance antes del Día 1"]
    D --> E["Reunión de inicio (kickoff)"]

Antes del Día 1

Los criterios de éxito deben existir antes de que empiece el piloto

Si no sabes cómo es el éxito al Día 30, no puedes diseñar el piloto para demostrarlo.

1. Línea base. La métrica que intentas mover, medida antes del Día 1: tiempo de ciclo de PR, horas por tarea, velocidad de migración. Sin línea base no hay historia de antes y después.
2. Umbral objetivo. El número que constituye una victoria. “Reducción del 25 % en el tiempo de ciclo de PR” es una afirmación; “el tiempo de ciclo de PR mejoró” no lo es. Los umbrales son los que se citan en las conversaciones de renovación.
3. Método de medición. Cómo capturarás los datos. Las herramientas existentes (git, JIRA, analítica de PR) son preferibles a la autoevaluación. Los datos objetivos resisten el escrutinio.
4. Fecha objetivo. La fecha concreta en la que evaluarás. El Día 30 es un hito, no una fecha límite. Nómbrala antes de que empiece el piloto para que todos sepan qué se mide y cuándo.

Regla de diseño. Un criterio de éxito que no puedes medir antes del Día 1 es una hipótesis, no un compromiso. Fija la línea base antes de la reunión de inicio.

Comprueba tu comprensión

Escenario: el diseño del piloto de Kellner Industries

Kellner Industries tiene un equipo de ingeniería de 45 desarrolladores que construye software de infraestructura empresarial. El CTO ha aprobado un piloto de Claude Code. Tres decisiones, hasta 6 puntos. Cada opción vale 2 puntos (mejor), 1 (parcial) o 0 (incorrecta).

Decisión 1 · Selección de la cohorte

Kellner ha aprobado un piloto para su proyecto de migración de C++ a Rust. Tú seleccionas la cohorte. El equipo de migración tiene 8 desarrolladores. El resto de la organización de ingeniería ha expresado interés.

¿Qué diseño de cohorte produce el resultado más defendible al Día 30? Elige una opción.

• A. Los 8 desarrolladores que son dueños del backlog de migración de C++ a Rust
• B. 15 desarrolladores de la migración y de otros dos equipos
• C. Los 45 desarrolladores en una cohorte inicial de concienciación

Ver respuesta

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

• A. Los 8 dueños del backlog de migración (2 puntos, mejor opción): propiedad directa del caso de uso. Los datos de PR son atribuibles, las líneas base son limpias y la historia del Día 30 queda enfocada. Retroalimentación: +2. La cohorte de migración de 8 personas es la elección correcta. La propiedad directa del caso de uso hace que los datos de PR sean atribuibles al piloto, las líneas base sean limpias y la historia del Día 30 no necesite matices.
• B. 15 desarrolladores de la migración y de otros dos equipos (1 punto, parcial): más amplitud, pero los casos de uso mezclados dificultan la atribución del ROI. Los datos de la migración se diluirán con trabajo no relacionado. Retroalimentación: +1. Las cohortes mixtas producen señales mixtas. Si vas a ampliar, hazlo en la Fase 2, cuando tengas una historia de línea base limpia del caso de uso central que sirva de ancla para la expansión.
• C. Los 45 desarrolladores en una cohorte de concienciación (0 puntos): genera datos de adopción, no de ROI. Sin responsables de caso de uso, sin líneas base acotadas y sin nada que presentar al Día 30. Retroalimentación: +0. Una cohorte amplia de concienciación produce datos de uso, no datos de ROI. Los datos de uso son fáciles de generar y difíciles de monetizar en una conversación de renovación.

Decisión 2 · Criterio de éxito

La cohorte de migración de 8 desarrolladores está confirmada. Ahora define el criterio de éxito principal.

¿Qué criterio de éxito ofrece la historia más defendible al Día 30? Elige una opción.

• A. Puntuación de satisfacción de los desarrolladores al Día 30
• B. Tiempo de ciclo de PR desde el ticket hasta el merge, con la línea base del Día 1 capturada
• C. Líneas de código Rust producidas por desarrollador y por semana

Ver respuesta

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

• A. Puntuación de satisfacción al Día 30 (1 punto, parcial): señal cualitativa útil, pero no es un caso de negocio. Los CIO quieren datos de productividad, no puntuaciones de NPS. Retroalimentación: +1. La satisfacción de los desarrolladores es una señal real, pero no cierra un caso de negocio. Úsala como evidencia de apoyo junto a una métrica de productividad, no como criterio principal.
• B. Tiempo de ciclo de PR desde el ticket hasta el merge, con la línea base del Día 1 (2 puntos, mejor opción): limpio, auditable y directamente vinculado al caso de uso. La comparación del Día 30 es limpia. Retroalimentación: +2. El tiempo de ciclo de PR es el ancla correcta. Ya se registra, captura el ciclo completo de desarrollo y una línea base del Día 1 hace que la comparación del Día 30 sea simple y auditable.
• C. Líneas de código Rust por desarrollador y por semana (0 puntos): métrica de vanidad. Producir más código más rápido no significa mejor código ni la finalización más rápida de los hitos de migración. Retroalimentación: +0. Las líneas de código son una métrica proxy que Claude infla por defecto. Mostrarán cifras grandes sin demostrar que los hitos de migración se completan más rápido.

Decisión 3 · Gestión del alcance

En la Semana 2, dos de los desarrolladores están entusiasmados con usar Claude en un proyecto de documentación independiente y quieren ampliar el alcance.

¿Qué haces? Elige una opción.

• A. Registrar la documentación para la Fase 2 y proteger el alcance de la migración
• B. Dejar que los dos desarrolladores repartan su tiempo, pero hacer el seguimiento por separado
• C. Ampliar el piloto para incluir la documentación

Ver respuesta

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

• A. Registrar la documentación para la Fase 2 y proteger el alcance de la migración (2 puntos, mejor opción): ampliar el alcance a mitad del piloto diluye la historia de ROI. Una historia sólida de un caso de uso vale más que dos débiles. Retroalimentación: +2. Proteger el alcance es la decisión correcta. Una historia de caso de uso enfocada y con datos limpios vale más que dos historias diluidas con atribución mezclada. El proyecto de documentación tendrá su propio piloto en la Fase 2.
• B. Repartir el tiempo y hacer seguimiento por separado (1 punto, parcial): manejable, pero genera complejidad en los informes. Los datos de migración serán más escasos y los datos de documentación no tendrán línea base. Retroalimentación: +1. El seguimiento en paralelo es manejable, pero añade carga a los informes y adelgaza los datos de migración. Si tomas esta vía, asegúrate de que las líneas base estén separadas desde el Día 1, no aplicadas retroactivamente.
• C. Ampliar el piloto para incluir la documentación (0 puntos): el readout del Día 30 tendrá dos historias mezcladas, ninguna con datos limpios de antes y después. Las decisiones de ampliación pertenecen a la Fase 2. Retroalimentación: +0. La ampliación de alcance a mitad del piloto casi siempre degrada la historia del Día 30. La narrativa de ROI pierde foco y los datos se vuelven más difíciles de atribuir.

Ver cierre del escenario

5–6 puntos · Veredicto: Diseño apto para piloto. Protegiste el alcance, elegiste la cohorte correcta y escogiste criterios de éxito defendibles. El readout de Kellner tendrá los datos para respaldarlo.

3–4 puntos · Veredicto: Base sólida. Tomaste bien las decisiones importantes, pero se te escaparon algunos detalles. Vuelve a leer las secciones de alcance y de criterios de éxito: la historia del Día 30 está en la precisión de esas decisiones.

0–2 puntos · Veredicto: Revisa el diseño del piloto. La cohorte, los criterios de éxito y la gestión del alcance son las tres palancas que determinan si un piloto produce un caso de negocio o solo un informe de uso.

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 diseño del piloto.

1. Nombra tu cohorte: cuántos desarrolladores, qué equipo y por qué son los dueños adecuados del caso de uso.
2. Escribe tu criterio de éxito principal con el formato: “[Métrica] [mejorará/disminuirá] en [umbral] respecto a la línea base del Día 1 para [fecha].”
3. Indica cómo se capturará la línea base y desde qué sistema.
4. Define la protección del alcance: qué queda explícitamente fuera de alcance durante el periodo del piloto.

Ideas clave

• La cohorte se elige por propiedad del caso de uso, no por disponibilidad. Los voluntarios entusiastas no representan al desarrollador típico.
• Alcance y duración son decisiones de diseño: un caso de uso específico y al menos dos ciclos completos de tarea por desarrollador (25–30 días para la mayoría de las migraciones).
• Los criterios de éxito (línea base, umbral objetivo, método de medición y fecha) deben existir antes del Día 1. Un criterio que no se puede medir antes del piloto es una hipótesis.
• Protege el alcance: las ideas nuevas se registran para la Fase 2 en lugar de ampliar el piloto en marcha.
• Un piloto sin criterios de éxito defendibles es una prueba, no un entregable del engagement. Propiedad de la cohorte, captura de la línea base y protección del alcance determinan si tienes una historia para el Día 30.

Siguiente: Medición de ROI