Escrita de Spec e Repasse para Engenharia Sem Sangrar

Seu último spec tinha oito páginas. A engenharia abriu uma vez na segunda-feira, passou o olho pelos títulos e nunca mais abriu. Na quinta-feira, duas histórias estavam travadas porque ninguém sabia se a exportação deveria incluir registros arquivados. Na revisão do sprint seguinte, 40% do trabalho havia sido refeito. Você levou a culpa pelo spec inflado. A engenharia levou a culpa por não ler. Ninguém consertou o sistema.

Esse é o ciclo. Veja como quebrá-lo.

Por que seu último spec não foi lido

Já vi isso se repetir em três times no último ano. Cada um com um stack diferente, domínio diferente, mesmo padrão: o PM produz um spec longo, a engenharia produz um sprint longo, e a lacuna entre o que foi escrito e o que foi construído é preenchida com retrabalho.

O número de 40% de retrabalho não vem de uma pesquisa. É o que os times encontram quando realmente contam. Pegue os tickets do seu último sprint, marque cada história que mudou de escopo, ganhou um ticket de acompanhamento ou foi entregue com um bug conhecido que remete a "não sabíamos disso". Essa é a sua taxa de retrabalho. A maioria dos times que faz esse exercício honestamente chega a algo entre 30 e 50%.

O spec não causou isso sozinho. Mas o spec é o lugar mais barato para consertar. Código é caro de reescrever. Um doc é gratuito para reescrever, e um doc de 1 página é reescrito muito mais do que um de 8.

Aqui está o que estamos substituindo pelo romance.

O spec de 1 página

Sete seções. Cada uma justifica seu espaço. Se uma seção não está fazendo um trabalho real, não vai no doc.

# [Nome da Feature]

**Problema**
O que está quebrado ou faltando para o usuário. Uma frase. Usuário real, dor real. Não "os usuários não conseguem fazer X". Algo mais como "Os representantes de vendas não conseguem exportar o pipeline para compartilhar com o gestor antes dos 1:1s, então tiram screenshot e colam no Slack."

**Hipótese**
Se entregarmos [coisa], então [resultado] vai acontecer, porque [motivo]. Uma frase. É a aposta que estamos fazendo.

**Métrica de Sucesso**
O único número que diz que ganhamos. Não três. Um. Seja específico: "30% dos representantes de vendas que visualizam o pipeline usam a Exportação nos primeiros 14 dias após o lançamento." Adicione um indicador antecedente se o indicador defasado demorar muito para aparecer.

**Escopo**
O que está dentro. Lista de bullets, máximo de 7 itens. Cada bullet é algo que um usuário pode fazer ou ver.

**Anti-Escopo**
O que NÃO está dentro, mesmo que alguém vá pedir. Lista de bullets. Seja específico: "Templates de exportação personalizados, não está na v1. Exportações programadas, não está na v1. Reordenação de colunas do CSV, não está na v1." Essa é a seção que salva o seu sprint.

**Casos Extremos**
As cinco coisas que vão quebrar se não pensarmos nelas agora: estados vazios, erros, conjuntos de dados grandes, permissões, edições simultâneas. Liste os que se aplicam de verdade a essa feature.

**Perguntas em Aberto**
As decisões que ainda não temos resposta, com nomes vinculados. "A exportação inclui negócios arquivados?, @ravi a confirmar com sales ops até quarta."

Só isso. Uma página. O spec completo.

A killer feature é o anti-escopo. A maioria dos PMs o pula porque parece negativo ou porque acha que "obviamente não vamos fazer X". Para a engenharia nunca é óbvio. Para o design nunca é óbvio. Para a parte interessada que te manda mensagem na sexta-feira perguntando por que a feature favorita dela não está incluída nunca é óbvio. O anti-escopo é a seção para a qual você aponta quando alguém tenta expandir o trabalho no meio do sprint. Sem ele, você está argumentando de memória. Com ele, está apontando para uma linha que todo mundo assinou duas semanas atrás.

Já entreguei features sem anti-escopo e acabei reconstruindo o fluxo de exportação duas vezes, porque a primeira versão assumia dados sem filtro e a segunda foi retrofitada para lidar com filtros salvos. Dois engenheiros, três semanas. Tudo isso poderia ser evitado por uma seção de anti-escopo com 4 bullets que levaria 90 segundos para escrever.

A revisão de engenharia antes do spec (15 minutos)

O spec não vai direto do seu laptop para o Jira. Passa por uma revisão de engenharia de 15 minutos antes, e você leva um rascunho, não um doc finalizado.

A configuração:

• Quem: Tech lead, um engenheiro sênior, você. Só isso. Sem designer ainda. Sem colega PM. Sem gestor.
• Quando: Antes de ter mostrado o spec para qualquer outra pessoa. Antes de o design ter começado. Antes de as partes interessadas terem dado opinião.
• O que você leva: O spec de 1 página, marcado como RASCUNHO. As seções Problema e Hipótese estão firmes. Todo o resto é isca.
• O que você recebe: Uma lista de casos extremos que você não percebeu, uma ideia aproximada de esforço e um "essa abordagem está errada" antecipado, se for o caso.

A pauta, mantida em um post-it:

0 a 2 min:  Problema + hipótese (você fala)
2 a 8 min:  Engenharia encontra falhas no escopo e nos casos extremos
8 a 12 min: Engenharia levanta duas ou três direções de implementação
12 a 14 min: Perguntas em aberto, quem é dono de cada uma
14 a 15 min: "Estamos alinhados na direção?", sim / não / talvez

Se a resposta for "não" ou "talvez", você não escreve mais spec. Você volta para consertar o enquadramento do problema ou a abordagem. A maioria dos problemas de spec são problemas de enquadramento disfarçados.

Por que isso funciona: a engenharia revisando um spec pela metade dá o melhor pensamento antes de entrar em modo defensivo. Uma vez que o spec está "pronto", a revisão vira uma crítica ao seu trabalho. Quando é um rascunho, vocês estão co-criando. O mesmo engenheiro que teria escrito 12 comentários de demolição no Jira vai dizer "e se a gente simplesmente adicionasse uma flag ao endpoint de exportação existente?" e te poupar uma semana.

O doc de kickoff

Depois que o spec de 1 página passa pela revisão de engenharia e o design deu sua contribuição, você escreve o doc de kickoff. Esse é o que fica fixado no canal do time. É um contrato.

Quatro seções, cada uma curta:

Tabela RACI: um nome por papel

Um comitê não é responsável. Um nome é.

Se você não consegue preencher a linha de Prestador de contas com um único nome, o projeto não está pronto para começar.

Marcos com datas

Três ou quatro marcos. Datas reais. Não "fim do sprint".

• 14/mar: Design pronto, dev começa
• 21/mar: Endpoint de backend atrás de feature flag, teste interno em staging
• 28/mar: Beta com 10 clientes
• 4/abr: Dia de demo (não negociável)
• 11/abr: GA

Dia de demo: não negociável

Escolha uma data. Avise o time. Avise as partes interessadas. Diga a si mesmo que vai fazer a demo com o que existir nessa data, mesmo que não esteja polido.

Datas de demo que se movem não são datas de demo. São aspirações. Entregue o que tem. Se o que tem é metade de uma feature, faça a demo de metade de uma feature e explique o que falta. É assim que a confiança é construída. O time que faz demo a cada duas semanas, mesmo quando está bruto, sempre acaba mais rápido do que o time que faz demo quando está polido.

Critérios de encerramento

Essa é a seção que ninguém quer escrever e todo mundo precisa.

"Vamos parar de construir isso se: os clientes beta não usarem a exportação nos primeiros 7 dias após a ativação, OU a latência do backend ultrapassar 800ms no p95 com o nosso dataset de teste, OU mais de dois clientes relatarem problemas de precisão de dados durante o beta."

Três condições. Concretas. Mensuráveis. Acordadas com antecedência.

Sem critérios de encerramento, toda feature vive para sempre. Com eles, o time tem cobertura para encerrar. Encerrei duas features nos últimos 18 meses usando essa seção, e nos dois casos os engenheiros me agradeceram. Ninguém quer passar mais três semanas em algo que não está funcionando. Eles só precisam de permissão, por escrito, definida com antecedência.

Loom em vez de reunião (na maioria das vezes)

A reunião de repasse onde você caminha a engenharia pelo spec durante 30 minutos? Pule. Grave um Loom de 4 minutos.

O que vai no Loom:

1. O spec de 1 página na tela, você explicando em voz alta.
2. Dois fluxos de demo: o caminho feliz e um caso extremo.
3. As três coisas que você mais espera que sejam perguntas.
4. Uma frase no final: "Coloquem perguntas na thread, vou responder até o fim do dia."

O que isso te dá: a engenharia assiste a 1,5x de velocidade quando está pronta, não quando o seu calendário permite. As perguntas vão para uma thread, o que significa que todos veem a resposta uma vez em vez de você reexplicar a mesma coisa em três DMs no Slack. Engenheiros que entram no projeto duas semanas depois assistem ao mesmo Loom em vez de tirar alguém do foco.

Quando o Loom não funciona: quando o projeto é genuinamente ambíguo e o time precisa debater em voz alta. Quando a confiança está baixa e o assíncrono parece que o PM está se escondendo. Quando há decisões estratégicas reais que precisam de uma sala. Para esses casos, faça a reunião. Para todo o resto, Loom.

A definição de "pronto"

Critérios de aceitação escritos como "usuário consegue fazer login" não são critérios de aceitação. São desejos.

Use Dado / Quando / Então. Exemplos concretos, dados reais, estados reais.

Ruim:

Usuário consegue exportar o pipeline.

Bom:

Dado que sou um representante de vendas com acesso de visualização ao meu pipeline, E apliquei um filtro mostrando apenas negócios de minha propriedade com etapa = "Negociação", Quando clico em Exportar e seleciono CSV, Então um arquivo é baixado com o nome pipeline-2026-04-28.csv contendo exatamente os negócios visíveis após o filtro, com as colunas: Nome, Etapa, Valor, Data de Fechamento, Responsável.

Caso extremo (resultado vazio): Se o filtro retornar zero negócios, exibir uma notificação: "Nenhum negócio para exportar", sem baixar arquivo.

Caso extremo (conjunto de dados grande): Se o filtro retornar mais de 10.000 negócios, enfileirar a exportação e enviar o arquivo por e-mail quando estiver pronto. Exibir uma notificação: "Exportação enfileirada. Vamos enviar por e-mail em breve."

Isso é mais dois minutos de escrita. São três dias de discussões poupadas. O engenheiro de QA lê isso e escreve um teste. O engenheiro de backend lê e conhece o contrato do endpoint. A liderança de customer success lê e sabe o que dizer aos clientes beta. Um artefato, quatro trabalhos.

Não pule os casos extremos. O retrabalho mora nos casos extremos.

Template de retro pós-entrega

Vinte minutos. Cinco perguntas. Postado no canal do time no Slack dentro de uma semana do GA.

**[Nome da feature], Retro Pós-Entrega**

1. O que estava obscuro no spec?
   (Um bullet por pessoa, sem debate, só listando.)

2. O que deixamos passar no escopo: o que apareceu sem ter sido planejado?
   (Esforço, risco, dependência, qualquer coisa.)

3. Que retrabalho aconteceu e por quê?
   (Seja específico. "Reconstruímos a persistência do filtro duas vezes porque não decidimos entre URL vs. armazenamento local cedo o suficiente.")

4. Que caso extremo nos pegou de surpresa?
   (O que gostaríamos que já estivesse no spec desde o começo.)

5. O que entra no próximo spec?
   (Uma mudança concreta no template ou no processo.)

, Respostas na thread até sexta. Vou resumir e postar as mudanças no próximo spec na segunda.

O objetivo não é culpa. É evoluir o template. O próximo spec recebe uma melhoria. Depois o seguinte recebe outra. Seis meses depois, o processo de spec do seu time é materialmente melhor do que era no começo, e ninguém precisou sentar numa retro de 90 minutos para chegar lá.

Mantenho um arquivo chamado spec-improvements.md com um bullet por retro. Depois de um ano, ocupa duas telas. É o documento mais valioso que tenho.

Anti-padrões comuns para observar

Alguns padrões aparecem repetidamente. Nomeie-os em voz alta no momento em que os ver. Eles morrem quando nomeados.

• O repasse "o design jogou por cima do muro". O design termina, posta um link do Figma no spec e some. A engenharia encontra uma interação que os mocks não cobrem, pergunta ao design e recebe "use seu julgamento". Três dias depois, entrega errado. Solução: o design entra no kickoff. A linha RACI deles é "Consultado" com um nome vinculado. Eles estão disponíveis para perguntas de interação durante o primeiro sprint.

• O spec que cresce durante o sprint. Uma parte interessada te manda mensagem na terça. "Ei, podemos também adicionar X nessa versão?" Você diz sim porque dizer não parece político. Na sexta-feira o time está atrasado. Solução: anti-escopo. Aponte para ele. "X está na v2. Já registrei." Feito.

• O anti-escopo ausente. A engenharia constrói a feature e então pergunta "e quanto aos registros arquivados?" Você diz "boa pergunta, vamos adicionar isso". Isso é o anti-escopo vazando de volta como uma pergunta cavalo de Troia. Solução: o anti-escopo está no spec desde o primeiro dia. Qualquer coisa que não está na lista de escopo está, por padrão, fora.

• A surpresa no dia de demo. O dia de demo chega. O PM não viu o build desde segunda-feira. Metade dos fluxos não funciona como o spec dizia. As partes interessadas saem confusas. Solução: o PM faz uma revisão privada com o líder de engenharia 24 horas antes do dia de demo. As discrepâncias são identificadas quando ainda podem ser corrigidas.

Conclusão

Um spec é um contrato, não um ensaio.

O spec de 1 página é curto porque specs curtos são lidos. A revisão de engenharia antes do spec dura 15 minutos porque qualquer coisa mais longa vira uma reunião que ninguém quer. O doc de kickoff tem um nome por papel porque comitês não podem prestar contas. O Loom substitui a apresentação porque a escrita assíncrona escala e as agendas de reunião não escalam. Dado/Quando/Então existe porque "usuário consegue fazer login" já entregou mil logins quebrados.

Anti-escopo e critérios de encerramento são as duas seções que a maioria dos PMs pula e mais lamenta ter pulado. Não pule. São o seguro mais barato que você vai comprar.

Mais curto, mais preciso, assinado por todos. Esse é o jogo todo.

Saiba Mais

• Descrição de Cargo de Product Manager
• Como Conduzir o Sprint Planning Sem Arrastar
• Comunicação de Roadmap para Times Multifuncionais
• Trabalhando com Design: Repasse entre PM e Designer