Identificación y calificación de casos de uso

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

Al terminar esta lección podrás calificar cualquier caso de uso que merezca un piloto e identificar los tres patrones de engagement que producen de forma consistente una historia de ROI defendible al Día 30.

No todo caso de uso merece un piloto.

Filtro de calificación

Dos tipos de ganancia. Solo una sobrevive a un readout (informe de resultados) ante el CIO.

Antes de acotar un piloto, necesitas saber si el caso de uso produce un cambio estructural o una mejora marginal. La distinción determina si tu caso de ROI se sostiene al Día 30.

Ganancia marginal: hace el mismo trabajo más rápido. La unidad de trabajo no cambia. Claude acelera una tarea existente, reduce fricción o recorta el tiempo de algo repetitivo. Las ganancias de productividad son reales pero difusas, y difíciles de aislar de otros factores en una ventana de 30 días. Ejemplos: autocompletado, generación de código repetitivo y documentación en línea. Son buenas para impulsar la adopción, pero difíciles de anclar a un caso de negocio de nivel CIO.

Ganancia estructural: cambia qué trabajo es posible. La unidad de trabajo en sí cambia. Una tarea que requería un equipo de cuatro personas y seis semanas ahora requiere dos desarrolladores y dos semanas. El caso de ROI es medible antes del Día 30 y defendible en el readout. Ejemplos: migración de sistemas heredados a gran escala, nuevos ciclos de funcionalidades con participación completa de Claude y modernización a nivel de framework. Sirve para anclar una conversación de renovación.

Modo de activación

Dos modos de activación. Uno cambia los datos que obtienes.

La decisión de alcance se toma al inicio del engagement. El modo 1 es una activación solo de formación. El modo 2 la envuelve en un programa estructurado de 30–45 días.

Modo 1: activación de formación de 2 días. Code 101 y la configuración administrativa se imparten como un evento de formación independiente. Es rápida de desplegar y requiere poca configuración. Produce señales de adopción, pero no datos de ROI: no hay periodo de medición, ni responsable de caso de uso, ni métricas con línea base para cerrar el ciclo.

Modo 2: programa de 30–45 días. Formación más una activación estructurada: configuración previa al inicio, definición del caso de uso, un punto de control intermedio en los días 20–25 y un readout de cierre (closeout readout) con resultados expuestos por el champion. Hay datos de ROI porque la infraestructura de medición se construyó antes del Día 1.

Dónde gana Claude Code

Tres patrones de engagement que producen de forma consistente ganancias estructurales

1. Modernización de código. Migrar pilas heredadas, traducir lenguajes y actualizar dependencias en una base de código grande. Claude asume el volumen; los desarrolladores toman las decisiones de juicio sobre la arquitectura. La proporción de commits asistidos por Claude frente al total de commits es directamente medible.
2. Construcción de nuevas funcionalidades. Acelerar el desarrollo de funcionalidades nuevas a lo largo de todo el ciclo: andamiaje, implementación, pruebas y preparación de la revisión. El tiempo de ciclo de PR antes y después es la métrica central. Funciona mejor cuando el alcance de la funcionalidad está claro y el CLAUDE.md está bien trabajado.
3. Migración de código. Mover código entre frameworks, proveedores de nube o patrones arquitectónicos. Son tareas bien acotadas, de alto volumen y baja ambigüedad, ideales para la delegación agéntica. La ganancia de velocidad es visible en las primeras dos semanas.

¿Califica este caso de uso?

Cuatro criterios que separan un caso digno de piloto de un elemento de lista de deseos

No todo caso de uso que suena prometedor supera la calificación. Evalúa cada candidato con estos cuatro criterios antes de comprometer el alcance del piloto. Una puntuación débil en cualquiera de ellos es una señal para replantear el caso de uso o bajar su prioridad.

• Volumen: la tarea se repite con la frecuencia suficiente para generar datos significativos en 30 días. Un proyecto puntual no califica, sin importar su complejidad.
• Complejidad: Claude aporta una palanca real, no solo velocidad. Si un desarrollador junior podría hacer la tarea en una tarde, la contribución de Claude es marginal. Si le tomaría a un ingeniero senior tres semanas, hay ganancia estructural disponible.
• Medibilidad: puedes capturar una línea base antes del Día 1. Si no puedes medirlo antes de que empiece el piloto, no podrás cerrar el ciclo de ROI al Día 30. Esto no es negociable.
• Preparación de los desarrolladores: el equipo está dispuesto a cambiar su flujo de trabajo, no solo a probar una herramienta. Un piloto en el que los desarrolladores usan Claude de vez en cuando, alrededor de sus hábitos existentes, produce métricas planas. La adopción tiene que diseñarse desde el inicio.

flowchart LR
    A["Caso de uso candidato"] --> B{"Tipo de ganancia"}
    B -->|"Marginal"| C["Impulsa la adopción; difícil de anclar al caso de negocio"]
    B -->|"Estructural"| D["Evaluar los cuatro criterios"]
    D --> E{"¿Algún criterio débil?"}
    E -->|"Sí, en otro criterio"| F["Replantear el caso o bajar su prioridad"]
    E -->|"Sí, en medibilidad"| G["Es un riesgo, no un candidato a piloto"]
    E -->|"No"| H["Candidato a piloto"]

Regla de calificación. Un caso de uso que puntúa bien en complejidad pero falla en medibilidad no es un candidato a piloto. Es un riesgo.

Comprueba tu comprensión

Escenario: la calificación de Arvana Technologies

Arvana Technologies es una empresa de software de mercado medio con un equipo de ingeniería de 60 desarrolladores. Su CTO quiere 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 del caso de uso

El responsable de ingeniería de Arvana propone dos casos de uso. Opción A: usar Claude Code para añadir tests unitarios a una base de código que ya tiene 82 % de cobertura. Opción B: una migración de Java a Spring Boot que el equipo lleva ocho meses planificando.

¿Qué caso de uso califica para el piloto? Elige una opción.

• A. Generación de tests unitarios
• B. Migración de Java a Spring Boot
• C. Ambos, en paralelo

Ver respuesta

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

• A. Generación de tests unitarios (0 puntos): 82 % de cobertura ya es alta. Claude aporta velocidad, no cambio estructural. No hay una brecha de línea base significativa que cerrar. Retroalimentación: +0. La generación de tests unitarios con 82 % de cobertura es una ganancia marginal. Claude aporta velocidad, no cambio estructural. Un readout para el CIO basado en cobertura incremental de tests no impulsará la renovación.
• B. Migración de Java a Spring Boot (2 puntos, mejor opción): alto volumen, cambio estructural claro y previamente acotado. Cumple los cuatro criterios de calificación. Retroalimentación: +2. La migración es la decisión correcta. Cumple los cuatro criterios de calificación: volumen (ocho meses de backlog acotado), complejidad (se necesita juicio de ingeniería senior), medibilidad (el tiempo de ciclo de PR se puede seguir desde el Día 1) y preparación de los desarrolladores (el equipo lleva meses pensando en ello).
• C. Ambos, en paralelo (1 punto, parcial): el caso de tests diluye la señal de ROI. Mezclar casos de uso estructurales y marginales en un mismo piloto dificulta la atribución en el readout del Día 30. Retroalimentación: +1. Los casos de uso en paralelo dividen la señal. Si la migración muestra un ROI sólido y la cobertura de tests no mejora, el resultado combinado parece mediocre. Empieza por el caso de uso estructural.

Decisión 2 · Captura de la línea base

El equipo elige la migración. Ahora determina qué métrica debes registrar como línea base antes del Día 1.

¿Qué métrica de línea base ofrece la historia de ROI más defendible al Día 30? Elige una opción.

• A. Tiempo de ciclo de PR desde el ticket hasta el merge en las tareas de migración
• B. Horas de desarrollador registradas por tarea de migración
• C. Líneas de código migradas por semana

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 desde el ticket hasta el merge (2 puntos, mejor opción): directamente medible antes de que empiece el piloto, captura el ciclo completo asistido por Claude y es visible en las herramientas existentes. Retroalimentación: +2. El tiempo de ciclo de PR es auditable, ya está en tus herramientas y captura el ciclo completo de desarrollo, desde el inicio hasta el merge. Es la métrica más directamente vinculada a la contribución de Claude.
• B. Horas de desarrollador registradas (1 punto, parcial): útil, pero autorreportada. Es más difícil de auditar y más susceptible al sesgo de estimación que los datos de PR. Retroalimentación: +1. Las horas del desarrollador funcionan como dato corroborante, pero conllevan riesgo de sesgo en los informes. Combínalas con una métrica objetiva como el tiempo de ciclo de PR para una historia de ROI más defendible.
• C. Líneas de código migradas por semana (0 puntos): una métrica de vanidad. Claude produce más líneas más rápido, pero el conteo no mide la calidad ni la completitud del trabajo de migración. Retroalimentación: +0. Las líneas de código son una mala señal de ROI. Claude genera más código más rápido, pero el código generado más rápido no es necesariamente mejor código. La calidad de la migración y la velocidad de PR son señales más fuertes.

Decisión 3 · Composición de la cohorte

Estás diseñando la cohorte del piloto. Arvana tiene 60 desarrolladores. La migración es el trabajo.

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

• A. 8–10 desarrolladores que son dueños del backlog de migración
• B. 20 desarrolladores de cuatro equipos diferentes
• C. Los 60 desarrolladores, empezando con formación de concienciación

Ver respuesta

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

• A. 8–10 desarrolladores dueños del backlog de migración (2 puntos, mejor opción): señal profunda de las personas que hacen el trabajo real. Las métricas son trazables a tareas concretas. Retroalimentación: +2. Una cohorte reducida que trabaja en tareas reales de migración produce la señal más limpia. Estos desarrolladores tienen trabajo acotado, patrones familiares y una comparación clara de antes y después. Los datos resistirán en el readout.
• B. 20 desarrolladores de cuatro equipos (1 punto, parcial): señal más amplia pero con menos profundidad. Los casos de uso mezclados y los tipos de tarea variados dificultan atribuir la historia de ROI. Retroalimentación: +1. Veinte desarrolladores en cuatro equipos darán datos de adopción más amplios, pero una atribución de ROI más delgada. Tendrás estadísticas de uso, no una historia de caso de uso. Es útil para la Fase 2, no para cerrar el ciclo del Día 30.
• C. Los 60 desarrolladores con formación de concienciación (0 puntos): demasiado amplio para un readout del Día 30. No tiene responsables de caso de uso, tareas acotadas ni un punto de partida medible. Retroalimentación: +0. Empezar con sesenta desarrolladores en modo de solo concienciación produce datos de engagement, no de ROI. Sin casos de uso acotados ni métricas de línea base, no hay nada que cerrar al Día 30.

Ver cierre del escenario

5–6 puntos · Veredicto: Listo para piloto. Sabes qué casos de uso califican y por qué. Tu readout del Día 30 tendrá los datos para respaldarlo.

3–4 puntos · Veredicto: Dirección correcta. Elegiste el caso de uso correcto, pero los detalles del diseño necesitan ajustes. Vuelve a leer las secciones de medibilidad y de cohorte antes de la siguiente llamada de definición de alcance.

0–2 puntos · Veredicto: Revisa el marco. La selección del caso de uso y el diseño del piloto son las primeras decisiones estructurales de cualquier engagement. Un inicio débil produce datos débiles al Día 30.

Artefacto del curso: Delivery Plan Pack

Al terminar el curso tendrás un Delivery Plan Pack completo que cubre calificación, diseño del piloto, scorecard de ROI y plan de champions. Esta lección aporta la sección de calificación.

1. Nombra el caso de uso en una frase. Indica qué hará Claude Code en el contexto de una base de código o de un flujo de trabajo específico.
2. Etiquétalo como estructural o marginal y explica por qué en dos frases. Haz referencia a la unidad de trabajo que cambia (o que no cambia).
3. Puntúalo con los cuatro criterios: volumen, complejidad, medibilidad y preparación de los desarrolladores. Señala cualquier criterio débil e indica si puede abordarse antes de que empiece el piloto.

Ideas clave

• Un caso de uso es estructural cuando cambia la unidad de trabajo y su ROI es medible antes del Día 30. Es marginal cuando solo acelera una tarea que ya existe.
• El modo 1 (formación de 2 días) produce señales de adopción; el modo 2 (programa de 30–45 días) produce datos de ROI porque la medición se construye antes del Día 1.
• Los tres patrones con ganancias estructurales son la modernización de código, la construcción de nuevas funcionalidades y la migración de código.
• Los cuatro criterios de calificación son volumen, complejidad, medibilidad y preparación de los desarrolladores. Un caso que falla en medibilidad es un riesgo, aunque puntúe bien en complejidad.
• La distinción entre estructural y marginal es la primera decisión en cualquier engagement de Claude Code, y las ganancias estructurales son las que producen un ROI defendible.

Siguiente: Diseño del piloto