O roadmap não é uma lista de projetos — é uma sequência de apostas ordenada por valor, risco e aprendizado. A abordagem em ondas garante que cada etapa valida o que a próxima precisa para funcionar.
Roadmap em ondas — sem marco de validação, a onda seguinte começa sobre incerteza.
🌊 Ondas: crawl, walk, run
Cada onda tem um objetivo de negócio, não apenas uma entrega técnica. Crawl prova que é possível e útil. Walk verifica que escala operacionalmente. Run é quando o padrão vira padrão.
Crawl — provar valor
Escopo mínimo que responde à pergunta: "isso funciona aqui?" Com dados reais, usuários reais, mas volume controlado. Resultado esperado: sim ou não, com dados.
Duração típica: 4-8 semanas. Critério de saída: métrica pré-definida atingida.
Walk — ampliar cobertura
Expande o que crawl validou para mais casos de uso, mais usuários ou mais volume. Constrói as capacidades reutilizáveis e integra com mais sistemas.
Duração típica: 8-16 semanas. Pré-requisito: crawl validado.
Run — escalar
O padrão vai para toda a organização ou toda a operação. Os processos de monitoramento e manutenção já existem. O time sabe operar.
Duração típica: contínuo. Pré-requisito: walk validado com SLA definido.
⚠️ O erro mais caro
Ir direto para Run sem passar por Crawl. O rollback de uma solução que foi para toda a operação sem validação custa 10× mais do que um piloto que falhou.
🔗 Dependências: dados e fundação primeiro
A maior fonte de atraso em projetos de IA não é o modelo — são as dependências não mapeadas: dados que não existem ou não têm qualidade suficiente, integrações que levam meses, permissões que exigem aprovação jurídica.
Dependências comuns
- 🗄️Dados: existência, qualidade, acesso, privacidade
- 🔌Integrações: APIs de sistemas legados, CRM, ERP
- 👥Equipe: capacidade técnica, treinamento, tempo
- ⚖️Governança: compliance, LGPD, aprovações
Ordem recomendada
💡 Dica prática
Mapeie dependências no primeiro sprint, antes de escrever código. Use uma tabela simples: dependência, responsável, prazo, bloqueador. Revise semanalmente. Dependências invisíveis são o maior risco de cronograma.
🏆 Sequenciar por valor, risco e aprendizado
Quando há múltiplos casos de uso candidatos, o critério de sequência não é "o mais empolgante" nem "o que o CTO pediu". É uma combinação de valor potencial, risco de execução e o que o caso ensina para os próximos.
📐 Critérios de sequenciamento
| Critério | O que avaliar | Ideal para 1ª onda |
|---|---|---|
| Valor | Quanto impacto se funcionar (R$ ou tempo) | Visível e significativo, mas não crítico |
| Risco | Chance de falhar × custo do erro | Controlável, erro tolerável |
| Aprendizado | O que esse caso ensina para os próximos | Alto — desbloqueará capacidades reutilizáveis |
🧱 Capacidades reutilizáveis
O consultor que pensa em plataforma antes de feature reduz o custo marginal de cada onda seguinte. Uma capacidade reutilizável é qualquer bloco construído num caso de uso que pode ser aproveitado nos próximos sem reconstrução.
Ingestão, limpeza e normalização de dados. Construída uma vez, serve todos os modelos.
Módulo que identifica pessoas, produtos, datas. Reutilizável em qualquer caso com texto.
Integração com sistemas de negócio. Construída para um caso, serve os próximos.
Sistema de alertas quando o comportamento do modelo muda. Vale para todos os modelos.
Padrões de prompt testados para tarefas recorrentes. Reutilizáveis com variação mínima.
Framework de testes de qualidade de saída. Reaproveitado em todos os módulos de IA.
🗓️ Roadmap visual com marcos e responsáveis
O roadmap visual serve a um propósito prático: alinhar expectativas. Quando todos olham para o mesmo diagrama, as divergências aparecem na reunião de planejamento — não no mês do prazo.
📋 Estrutura mínima do roadmap
Crawl / Walk / Run claramente separados no tempo, com duração estimada e datas-âncora.
Cada bloco numa linha ou coluna, com nome, responsável e onda de execução.
Go/no-go ao final de cada onda, com critério de sucesso visível.
Setas ligando o que depende do quê. As críticas ficam em vermelho.
💡 Dica prática
Ferramenta não importa: uma tabela no Google Docs ou um quadro no Miro funcionam igual. O que importa é que seja público, atualizado semanalmente e que todo mundo saiba onde achar.
🔁 Replanejar com o que o piloto ensinou
O piloto é o melhor consultor que você vai ter. Ele revela o que o planejamento não conseguia ver: dados piores do que o esperado, integração mais complexa, ou um caso de uso que entregou 3× mais valor do que o previsto. Usar esses dados para replanejar é obrigatório.
O que o piloto frequentemente ensina
- →Os dados têm mais lacunas do que o mapeamento mostrou
- →A integração com sistema legado vai levar 2× mais tempo
- →Um caso adjacente não mapeado tem valor maior
- →O modelo funciona bem, mas a equipe resiste à adoção
Revisão formal pós-onda
🎒 Resumo do módulo
Próximo módulo:
4.3 — Escolher o nível da pirâmide para cada caso