Discovery técnico em 4 semanas

Projetos de software falham com mais frequência por incerteza não tratada antes da construção do que por execução ruim depois. O Standish Group CHAOS Report registra que apenas cerca de 31% dos projetos são entregues com sucesso, e requisitos mal compreendidos aparecem consistentemente entre as principais causas.

Discovery técnico é um instrumento para tratar essa incerteza antes do compromisso de execução. Em quatro semanas é possível mapear viabilidade, riscos, custo e cronograma realista o suficiente para responder a pergunta central: vale construir, como e a que custo?

A estrutura abaixo é uma das formas que costumam funcionar bem. Não é receita única, e o ritmo pode mudar conforme o domínio.

Semana 1: o que o negócio realmente precisa?

Antes de qualquer linha de código ou decisão de arquitetura, o problema precisa estar claro.

Isso costuma envolver entrevistas com os stakeholders certos: quem financia, quem usa, quem opera. Mapear as métricas que importam (o que muda no negócio se isso funcionar?) e as restrições reais (prazo regulatório, budget disponível, time existente, legado que não pode ser tocado).

Entregáveis típicos da semana 1:

• Mapa de stakeholders e seus critérios de sucesso.
• Definição do problema central (não da solução).
• Lista de hipóteses a validar nas semanas seguintes.
• Restrições documentadas (técnicas, regulatórias, orçamentárias).

Quando há usuários finais envolvidos, três a cinco entrevistas curtas tendem a ser suficientes nesta semana. Teresa Torres, em Continuous Discovery Habits, defende que a tríade produto/design/engenharia precisa de contato direto com quem vai usar o que está sendo construído desde o primeiro momento.

Semana 2: como isso pode ser construído?

Com o problema claro, engenharia entra com força.

O objetivo aqui não é definir a arquitetura final. É mapear o espaço de soluções e identificar onde estão os riscos. Quais integrações externas existem e qual o nível de maturidade das APIs? Há dependências de sistemas legados? Quais requisitos de segurança e compliance impactam a arquitetura?

As primeiras ADRs (Architecture Decision Records) costumam surgir aqui, ainda abertas. São registros de decisões com contexto, opções consideradas e trade-offs, não documentos burocráticos.

Entregáveis típicos da semana 2:

• Diagrama de contexto do sistema (modelo C4 nível 1 e 2, por exemplo).
• Lista de integrações externas com avaliação de risco.
• ADRs iniciais para as decisões estruturantes.
• Mapa de riscos técnicos por probabilidade e impacto.

A SVPG (Silicon Valley Product Group) descreve esse momento como o cruzamento entre os quatro grandes riscos de produto (valor, usabilidade, viabilidade técnica e viabilidade de negócio), que precisam ser avaliados em paralelo.

Semana 3: o que precisa ser testado com código real?

Esta é a semana que separa discovery sério de análise infinita.

Dois ou três riscos críticos identificados na semana anterior viram provas de conceito (POCs). Não protótipos em Figma. Código funcional, ainda que descartável, que responde perguntas específicas:

• A latência dessa integração é aceitável para o fluxo principal?
• O modelo de LLM escolhido performa dentro do budget esperado?
• A migração de dados do sistema legado é tecnicamente viável no prazo?

Cada POC tem uma pergunta clara e um critério de sucesso definido antes de começar. Quando a resposta é “não funciona como esperado”, o resultado é informação valiosa, não fracasso.

Entregáveis típicos da semana 3:

• 2-3 POCs com código versionado e resultado documentado.
• Revisão dos riscos do mapa inicial (o que mudou?).
• Ajuste nas hipóteses de arquitetura com base nos dados reais.

Semana 4: qual é o plano realista?

Com contexto de negócio, mapeamento técnico e POCs em mão, a semana 4 é de síntese.

O resultado é um plano que uma liderança técnica ou executiva consegue usar para tomar decisão. Os componentes mais comuns:

• Cronograma por fases com marcos claros (não “3 meses de desenvolvimento”, mas fase 1, fase 2, critérios de entrada e saída).
• Estimativa de custo em squad/meses, com premissas explícitas.
• Roadmap técnico inicial com sequenciamento de dependências.
• Critérios go/no-go objetivos: o que precisa ser verdade para avançar?

Entregáveis típicos da semana 4:

• Documento de síntese (10-15 páginas, sem enrolação).
• Apresentação executiva com recomendação clara.
• Backlog inicial do primeiro ciclo de construção, se a decisão for avançar.

O que costuma sabotar um discovery?

Alguns padrões comprometem o resultado antes de o ciclo terminar.

Discovery virando análise infinita. Quando o time gasta dias refinando um diagrama que ninguém vai usar, algo está fora do lugar. Cada entregável deve responder a uma pergunta específica de negócio ou técnica.

Pular POC para “começar logo”. A lógica parece razoável: por que gastar uma semana testando algo que provavelmente funciona? Porque o custo de descobrir que não funciona na semana 8 de construção é ordens de magnitude maior.

Não envolver engenharia sênior desde o início. Discovery feito só por produto ou só por negócio gera planos que engenharia desmonta na primeira sprint. O valor está exatamente na troca entre as perspectivas, desde o primeiro dia.

Tratar discovery como entregável e não como processo. O objetivo não é o documento de síntese. É a decisão melhor informada. O documento é consequência.