Discovery antes do código: o que fazer na primeira semana

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:

1. Qual tarefa deixa de ser feita à mão quando o produto existir?
2. Quem sofre hoje se essa tarefa falhar?
3. 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.

Um roteiro de entrevista com oito perguntas

A conversa com quem executa o processo rende mais do que qualquer formulário. Um roteiro simples:

1. Conte passo a passo como essa tarefa é feita hoje, do começo ao fim.
2. Quais ferramentas, planilhas ou aplicativos você usa?
3. Onde você perde mais tempo?
4. O que costuma dar errado? Qual foi a última vez?
5. Quem depende do resultado dessa tarefa e o que acontece quando atrasa?
6. Que informações você precisa e de onde elas vêm?
7. Existe alguma regra, lei ou política que não pode ser quebrada?
8. Como você saberia que a nova solução ficou melhor do que a atual?

Peça para a pessoa mostrar na tela, com dados reais (sem expor informações sensíveis). O que ela mostra costuma ser diferente do que ela descreve.

Exemplo ilustrativo de pacote preenchido

Para uma clínica pequena que controla consultas em planilha, o pacote do primeiro ciclo poderia ser:

• Problema: a recepção perde tempo conferindo horários duplicados e pacientes faltam por falta de lembrete.
• Usuário principal: recepcionista. Secundário: profissional de saúde.
• Fluxo principal: buscar horário livre, cadastrar paciente, confirmar, lembrar, registrar presença.
• Entra: agenda por profissional, cadastro básico, lembrete e lista do dia.
• Fica de fora: prontuário completo, integração com convênio, aplicativo para o paciente.
• Riscos abertos: onde está o histórico atual dos pacientes e quem autoriza a migração dos dados (dono da decisão: a direção da clínica).

(O exemplo é ilustrativo e serve de modelo de formato, não de recomendação para o seu caso.)

Quanto tempo leva

Para a maioria dos projetos de porte pequeno ou médio, uma ou duas semanas bastam para sair com o pacote acima. Projetos com muitas integrações ou áreas envolvidas podem pedir mais. O importante é que o discovery tenha começo, fim e entregável, e não vire uma fase sem fim.

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.