Escrever uma especificação que o time realmente lê

O que entra e o que não entra

Uma especificação que descreve cada pixel vira um documento que ninguém atualiza depois de duas semanas. Uma que descreve só uma visão gera vinte perguntas por dia. O ponto do meio: para cada capacidade, quem usa, o que acontece no caminho normal, o que acontece quando algo falha, e a condição para dizer que está pronto.

Os critérios de aceite economizam a maior parte das discussões. “O usuário recebe um aviso em até um minuto” é critério; “o processo será rápido” é desejo.

Descreva fluxos, não telas

Descreva o fluxo como sequência: estado inicial, ação, resultado. Depois escreva os caminhos de falha — sem conexão, o usuário fechou no meio, o arquivo está corrompido, permissão negada. Em projetos reais, os caminhos de falha são metade do trabalho e um quarto da especificação.

Telas são redesenhadas; fluxos permanecem. Por isso o design é linkado a partir da especificação, e não embutido nela.

A parte que todo mundo pula

Escreva explicitamente o que está fora do escopo desta versão. Uma lista de “agora não” é ferramenta de gestão, não desculpa: permite dizer “isso mesmo, e vem depois” em vez de rediscutir em toda reunião.

Acrescente as premissas em que você se apoia. Premissa escrita é risco gerenciado; premissa que ficou na cabeça é surpresa.