Pegue as lacunas do seu PRD antes dos revisores

A maioria dos PRDs sai depois de uma única leitura de quem os escreveu. Isso pega erros de digitação, mas raramente pega a lacuna que faz a mesma pergunta de esclarecimento aparecer nos comentários de todo documento que você envia, porque você já sabe a resposta e passa direto por onde ela falta. Um PM que carregou o contexto de uma funcionalidade na cabeça por duas semanas lê um PRD sobre ela de modo completamente diferente de um engenheiro que abre o documento a frio pela primeira vez.

O PRD que sobrevive à sua própria leitura é o que você está menos qualificado para julgar.

Por que a mesma pergunta continua aparecendo na revisão

Você escreveu o documento com todo o contexto já na cabeça, então uma lacuna nos requisitos não lhe parece uma lacuna, parece óbvia. O revisor não tem esse contexto, então o mesmo tipo de pergunta, um caso de borda não tratado, uma suposição não dita, ressurge documento após documento. Se três dos seus últimos cinco PRDs receberam o mesmo comentário perguntando como a funcionalidade deve se comportar para um tipo específico de usuário, isso não é azar, é um padrão em como você escreve o escopo.

Pense num PRD de uma funcionalidade de exportação em massa que especifica exatamente o que acontece para um usuário padrão exportando até 10.000 linhas. Ele não diz o que acontece com 100.000 linhas, nem para um usuário de um plano gratuito com limites de exportação, porque o autor pensava no caso comum o tempo todo em que escrevia. Um engenheiro que pega o documento não tem como inferir essas respostas, e a discussão de comentários resultante, “o que acontece acima do limite de linhas?”, é a mesma pergunta que teria surgido nos últimos três PRDs também, se alguém tivesse pensado em conferir.

Antes: escrever o PRD, ler uma vez, decidir que está claro, enviar para revisão.

Depois: entregá-lo ao Claude com o contexto real da funcionalidade, perguntar especificamente se o escopo está claro e que casos de borda faltam e corrigir o que ele achar antes que um revisor precise perguntar.

Um processo para testar um PRD antes da revisão

Para uma funcionalidade com uma restrição técnica específica que você já conhece, um limite de requisições, um teto de tamanho de dados, uma fronteira de permissões, vale contá-la diretamente ao Claude para que a checagem de casos de borda se baseie no sistema real e não em palpites genéricos.

Quando as lacunas continuam vindo da mesma seção

Se os casos de borda continuam surgindo na mesma parte dos seus PRDs, vale notar isso como um padrão, e não consertar do zero toda vez. Uma lacuna recorrente, digamos, na seção de permissões geralmente significa que essa seção precisa de um checklist permanente, não de mais uma revisão pontual. Consertar a mesma categoria de lacuna três vezes separadas é sinal de que o hábito de fundo precisa mudar, não só o documento atual.

Depois que um checklist assim existe, vale rodar a seção relevante de todo PRD novo contra ele antes da primeira revisão, em vez de depender da memória para pegar a mesma lacuna recorrente toda vez.

Continue lendo

• Escrevendo um PRD a partir de um pedido de funcionalidade de uma linha: acertar a estrutura desde o início, antes da passada de revisão e correção que este artigo cobre.
• Transformando chamados de suporte em temas priorizados: de onde costumam vir, em primeiro lugar, os casos de borda que um PRD precisa cobrir.
• Primeiros passos com o Claude: os hábitos de base, contexto, iteração, especificidade, sobre os quais todo este processo se apoia.