El roadmap no es una lista de proyectos: es un secuencia de apuestas ordenada por valor, riesgo y aprendizaje. El enfoque por etapas garantiza que cada etapa valide lo que la siguiente necesita para funcionar.
Roadmap por olas: sin un hito de validación, la siguiente ola comienza sobre la incertidumbre.
🌊 Olas: crawl, walk, run
Cada etapa tiene un objetivo de negocio, no solo una entrega técnica. Crawl demuestra que es posible y útil. Walk verifica que escale operativamente. Run es cuando el estándar se convierte en estándar.
Crawl — demostrar valor
Alcance mínimo que responde a la pregunta: «¿esto funciona aquí?». Con datos reales, usuarios reales, pero con volumen controlado. Resultado esperado: sí o no, con datos.
Duración típica: 4-8 semanas. Criterio de salida: métrica predefinida alcanzada.
Walk — ampliar la cobertura
Amplía lo que crawl validó a más casos de uso, más usuarios o más volumen. Construye capacidades reutilizables e integra más sistemas.
Duración típica: 8-16 semanas. Requisito previo: crawl validado.
Run — escalar
El patrón se aplica a toda la organización o a toda la operación. Los procesos de monitoreo y mantenimiento ya existen. El equipo sabe cómo operarlo.
Duración típica: continua. Requisito previo: walk validado con SLA definido.
⚠️ El error más costoso
Ir directamente a Run sin pasar por Crawl. Revertir una solución implementada en toda la operación sin validación cuesta 10× más que un piloto fallido.
🔗 Dependencias: primero los datos y los fundamentos
La mayor fuente de retrasos en los proyectos de IA no es el modelo, sino las dependencias que no se mapearon: datos que no existen o no tienen suficiente calidad, integraciones que llevan meses, permisos que requieren aprobación legal.
Dependencias comunes
- 🗄️Datos: existencia, calidad, acceso, privacidad
- 🔌Integraciones: API de sistemas heredados, CRM, ERP
- 👥Equipo: capacidad técnica, capacitación, tiempo
- ⚖️Gobernanza: cumplimiento, LGPD, aprobaciones
Orden recomendado
💡 Consejo práctico
Mapea las dependencias en el primer sprint, antes de escribir código. Usa una tabla sencilla: dependencia, responsable, plazo, bloqueo. Revísala semanalmente. Las dependencias invisibles son el mayor riesgo para el cronograma.
🏆 Secuenciar por valor, riesgo y aprendizaje
Cuando hay varios casos de uso candidatos, el criterio para definir la secuencia no es «el más emocionante» ni «lo que pidió el CTO». Es una combinación de valor potencial, riesgo de ejecución y lo que enseña el caso para los próximos.
📐 Criterios de secuenciación
| Criterio | Qué evaluar | Ideal para la 1.ª ola |
|---|---|---|
| Valor | Cuánto impacto tendría si funciona (R$ o tiempo) | Visible y significativo, pero no crítico |
| Riesgo | Probabilidad de fallar × costo del error | Controlable, con margen para equivocarse |
| Aprendizaje | Qué enseña este caso para los próximos | Alto — desbloqueará capacidades reutilizables |
🧱 Capacidades reutilizables
El consultor que piensa en la plataforma antes que en la funcionalidad reduce el costo marginal de cada ola siguiente. Una capacidad reutilizable es cualquier bloque construido para un caso de uso que puede aprovecharse en los próximos sin reconstrucción.
Ingesta, limpieza y normalización de datos. Se construye una vez y sirve para todos los modelos.
Módulo que identifica personas, productos, fechas. Reutilizable en cualquier caso con texto.
Integración con sistemas de negocio. Se construye para un caso y sirve para los siguientes.
Sistema de alertas cuando cambia el comportamiento del modelo. Aplica a todos los modelos.
Patrones de prompts probados para tareas recurrentes. Reutilizables con variación mínima.
Framework de pruebas de calidad de salida. Reutilizado en todos los módulos de IA.
🗓️ Roadmap visual con hitos y responsables
El roadmap visual cumple un propósito práctico: alinear expectativas. Cuando todos miran el mismo diagrama, las diferencias aparecen en la reunión de planificación, no el mes en que vence el plazo.
📋 Estructura mínima del roadmap
Crawl / Walk / Run claramente diferenciados en el tiempo, con duración estimada y fechas de referencia.
Cada bloque en una fila o columna, con nombre, responsable y etapa de ejecución.
Decisión de avanzar o no al final de cada etapa, con criterios de éxito visibles.
Flechas que conectan qué depende de qué. Los elementos críticos van en rojo.
💡 Consejo práctico
La herramienta no importa: una tabla en Google Docs o un tablero en Miro funcionan igual. Lo que importa es que sea público, se actualice semanalmente y que todos sepan dónde encontrarlo.
🔁 Replanificar con lo que enseñó el piloto
El piloto es el mejor consultor que tendrás. Revela lo que la planificación no podía prever: datos peores de lo esperado, una integración más compleja o un caso de uso que generó 3× más valor de lo previsto. Usar estos datos para replanificar es obligatorio.
Qué suele enseñar el piloto
- →Los datos tienen más brechas de las que mostró el mapeo
- →La integración con el sistema heredado llevará 2× más tiempo
- →Un caso adyacente no identificado tiene más valor
- →El modelo funciona bien, pero el equipo se resiste a adoptarlo
Revisión formal posterior a la ola
🎒 Resumen del módulo
Siguiente módulo:
4.3 — Elegir el nivel de la pirámide para cada caso