Especificação antes do código não atrasa o projeto?

Atrasa o começo da construção e encurta o total. O tempo gasto escrevendo a especificação é menor que o retrabalho de construir a coisa errada, e a diferença cresce com o tamanho do projeto. Em escopo fechado, esse tempo é nosso risco, não seu.

Quem escreve a especificação: vocês ou o cliente?

Nós escrevemos, a partir de conversas com quem opera. O cliente lê e aprova — e é justamente na leitura que aparece a divergência que teria custado semanas se fosse descoberta com a tela pronta.

Onde esse método não serve?

Em exploração genuína, quando ninguém sabe ainda o que o produto deve fazer e o objetivo é aprender rápido. Aí a especificação detalhada documenta um palpite. Nesse caso o certo é protótipo descartável primeiro, especificação depois que a dúvida fechar.

Spec antes de código: como funciona o

Escrever a especificação antes do código parece burocracia até o terceiro retrabalho. Como funciona na prática, o que muda e onde o método não serve.

Todo projeto de software que atrasa atrasa duas vezes. A primeira quando alguém constrói a coisa errada. A segunda quando descobre.

A distância entre esses dois momentos é o que determina o custo. Descobrir na conversa de alinhamento custa uma hora. Descobrir no code review custa um dia. Descobrir quando o cliente abre a tela custa a confiança — e o retrabalho vem por cima.

Desenvolvimento orientado a especificação é uma tentativa de encurtar essa distância até quase zero: a divergência aparece enquanto ainda é texto.

O que é uma especificação, na prática

Não é documento de cem páginas nem diagrama UML. É um arquivo curto, por funcionalidade, que responde quatro coisas:

O que o sistema faz. Em uma frase, do ponto de vista de quem usa. "O operador confirma a entrega informando o código que o cliente recebeu."

Quem pode fazer. Qual perfil, sob que condição. É onde mora metade dos bugs de segurança que aparecem depois: ninguém escreveu que aquele endpoint só valia para o dono do pedido.

O que acontece quando dá errado. Código já expirou, cliente não está no local, o pedido foi cancelado no meio. A lista de casos ruins é sempre maior que a de caso feliz, e é ela que separa a estimativa realista da otimista.

Como se sabe que funcionou. Critérios de aceite escritos como afirmação verificável, não como adjetivo. "Rápido" não é critério. "Responde em menos de 300ms com mil pedidos na fila" é.

Uma especificação dessas cabe em duas páginas. Se está passando de cinco, quase sempre são duas funcionalidades disfarçadas de uma.

Por que escrever antes muda a conversa

O ganho óbvio é o alinhamento. O ganho que não é óbvio: escrever força a decidir.

É perfeitamente possível conversar uma hora sobre uma funcionalidade, todo mundo concordar, e cada pessoa sair da sala com um entendimento diferente. A conversa tolera ambiguidade; o texto não. Na hora de escrever "o que acontece se o pagamento falhar no meio", alguém precisa decidir — e é aí que se descobre que o time comercial e o time técnico assumiam coisas incompatíveis.

Esse é o momento mais barato possível para descobrir isso.

O segundo artefato: a decisão registrada

Especificação diz o que o sistema faz. Ela não diz por que ele foi construído daquele jeito.

A pergunta que aparece dois anos depois nunca é "o que isso faz" — o código responde. É "por que isso é assim?". E a resposta costuma estar na cabeça de alguém que não trabalha mais na empresa.

Por isso toda decisão de arquitetura que fecha uma porta é registrada num arquivo curto: qual era o problema, quais opções existiam, qual foi escolhida e o que se aceitou perder. Especialmente o que se aceitou perder — é a parte que a pessoa do futuro precisa para saber se a decisão ainda vale.

O custo é dez minutos por decisão. O retorno aparece na primeira vez que alguém evita refazer uma análise que já tinha sido feita.

O que faz o método não desandar

Processo que depende de disciplina humana degrada. Sempre. Numa semana corrida, a especificação vira "depois eu escrevo", e depois nunca chega.

O que sustenta é o que roda sozinho: verificações automatizadas que reprovam quando a especificação não existe, quando o padrão de código foi quebrado, quando o teste que deveria cobrir aquele caminho não está lá. Não é rigor de quem revisa — é uma verificação que reprova igual para todo mundo, inclusive para quem escreveu a regra.

A diferença entre um método que funciona e um que virou folclore interno é exatamente essa: existe algo mecânico segurando, ou só a boa vontade de quem está com pressa?

Onde não serve

Vale dizer o contrário também.

Descoberta. Quando ninguém sabe ainda qual é o produto, especificar antes é especificar a suposição errada com precisão. A fase de descoberta pede protótipo descartável, não especificação.

Correção urgente. Sistema fora do ar não espera texto. O que se faz é corrigir, e depois escrever o que se aprendeu — inclusive por que o defeito passou.

Mudança trivial. Trocar o texto de um botão não merece dois artefatos. Faz parte do método saber onde ele não se aplica; método que se aplica a tudo vira burocracia, e burocracia todo mundo aprende a contornar.

O efeito colateral que interessa a quem compra

Para quem contrata software, o método tem uma consequência prática que vale mais que a discussão técnica: os artefatos são conferíveis.

Uma especificação aprovada é um documento que você leu e concordou, antes de pagar pela construção. Um relatório de execução de testes é um resultado, não uma promessa. Um registro de decisão é auditável por qualquer técnico que você chame para dar uma segunda opinião.

Sem isso, avaliar um fornecedor de software é avaliar a simpatia da reunião de status. É por isso que tanta gente já se queimou: não faltava competência para julgar, faltava objeto para julgar.

Como aplicamos isso: especificação aprovada antes de qualquer código, decisões de arquitetura registradas com o motivo, e verificação automatizada que reprova o que sai do padrão. É o método que descrevemos em como trabalhamos.

Spec antes de código: como funciona o desenvolvimento orientado a especificação