Jonathan Machado
O momento mais caro de um projeto de software não é quando o código quebra. É quando o código funciona perfeitamente e entrega a coisa errada.
Isso acontece porque alguém descreveu uma solução antes de fechar qual problema estava resolvendo. O time construiu com competência, o resultado passou nos testes, e na primeira semana de uso ficou claro que ninguém tinha combinado o que "pronto" significava.
O PRD existe para matar esse momento. E a parte dele que mais evita retrabalho é justamente a que quase ninguém escreve.
O que é um PRD, em uma frase
PRD é a sigla de Product Requirements Document, ou Documento de Requisitos de Produto. É o documento que define qual problema um sistema, aplicativo ou funcionalidade precisa resolver, para quem, sob quais restrições e com qual critério de aceite, antes de existir uma linha de código.
A definição é fácil. O uso é o que separa um PRD de uma lista de desejos.
O erro que transforma PRD em lista de desejos
PRDs ruins têm quase sempre o mesmo defeito: descrevem a tela em vez de descrever a dor.
"Adicionar um botão de exportar CSV no canto superior direito da listagem" não é requisito. É palpite de solução disfarçado de requisito. Ele fecha a porta para qualquer alternativa melhor e não dá ao time nenhuma forma de saber se resolveu alguma coisa.
O requisito equivalente seria: "o gestor precisa levar os dados da listagem para a planilha onde ele fecha o mês, sem redigitar. Hoje ele copia célula por célula e leva cerca de 40 minutos por fechamento." Agora o time sabe o que está em jogo, tem espaço para propor a exportação, uma integração ou um relatório pronto, e tem um número para medir depois.
A régua prática: se o seu requisito não sobrevive à pergunta "e se existisse uma forma melhor de fazer isso?", ele é solução, não requisito.
Isso vale mesmo quando você é o dono e o executor ao mesmo tempo. Escrever o problema em vez da tela é o que permite testar rápido e refinar depois sem perder o alvo no caminho.
As 11 seções de um PRD que aguenta execução
Existe muita variação de template por aí. O que importa não é a quantidade de seções, é quais perguntas o documento fecha. Este é o formato que usamos na eBuz, e cada linha existe porque a ausência dela já custou tempo em algum projeto:
| # | Seção | A pergunta que ela fecha |
| 1 | Contexto e motivação | Por que agora? O que mudou para isso virar prioridade? |
| 2 | Estado atual | O que existe hoje, medido e verificado, não suposto |
| 3 | Estado desejado | Como o mundo fica depois, em termos observáveis |
| 4 | Decisões de design | O que foi escolhido, e o que foi descartado com qual motivo |
| 5 | Plano de execução faseado | Em que ordem, em que tamanho de passo |
| 6 | Matriz de risco | O que pode dar errado e qual a resposta a cada caso |
| 7 | Plano de rollback | Como voltar atrás, em quanto tempo, com qual comando |
| 8 | Métricas de sucesso | Qual número diz que funcionou |
| 9 | O que este PRD NÃO faz | Onde o escopo termina |
| 10 | Pré-requisitos | O que precisa estar de pé antes de começar |
| 11 | Documentos relacionados | Onde está o resto do contexto |
Um PRD pequeno pode viver com as seções 1, 2, 3, 8 e 9. Nenhum PRD deveria viver sem a 2 e sem a 9.
Por que a seção 2 (estado atual) paga o documento inteiro
Auditar o estado antes de especificar parece burocracia até a primeira vez que a auditoria contradiz o pedido.
Exemplo real, deste blog. O pedido era curto: "padronizar as capas dos artigos". Antes de escrever qualquer requisito, medimos o estado. A auditoria achou 30 capas apontando para um bucket de armazenamento que havia sido deletado (todas retornando erro), 53 posts sem capa nenhuma caindo num fallback que sorteava um ideograma japonês sem relação com o texto, 30 endereços canônicos apontando para um domínio já desativado e 83 artigos fora de qualquer filtro de categoria.
Nada disso estava no pedido. Tudo isso teria continuado quebrado se a especificação tivesse começado pela solução ("gerar capas novas") em vez de começar pela medição.
A seção 2 é o que transforma um pedido em escopo.
A seção que quase ninguém escreve: "o que este PRD NÃO faz"
É a seção 9, e é a mais barata de escrever e a mais cara de omitir.
Um PRD sem não-objetivos declarados é um convite permanente ao aumento de escopo. Toda conversa seguinte carrega a pergunta implícita "mas já que estamos mexendo aqui...". Com os não-objetivos escritos, a resposta deixa de ser negociação e passa a ser consulta: está no documento ou não está.
Um exemplo de não-objetivos bem escritos:
- Este PRD não altera o sistema de autenticação, mesmo que ele apareça no caminho.
- Este PRD não faz migração de dados históricos. Só o fluxo novo.
- Este PRD não cobre o aplicativo móvel. Só web.
- Este PRD não resolve a lentidão da listagem. Isso tem documento próprio.
Repare que cada linha nomeia uma tentação concreta e a desarma. "Não vamos fazer nada além do combinado" não é um não-objetivo, é uma frase de efeito.
Métricas de sucesso: o teste que separa requisito de opinião
Se a seção 8 não tem número, o projeto não tem critério de aceite. E sem critério de aceite, "pronto" é opinião de quem fala mais alto na reunião.
Métrica ruim: "melhorar a experiência do usuário". Métrica utilizável: "o fechamento mensal que hoje leva 40 minutos passa a levar menos de 5, medido no relógio, com o mesmo gestor e o mesmo volume de dados".
Vale a mesma lógica da regra dos 3 números: poucos indicadores, escolhidos antes, olhados sempre. Métrica definida depois da entrega vira justificativa, não medição.
Como saber se o seu PRD está pronto
Seis perguntas. Se alguma não tem resposta escrita no documento, ele não está pronto:
- Qual problema, na voz de quem sofre com ele?
- Como está hoje, medido e não suposto?
- Qual número diz que resolveu?
- O que explicitamente fica de fora?
- Como voltamos atrás se der errado?
- O que precisa existir antes de a primeira linha ser escrita?
Um PRD que responde essas seis perguntas em uma página vale mais que um de trinta páginas que responde quatro.
PRD, SDD e ADR: quem responde o quê
Os três documentos são confundidos com frequência porque todos aparecem antes do código. A divisão de trabalho é simples:
| Documento | Pergunta que responde | Dono natural |
| PRD | Que problema vamos resolver, e como sabemos que resolvemos | Quem é dono do produto |
| SDD | Como vamos construir, em que ordem, com qual gate por fase | Quem vai executar |
| ADR | Por que escolhemos este caminho e descartamos os outros | Quem decidiu, para o futuro entender |
Na prática o PRD entra primeiro e trava o "o quê". O SDD entra depois e trava o "como", e é ele que ganhou peso novo agora que ferramentas de IA escrevem código a partir de especificação. O ADR é o registro que impede a mesma discussão de voltar em seis meses.
Confundir os três gera o pior dos mundos: um documento longo que descreve implementação sem nunca fechar o problema, e que ninguém consegue usar como critério de aceite.
O PRD não é papel. É o momento em que o escopo para de negociar
Todo projeto tem uma conversa em que o escopo é decidido. A única escolha real é se ela acontece antes da construção, num documento que dá cinco minutos para revisar, ou depois, numa reunião em que já existe código feito para jogar fora.
Escreva o problema, meça o estado atual, declare o que fica de fora e defina o número que encerra a discussão. As outras sete seções são conforto. Essas quatro são o documento.
Se você usa IA para acelerar a execução, o passo seguinte é o que transforma esse documento em código: veja como funciona o Spec-Driven Development e por que a especificação virou o gargalo. Para as ferramentas que sustentam esse fluxo no dia a dia, o stack completo da eBuz mostra as 31 peças e a ordem certa de ligar cada uma.
