Discovery, documentação e critérios de aceite: quando um simples DE/PARA deixa de ser simples

Nos últimos meses eu tenho trabalhado em um produto que, no começo, parecia simples de explicar.

Em teoria, era quase um DE/PARA.

Você recebe uma informação de um lado, entende como ela deve ser representada do outro e cria a ponte entre os dois mundos.

Parece o tipo de projeto que você desenha em uma reunião, quebra em algumas tarefas e começa a desenvolver.

Na prática, foi justamente o contrário.

Quanto mais a gente avançava, mais apareciam exceções, dependências, interpretações diferentes e cenários que ninguém tinha colocado na mesa no começo.

E foi aí que uma coisa ficou muito clara para mim:

o que salvou o projeto não foi acertar tudo de primeira. Foi ter uma metodologia boa o suficiente para descobrir rápido quando não estávamos acertando.

O problema quase nunca está no DE/PARA

Quando alguém descreve um produto como um DE/PARA, normalmente está olhando para o fluxo feliz.

Campo A vira campo B.

Status X vira status Y.

Regra 1 produz resultado 2.

Só que produto real raramente vive apenas no fluxo feliz.

Começam a aparecer perguntas:

• e se esse campo vier vazio?
• e se dois sistemas tratarem o mesmo status de formas diferentes?
• quem é a fonte da verdade?
• o que acontece com dados antigos?
• existe alguma exceção comercial?
• o usuário pode corrigir isso?
• precisamos guardar histórico?
• o comportamento é o mesmo para todos os perfis?
• o que acontece quando uma integração falha no meio?

Nenhuma dessas perguntas muda a ideia original do produto.

Mas cada uma delas pode mudar completamente a implementação.

Foi aí que comecei a perceber que uma discovery boa não serve apenas para descobrir o que construir.

Ela serve principalmente para descobrir onde estão as interpretações diferentes antes que elas virem código.

Discovery não é uma reunião antes do desenvolvimento

Eu costumava pensar em discovery como uma etapa relativamente bem definida.

Você conversa com as pessoas certas, entende o problema, documenta, fecha um escopo e entra em delivery.

Hoje vejo de uma forma um pouco diferente.

Em produtos que dependem de regras de negócio, integrações e vários stakeholders, a discovery continua acontecendo durante o desenvolvimento.

A primeira discovery cria um modelo do problema.

O desenvolvimento começa a testar esse modelo contra a realidade.

E, inevitavelmente, aparecem situações que não estavam previstas.

A diferença entre um projeto saudável e um projeto caótico é o que acontece depois disso.

Quando surge uma dúvida, ela vira uma conversa objetiva.

A conversa vira uma decisão.

A decisão vira documentação.

E a documentação vira comportamento esperado.

Esse ciclo parece burocrático quando escrito dessa forma.

Na prática, ele evita uma quantidade enorme de retrabalho.

Documentação boa não é documentação grande

Outra coisa que esse projeto reforçou para mim é que quantidade de documentação não significa qualidade.

Você pode ter uma página enorme explicando um produto e, ainda assim, deixar o desenvolvedor sem saber o que deve acontecer em um cenário específico.

Para mim, uma documentação começa a ficar realmente útil quando ela consegue responder três coisas:

o que acontece, por que acontece e como sabemos que aconteceu corretamente.

O primeiro ponto explica o comportamento.

O segundo preserva o contexto da decisão.

O terceiro começa a nos levar para uma das partes mais importantes do processo: os critérios de aceite.

Critério de aceite é onde a abstração acaba

"Precisamos sincronizar esses dados."

"Esse status deve aparecer na nova tela."

"O sistema precisa fazer o DE/PARA."

Tudo isso pode estar correto e ainda ser insuficiente para desenvolver qualquer coisa.

O critério de aceite força a conversa a sair da intenção e chegar no comportamento observável.

Se o dado não existir, o que aparece?

Se a integração estiver fora, o usuário vê erro ou tentamos novamente?

Se existirem duas informações conflitantes, qual prevalece?

Depois de salvar, em quanto tempo o outro sistema precisa refletir a mudança?

Quem pode executar essa ação?

O que não pode acontecer?

Para mim, esse é um dos maiores valores de escrever bons critérios de aceite:

eles expõem ambiguidades.

Às vezes você começa escrevendo um critério achando que a regra está completamente entendida e percebe, no meio da frase, que ainda existe uma decisão de produto escondida ali.

É muito melhor descobrir essa dúvida escrevendo uma task do que depois de alguém já ter implementado metade da solução.

O critério de aceite também melhora a conversa

Uma coisa interessante é que critérios de aceite não ajudam apenas quem desenvolve.

Eles melhoram a conversa com stakeholders.

É muito mais fácil validar:

"Se acontecer X, o sistema faz Y. Se acontecer Z, fazemos W. Está correto?"

do que perguntar:

"O fluxo está certo?"

A segunda pergunta quase sempre recebe um "sim".

A primeira obriga todo mundo a olhar para o mesmo cenário.

Isso reduz aquela situação clássica em que produto, negócio e engenharia saem da mesma reunião acreditando que concordaram — mas cada pessoa entendeu uma solução diferente.

Assertividade não significa ter todas as respostas

Nesse projeto também comecei a separar melhor duas coisas que parecem iguais: confiança e certeza.

Como Product Owner, eu não preciso chegar em uma conversa sabendo todas as regras.

Mas preciso saber qual dúvida estou tentando resolver.

Existe uma diferença enorme entre reunir cinco pessoas e dizer:

"Precisamos entender melhor esse fluxo."

e chegar dizendo:

"Temos três interpretações possíveis para este cenário. A implementação está bloqueada porque não sabemos qual sistema é a fonte da verdade. Precisamos sair daqui com essa decisão."

A segunda conversa normalmente é muito mais curta.

E muito mais útil.

Essa assertividade não vem de saber tudo.

Ela vem de fazer o trabalho antes da reunião: entender onde está a lacuna, reunir evidências, desenhar os cenários e transformar uma discussão ampla em uma decisão específica.

O time também faz discovery

Outro aprendizado importante foi parar de tratar discovery como uma responsabilidade exclusiva de produto.

Desenvolvedor encontra regra escondida.

QA encontra cenário que ninguém considerou.

Stakeholder percebe uma exceção quando vê o comportamento funcionando.

Alguém de negócio lembra que existe um processo manual acontecendo fora do sistema.

Tudo isso é discovery.

Se o time sente que pode levantar essas dúvidas cedo, o produto melhora.

Se o ambiente trata qualquer mudança de entendimento como "mudança de escopo" ou erro de planejamento, as pessoas começam a esconder dúvidas e simplesmente implementar a interpretação que parece mais provável.

Aí o problema só aparece mais tarde — e mais caro.

A documentação vira memória do projeto

Conforme mais decisões começaram a surgir, a documentação passou a ter outra função importante: evitar que a equipe precisasse rediscutir a mesma coisa.

Uma decisão tomada apenas em reunião desaparece rápido.

Depois de algumas semanas alguém pergunta:

"Por que fizemos assim?"

E começa uma nova discussão.

Quando a decisão está registrada junto do contexto e dos critérios de aceite, ela vira memória do produto.

Isso não significa que a decisão nunca possa mudar.

Significa que, se mudar, sabemos o que estamos mudando e por quê.

Essa diferença parece pequena, mas em projetos longos ela é enorme.

O melhor processo não elimina surpresa

Mesmo fazendo tudo isso, continuamos encontrando desafios no meio do caminho.

E acho que essa é a parte mais importante.

Uma discovery bem feita não promete que nenhuma surpresa vai aparecer.

Uma documentação boa não prevê todos os casos do futuro.

Critérios de aceite não tornam requisitos imutáveis.

O que essas ferramentas fazem é tornar a equipe mais preparada para absorver a surpresa sem perder o controle do produto.

Quando aparece uma nova regra, conseguimos entender onde ela impacta.

Quando um stakeholder traz uma exceção, conseguimos confrontar com o comportamento que estava combinado.

Quando o desenvolvedor encontra uma inconsistência, existe um espaço claro para transformar aquilo em decisão.

Metodologia, nesse caso, não serviu para burocratizar o trabalho.

Serviu para manter todo mundo olhando para a mesma versão da realidade.

O que eu passei a considerar uma boa entrega de produto

Hoje, antes de considerar uma demanda realmente pronta para desenvolvimento, tento garantir pelo menos quatro coisas:

1. O problema está entendido. Não apenas a solução pedida.
2. Os fluxos principais e as exceções mais relevantes estão explícitos.
3. As decisões importantes têm contexto registrado.
4. Os critérios de aceite permitem que qualquer pessoa do time diga objetivamente se aquilo está funcionando ou não.

Nem sempre conseguimos chegar a 100%.

Aliás, provavelmente nunca chegamos.

Mas a diferença entre começar com 40% de entendimento e começar com 80% aparece muito rápido no delivery.

No fim, o trabalho é criar entendimento compartilhado

Eu comecei esse projeto pensando que grande parte do desafio seria organizar um DE/PARA.

Hoje acho que essa era a parte fácil.

A parte difícil é fazer pessoas com contextos diferentes — produto, engenharia, negócio e stakeholders — construírem a mesma imagem mental do que o sistema precisa fazer.

Discovery ajuda a construir essa imagem.

Documentação impede que ela desapareça.

Critérios de aceite transformam essa imagem em algo verificável.

E conversas assertivas corrigem o caminho sempre que a realidade mostra que nosso modelo estava incompleto.

Talvez essa seja a parte que mais tenho aprendido trabalhando com produto:

muitas vezes, o principal entregável de um PO antes do software não é uma especificação. É alinhamento.

O código vem depois.