Por que discovery vem antes do código

Imagine a cena: um cliente chega com uma ideia brilhante de um novo app que ele diz que será um sucesso. Ele fala todo empolgado sobre o software que pretende lançar, mas ao ser questionado sobre alguns pontos um pouco fora do conhecimento comum, percebemos que ele não tem muita clareza sobre o que exatamente precisa ser construído. Isso não é falha dele — afinal, não é papel dele saber. Isso fica com quem desenvolve, e é papel de um estúdio de software perguntar antes que qualquer linha de código seja escrita. E é aí que entra um termo comum em empresas de software, mas desconhecido para muitas pessoas, que é o “discovery de produto”.

O que discovery resolve, na prática

Discovery não é burocracia nem uma etapa decorativa antes do “trabalho de verdade”. É o momento em que escopo ambíguo vira decisão escrita: quais fluxos existem, quais dados entram e saem do sistema, o que é obrigatório na primeira entrega e o que pode esperar.

Sem isso, cada decisão de arquitetura é um palpite. E palpite errado na primeira semana custa muito mais pra corrigir do que na semana 10 do projeto, quando já tem código, dado real e usuário em cima.

O custo de corrigir um problema de escopo cresce conforme o projeto avança — baixo no discovery, alto depois que já existe código, dado real e usuário em produção.

Marty Cagan, da Silicon Valley Product Group e autor de INSPIRED, descreve discovery como o que separa times que validam uma ideia antes de construir dos que só constroem e torcem para dar certo. Teresa Torres, autora de Continuous Discovery Habits, defende levar essa disciplina adiante — não como um evento único no início do projeto, mas como hábito contínuo ao longo de todo o produto. Aplicamos a mesma lógica no começo de cada projeto: validar antes de comprometer tempo de desenvolvimento.

O custo real de pular essa etapa

O problema de pular discovery não aparece logo. Aparece depois, como retrabalho:

• Uma funcionalidade construída do jeito errado, porque ninguém perguntou como o processo realmente funciona no dia a dia do cliente
• Uma arquitetura que não aguenta um caso de uso que só foi mencionado na segunda reunião
• Um prazo que parecia razoável e vira impossível quando o escopo real aparece no meio do projeto

Esse custo não é hipotético, é o motivo mais comum de projeto de software atrasar ou sair do orçamento. E quase sempre a raiz é a mesma: alguém começou a codar antes de entender o problema por completo.

Um exemplo na prática

Pensa num cenário comum: um cliente pede um sistema pra gerenciar agendamentos. O escopo parece direto: cadastrar horário, profissional, cliente. Mas antes de qualquer código, perguntas básicas revelam que a empresa tem duas unidades com agendas independentes, que às vezes compartilham o mesmo profissional entre as duas: um detalhe óbvio pra quem trabalha lá todo dia, mas que nunca tinha sido mencionado porque ninguém pensou que fosse relevante dizer.

Descoberto na primeira semana, isso é um ajuste no desenho do banco de dados. Descoberto na décima, com agenda, profissional e cliente já modelados como entidades fixas de uma única unidade, é reconstruir a base inteira.

Como isso funciona

Antes de qualquer código, a etapa de discovery produz um documento objetivo: escopo da primeira entrega, fluxos principais, decisões técnicas que já podem ser tomadas e perguntas que ainda precisam de resposta do cliente. Esse documento não é formalidade, é o que orienta cada decisão de arquitetura depois.

Isso significa um pouco mais de tempo antes de começar a programar. Na prática, é tempo que se paga sozinho: menos retrabalho, menos decisão revertida, menos reunião de “isso não era bem o que eu queria”.

Ninguém faz discovery por desconfiança. Faz porque corrigir um sistema construído em cima do problema errado custa muito mais do que ter gasto uma semana a mais entendendo o problema certo.

É por isso que, quando um cliente chega assim, empolgado, com a ideia pronta mas sem saber ainda o que precisa ser construído, a primeira coisa que fazemos não é abrir o editor de código. É fazer as perguntas certas.