Discovery: o que é e por que vale fazer antes de codar

Resposta curta: discovery é uma fase curta (em geral de 1 a 3 semanas) em que a equipe entende o seu processo, define o que entra na primeira versão e o que fica de fora, e entrega escopo, telas e estimativa antes de escrever o código. Você paga por ela porque o erro mais caro num projeto de software é construir a coisa errada.

O nome vem do inglês (descoberta). Em outros lugares aparece como "fase de descoberta", "imersão" ou "levantamento de requisitos". Muda o rótulo, o objetivo é o mesmo: reduzir o risco antes de gastar a maior parte do orçamento.

Por que fazer discovery

Sem essa fase, o projeto começa com uma ideia parecida entre você e o fornecedor, mas não igual. A diferença só aparece meses depois, quando o sistema não bate com o que você imaginava. O discovery empurra essa descoberta para o começo, quando corrigir custa uma conversa, não semanas de retrabalho.

Ele resolve quatro problemas comuns:

• Escopo vago, que gera orçamento "chutado" e aditivos depois.
• Expectativas diferentes entre quem contrata e quem constrói.
• Riscos escondidos, como uma integração que não é possível ou dados que não estão organizados.
• Falta de prioridade, quando tudo é urgente e a primeira versão fica do tamanho do sistema inteiro.

O que acontece em um discovery

O formato varia entre fornecedores, mas costuma incluir estas atividades:

1. Conversas com quem usa o processo

Não só com o dono: com quem lança o pedido, quem cobra, quem atende o cliente. É neles que está a versão real do processo, com as exceções que ninguém escreve. Começamos ouvindo quem usa no dia a dia.

2. Mapa do processo atual

Um desenho simples de como o trabalho acontece hoje: quem faz o quê, com que ferramenta, onde há retrabalho. Frequentemente inclui olhar as planilhas e os sistemas que já existem. (Se você usa planilha para isso, veja quando a planilha deixou de servir.)

3. Levantamento de regras e integrações

Regras de negócio (cálculo de preço, prazos, aprovações), perfis de usuário e sistemas com os quais é preciso conversar. Essa etapa revela boa parte do custo.

4. Priorização

Uma lista do que é indispensável na primeira versão, do que é desejável e do que pode esperar. Uma técnica simples é perguntar, para cada funcionalidade: "se ela não existisse no primeiro dia, a operação para?".

5. Protótipo das telas principais

Desenhos navegáveis (não código) das telas mais importantes, para você "ver e clicar" antes de construir. Mudar um desenho custa minutos; mudar uma tela programada custa dias.

6. Definição técnica e estimativa

Escolha de tecnologia, riscos e um plano em ciclos, com estimativa de prazo e custo da primeira versão.

O que você recebe no final

• Escopo escrito da primeira versão, com o que está dentro e fora.
• Fluxos e telas principais desenhados.
• Lista de riscos e como serão tratados.
• Estimativa de prazo e investimento para construir, com margem de variação explicada.
• A decisão de seguir ou não. O discovery é também um ponto de saída: você pode ficar com o material e contratar outro fornecedor, ou perceber que um sistema pronto resolve.

Vale exigir que os documentos sejam seus, independentemente de quem vá construir. Esse ponto entra no checklist de como escolher uma software house.

Quanto tempo e quanto custa

Como referência de mercado, um discovery costuma levar de 1 a 3 semanas para um projeto pequeno ou médio, e pode passar disso em plataformas grandes. O investimento costuma ser uma fração pequena do projeto, algo como 5% a 10% do valor estimado da construção.

Faixas típicas, variam com escopo: um projeto que acabará custando R$ 100 mil pode ter um discovery na casa de alguns milhares a poucos mais de dez mil reais. A ideia é que esse valor evite o retrabalho que custaria muito mais. Para ver como o valor total se forma, leia quanto custa desenvolver um sistema sob medida.

Se o fornecedor abate o valor do discovery do contrato final, pergunte antes. É uma prática comum, mas não universal.

O que você precisa fazer do seu lado

O discovery só funciona com participação sua. Reserve:

• Uma pessoa com poder de decisão, disponível algumas horas por semana.
• Acesso a quem usa o processo, para entrevistas de 30 a 60 minutos.
• Material existente: planilhas, relatórios, exemplos de documentos, capturas de tela dos sistemas atuais.
• Dados de exemplo, mesmo anonimizados, para entender o volume e a bagunça real.

Quando dá para pular o discovery

Nem sempre ele é necessário. Um discovery formal costuma valer menos quando:

• O escopo é pequeno e muito claro (um formulário com envio de e-mail, por exemplo).
• Você já tem especificação escrita e protótipos.
• O projeto é uma evolução de um sistema que o fornecedor já conhece.

Mesmo nesses casos, um alinhamento curto de escopo por escrito antes de começar é uma boa ideia. Quando o projeto toca dinheiro, dados de clientes ou várias áreas da empresa, o discovery quase sempre se paga.

Sinais de um discovery bem-feito (e de um de fachada)

Como o discovery se encaixa no resto do projeto

Depois do discovery, a construção segue em ciclos curtos, com entregas que você pode testar (por exemplo, a cada duas semanas). O que aprendemos na descoberta guia a ordem: primeiro o núcleo do processo, depois o que aumenta a eficiência, por último o que é "bom ter". Isso combina com os dois modelos de contratação, que comparamos em escopo fechado ou banco de horas: com o escopo bem descrito, o fechado fica mais viável; com um escopo que muda, o banco de horas fica mais seguro.

Perguntas frequentes

Posso fazer o discovery com uma empresa e a construção com outra?

Pode, se os documentos forem entregues a você. Só avise a empresa que fará o discovery, porque isso muda o nível de detalhe técnico que você precisa receber.

Discovery é o mesmo que "levantamento de requisitos"?

É uma versão mais ampla. Além de listar requisitos, o discovery prioriza, desenha telas, avalia riscos e estima prazo e custo.

E se o discovery mostrar que o projeto é inviável?

É um bom resultado: você gastou uma fração pequena para descobrir isso, e não o orçamento inteiro.

Preciso pagar o discovery mesmo se já sei o que quero?

Se você tem escopo e protótipos, provavelmente não precisa de um discovery completo, só de uma revisão. O que não vale é assumir que "já sei" quando a especificação está só na sua cabeça.

Próximo passo

Se você tem um processo que quer transformar em sistema e não sabe por onde começar, um discovery é o primeiro passo mais seguro. Conte o que precisa e a gente propõe o formato adequado ao seu caso.

Falar com a gente