Ideia principal

Uma parte dos defeitos não vem do código, mas do que veio antes dele: uma especificação incompleta, uma decisão de produto ambígua, um caso-limite nunca considerado, um fluxo mal compreendido. A constatação costuma servir para inocentar — "não é um bug, a spec estava vaga". Na verdade, ela leva a outro lugar.

Se o enquadramento não está claro o bastante para entregar direito, quem precisa entregar pode dizer isso e parar. Recusar não é travar: é devolver o pedido para uma clarificação — o comportamento esperado, os casos-limite, os critérios de aceitação, os dados, as dependências, os riscos. Perguntar antes de programar custa uma conversa; programar no escuro custa uma funcionalidade capenga, depois defeitos, suporte, retrabalho e arbitragens para refazer.

O fundamento é simples: não dá para garantir a qualidade daquilo que não se entende. Um desenvolvedor que executa um pedido ambíguo resolve as ambiguidades sozinho, sem dizer, e muitas vezes sem saber.

Por que isso importa

Isso transforma uma reclamação recorrente num direito acompanhado de um dever. Enquanto a especificação vaga for apenas uma queixa, ela produz defeitos que depois são imputados a quem não fez a pergunta.

Isso também precisa onde se encontram a responsabilidade de produto e a responsabilidade técnica: cabe ao produto clarificar sua escolha, cabe à técnica não converter uma ambiguidade forte em código frágil.

Nuances e limites

O direito de recusar se corrompe rápido. Usado para obter uma especificação exaustiva antes de qualquer código, ele reconstitui um ciclo em cascata e nega a parcela de incerteza que o time deveria absorver.

A linha não é "está tudo escrito", mas "eu sei qual comportamento preciso tornar verdadeiro" — uma fronteira que depende do contexto compartilhado do time, e que nenhum modelo de documento fixa no lugar dele.

Questões em aberto

• Quem decide quando o produto considera o pedido suficientemente claro e o time de desenvolvimento considera o contrário?