Discovery antes do código: o que fazer na primeira semana
O que descobrir sobre processo, usuário e risco antes de escrever a primeira linha — e o que dá para adiar sem prejuízo.
04 de setembro de 2026 · 2 min de leitura · Luiz Paulo J. Rodrigues
Muita gente chama de “discovery” uma reunião de kickoff com slides. Discovery de verdade é outra coisa: é o trabalho de tornar o risco visível antes de o código começar a engessar decisões.
Se você pula essa etapa, o projeto não fica mais rápido. Ele só adia a conversa difícil — e ela volta mais cara.
O que precisa ficar claro na primeira semana
Três perguntas bastam para orientar o resto:
- Qual tarefa deixa de ser feita à mão quando o produto existir?
- Quem sofre hoje se essa tarefa falhar?
- Como você sabe que a primeira versão melhorou algo?
Sem resposta honestas, qualquer tela é chute bem desenhado.
Mapear o processo real (não o processo do organograma)
Peça para a pessoa que executa mostrar o fluxo com dados reais: planilha, WhatsApp, e-mail, sistema antigo. Anote exceções — é nelas que o software costuma quebrar.
O objetivo não é documentar tudo. É achar o caminho feliz e as duas ou três exceções que destroem a operação se forem ignoradas.
Separar desejo de necessidade
Lista de desejos aparece fácil. Necessidade aparece quando você pergunta: “se só der para entregar três coisas no primeiro ciclo, quais são?”
Isso se conecta direto ao recorte de MVP em oito semanas: discovery bom encurta debate na hora do corte.
Riscos técnicos que cabem cedo
Ainda sem código de produto, dá para validar:
- integrações obrigatórias (existe API? documentação? ambiente de teste?);
- volume aproximado (dezenas, centenas ou milhares de registros por dia);
- restrições de acesso e dados sensíveis;
- necessidade de mobile de verdade ou só navegador responsivo.
Nada disso exige arquitetura completa. Exige não mentir para si mesmo sobre o terreno.
O entregável que evita “achismo”
Ao fim da semana, um pacote enxuto:
- problema em uma frase;
- usuário principal e usuário secundário;
- fluxo principal em passos;
- lista do que entra / fica de fora no primeiro ciclo;
- riscos abertos com dono da decisão.
Se o pacote não existe, o time de desenvolvimento vai inventar — e inventar escopo é a forma mais cara de descobrir o óbvio.
O que dá para adiar
Wireframes de todas as telas, escolha fina de tipografia, automação secundária, relatórios “bonitos”. Adie o que não muda a modelagem de dados nem o fluxo crítico.
Sinais de que o discovery falhou
- O briefing muda toda reunião e ninguém atualiza o documento.
- “Faz igual ao sistema X” sem explicar o que do X importa.
- Ninguém do negócio participa — só o intermediário.
Próximo passo
Se você vai contratar desenvolvimento, leve esse pacote. Ajuda a comparar propostas com o mesmo critério — e evita a proposta genérica que não fecha.
Quer estruturar isso com a gente? Use o formulário de diagnóstico.
