O que é Discovery, e por que ele vem antes de qualquer tela

Quando uma empresa contrata um site, um aplicativo ou um sistema, a vontade é ver logo a primeira tela. Mas a maior parte dos problemas de um projeto não está na tela: está numa regra que ninguém combinou. O Discovery existe para isso. É a etapa em que, antes de desenhar e de programar, cliente e equipe combinam como o produto deve funcionar.

De onde vem o nome

Discovery quer dizer "descoberta". O nome vem do jeito como as empresas de tecnologia passaram a construir produtos digitais: primeiro descobrir o que precisa ser feito, depois fazer. O Double Diamond, modelo de design criado pelo Design Council britânico, chama essa primeira fase de Discover. No desenvolvimento ágil, que é como a maioria das software houses trabalha hoje, o Discovery é a etapa que alimenta todo o resto.

Por isso, se você conversar com mais de uma empresa de desenvolvimento, vai ouvir o termo em quase todas. O nome se repete; o que muda é o quanto cada uma leva essa etapa a sério.

O que se decide no Discovery

Não é a cor do botão. São as regras do seu negócio que o produto vai ter de seguir, como:

• Quem pode cancelar um pedido, e até quando?
• Se o cliente cancela, o dinheiro volta inteiro, em parte ou vira crédito?
• O que acontece quando dois funcionários editam a mesma ficha ao mesmo tempo?
• Quem vê o quê: o gerente vê o caixa de todas as lojas ou só da dele?

Cada resposta dessas vira uma regra de negócio: uma frase curta e clara que o produto vai obedecer. Parece pouco, mas é o que separa um app que funciona no dia a dia de um app que trava no primeiro caso fora do comum.

Por que fazer antes, e não durante

Mudar uma regra numa conversa custa uma conversa. Mudar a mesma regra depois que as telas estão desenhadas e o programa está escrito custa refazer telas e programa. E, quando a regra só aparece depois do lançamento, quem descobre é o seu cliente.

O Discovery também é a hora de decisões que não dá para trocar no meio do caminho, como fazer um app para as lojas ou um site que se instala no celular (veja a diferença).

Como funciona na prática

Em geral, são reuniões curtas com quem conhece a operação por dentro — não só o dono, mas quem atende, quem vende, quem resolve o problema quando dá errado. A equipe pergunta, anota e devolve as regras por escrito para o cliente conferir.

Na Pump, o Discovery é dividido por partes do produto: cada parte ganha a sua reunião, e as regras dela ficam num documento no portal do cliente, organizadas por assunto. A equipe do cliente lê, comenta, sugere mudanças e aprova ali mesmo, sem precisar de outra reunião. Uma parte só passa para o desenho quando as regras dela estão aprovadas.

O que você leva no fim

• As regras do produto por escrito, aprovadas por você. É o combinado entre as duas partes: se algo funcionar diferente do que está ali, é correção, não pedido novo.
• As decisões tomadas, com o porquê de cada uma — útil quando alguém perguntar, daqui a um ano, "por que o sistema faz assim?".
• O que ficou para depois, separado do que entra agora, para o prazo e o preço continuarem de pé.

Onde o Discovery fica no projeto

Ele é uma etapa de uma sequência que se repete, com nomes parecidos, na maioria das empresas de desenvolvimento:

1. Proposta e contrato: o que vai ser feito, por quanto e em quanto tempo.
2. Kickoff: a reunião de começo, para conhecer as pessoas e combinar como vai ser o trabalho.
3. Discovery: as regras do negócio, por escrito.
4. Desenvolvimento: o produto sendo construído em ciclos curtos, de uma ou duas semanas, com entregas que dá para acompanhar.
5. Protótipo: as telas desenhadas para você aprovar antes de elas ganharem vida.
6. Homologação: você testa o produto pronto e confirma que ele faz o que foi combinado.
7. Lançamento: o produto no ar, com as contas e os acessos passados para o seu nome.
8. Sustentação: quem cuida do produto depois, para ele continuar funcionando e seguro.

A ordem do protótipo e do desenvolvimento varia: há quem desenhe tudo antes, e há quem construa primeiro a parte que não aparece — os cálculos, as regras e os dados — e desenhe as telas depois. O que não varia é o Discovery vir antes dos dois.

Sinal de alerta

Se a empresa responsável pelo desenvolvimento começa pelo desenho das telas sem perguntar como o seu negócio funciona, as regras vão ser decididas por quem programa, no meio do projeto, sem você. Na Pump, nenhuma tela é desenhada antes de as regras daquela parte estarem combinadas com o cliente.