Este detalhe evita discussões no fim

A maioria das discussões na conclusão do projeto não nasce no último dia. Nasce semanas antes, quando toda a gente assume que “está feito” - mas ninguém alinhou, por escrito, os critérios de aceitação e o que conta mesmo como “entregue”. Em equipas de produto, agências, consultoria ou TI, esse detalhe parece burocracia até ao momento em que aparece um “só falta mais uma coisinha”.

O fim de um projeto é emocional: há cansaço, há pressão de prazos, há expectativas acumuladas. E é precisamente por isso que um acordo simples, claro e verificável vale mais do que mais uma reunião.

O detalhe que evita o “mas eu pensei que…”

Em quase todos os conflitos de fecho há uma frase repetida, dita com boa fé e zero utilidade: “eu pensei que isso estava incluído”. O problema não é a intenção. É a ausência de um “teste” comum que diga se a entrega passou ou falhou.

Os critérios de aceitação servem para isso: transformar perceções em verificação. Se não dá para confirmar, medir, observar ou validar, então é um desejo - e desejos mudam quando o trabalho já está feito.

Um projeto não termina quando alguém diz “está bom”. Termina quando cumpre o que foi acordado que “bom” significa.

Porque é que isto estoura no fim (e não no início)

No arranque, as pessoas têm tempo e paciência para discutir detalhes. No meio, já há trabalho a acontecer e muita coisa resolve-se “logo se vê”. No fim, qualquer “logo se vê” volta em forma de fatura emocional: retrabalho, atrasos, e-mails longos, e aquela sensação de injustiça dos dois lados.

Há também um fator silencioso: a memória seletiva. Depois de meses, cada pessoa lembra-se mais do que defendeu do que do que ficou decidido. Sem uma referência objetiva, ganha quem argumenta melhor - não quem tem razão.

Os sinais de que a aceitação está a caminho do desastre

• Feedback tardio do cliente ou do stakeholder (“só agora tive tempo de ver”).
• Revisões vagas (“falta polir”, “ainda não está com o feeling certo”).
• Testes feitos com “uso normal” em vez de cenários definidos.
• Dependências externas não fechadas (“quando o fornecedor responder, ajustamos”).

Se reconhece dois ou mais pontos, o seu problema não é a execução. É o fecho sem régua.

Critérios de aceitação que funcionam: simples, observáveis, fechados

Os melhores critérios parecem pouco glamorosos. São curtos, chatos e concretos. E, por isso mesmo, protegem relações.

Em vez de “página rápida”, prefira:

• “A página carrega em menos de 2,5s em 4G num dispositivo médio (definir qual), medido com (definir ferramenta)”.

Em vez de “layout como no Figma”, prefira:

• “Aplicar o design da versão X do Figma (link), com tolerância de 8px em espaçamentos; fonte Y; e comportamento definido para mobile (breakpoint Z)”.

Em vez de “integração feita”, prefira:

• “Criar pedido no endpoint /orders, guardar no sistema A, e devolver confirmação com ID; testar com payload de exemplo (anexo)”.

A regra é desconfortável, mas clara: se não consegue escrever o critério sem adjetivos, ainda não está pronto.

Um modelo rápido para escrever bons critérios

Use este formato e repita, sem vergonha, para cada entrega relevante:

• Dado que (contexto),
• quando (ação),
• então (resultado esperado),
• e (como se valida / evidência).

Exemplo: “Dado que o utilizador está autenticado, quando altera a palavra-passe, então recebe e-mail de confirmação, e validamos pelo registo no log + e-mail recebido em ambiente de testes.”

O momento certo para fechar isto (e não é na entrega)

O melhor momento para fixar critérios de aceitação é antes de começar a construir. O segundo melhor é assim que percebe que há interpretações diferentes - mesmo que já esteja “quase pronto”.

Uma boa prática é fazer um mini-checkpoint a meio, de 20 minutos, só para responder a três perguntas:

1. O que vai ser avaliado no fim?
2. Quem dá a validação final?
3. Que evidências vão provar que passou?

Se essas respostas não cabem num parágrafo, o fecho vai doer.

Como usar este detalhe para evitar discussões - na prática

Não precisa de criar um manual. Precisa de criar um hábito. Eis uma sequência simples que funciona em projetos pequenos e grandes:

• Antes de iniciar: listar 5–10 critérios de aceitação por entregável (não por tarefa).
• Durante: a cada alteração de scope, atualizar critérios e pedir confirmação explícita (“ok” escrito).
• Antes da entrega: fazer uma pré-validação interna usando exatamente os critérios acordados.
• No dia do fecho: reunir evidências (prints, links, logs, resultados de teste) e anexar ao e-mail ou ao ticket de entrega.

Isto muda o tom da conversa. Em vez de “gostam?” passa a “cumpre o que acordámos?”. E isso é muito mais fácil de gerir quando há cansaço.

O fecho fica mais leve quando a régua é comum

Há projetos que acabam com champanhe e outros que acabam com silêncios estranhos. A diferença raramente está no talento da equipa. Está na clareza do fim.

Quando os critérios de aceitação estão definidos, a conclusão do projeto deixa de ser um debate sobre expectativas. Passa a ser uma verificação honesta do que foi prometido - e, se faltar algo, uma decisão consciente sobre custo, prazo e prioridade, em vez de uma guerra de perceções.

Checklist final (curto e eficaz)

• Critérios escritos e linkados numa fonte única (ticket, contrato, documento).
• Responsável pela aceitação identificado (uma pessoa, não “a equipa”).
• Evidências preparadas antes da reunião final.
• Regra para “extras” definida: novo pedido = novo prazo/novo custo ou backlog.

FAQ:

• Como é que eu imponho critérios de aceitação sem parecer rígido? Apresente-os como proteção mútua: evitam retrabalho, reduzem mal-entendidos e tornam o fecho mais rápido. A rigidez está no tom, não na clareza.
• Quantos critérios de aceitação devo ter? O suficiente para validar o essencial sem cobrir exceções infinitas. Em muitos casos, 5–10 por entregável grande e 2–5 por funcionalidade pequena chegam.
• E se o cliente só consegue dar feedback “de feeling”? Converta “feeling” em sinais observáveis: exemplos, referências, casos de uso e comparações (“mais parecido com X do que com Y”). Se continuar vago, aceite que não é critério - é direção criativa, e deve ser tratada como iteração.
• O que faço quando os critérios mudam a meio? Registe a alteração, confirme por escrito e renegocie impacto (prazo, custo ou scope). Sem isso, a mudança entra pela porta do “só mais isto” e sai como conflito no fecho.