Especificação de software: como fazer sem travar a empresa

Uma especificação de software não leva meses para ficar pronta por ser trabalhosa. Leva meses porque tenta decidir o sistema inteiro de uma vez e porque ninguém tem autoridade, ou disposição, para encerrar as discussões. Resolvidas essas duas coisas, a especificação passa a andar no ritmo do desenvolvimento: detalha-se só o próximo incremento, cada decisão tem um dono e um prazo, e os conflitos entre áreas aparecem em sessões curtas, e não na homologação.

A política corporativa não desaparece com isso. Ela ganha prazo.

Por que a especificação trava#

Num artigo anterior, o argumento foi que desenvolver com IA sem especificação acelera o retrabalho. A objeção natural vem em seguida: na prática, a especificação completa nunca fica pronta. Os motivos costumam ser os mesmos:

• Escopo grande demais. Tenta-se especificar o produto inteiro antes de começar, e cada área quer ver todas as suas regras no documento.
• Ninguém decide. As áreas opinam, mas nenhuma pessoa tem o papel de fechar a questão. Quem discorda não precisa vencer a discussão: basta não decidir.
• Não decidir não custa nada para quem não decide. A dúvida segue para o desenvolvimento, onde alguém, agora muitas vezes um agente de IA, escolhe uma resposta sem mandato para isso.
• Pouca gente sabe como fazer. Sem modelo nem exemplos, cada especificação vira um documento diferente, longo e difícil de revisar.

Um exemplo: o acordo de renegociação#

Um caso típico de crédito e cobrança mostra quanto cabe numa frase. O pedido chega assim: “permitir que o cliente em atraso negocie um acordo pelo aplicativo”. Parece uma funcionalidade. Na verdade, é uma lista de decisões que pertencem a áreas diferentes:

• Desconto: qual o desconto máximo por faixa de atraso? A área comercial quer flexibilidade para recuperar o cliente; a financeira quer proteger a margem.
• Base do desconto: o desconto incide sobre juros e multa, ou também sobre o principal?
• Condições: qual a entrada mínima e o número máximo de parcelas?
• Histórico: quem já quebrou um acordo nos últimos meses tem as mesmas condições?
• Exceções: quem pode aprovar uma condição fora da tabela, e até que valor?
• Negativação: depois do pagamento, em quanto tempo o registro em cadastro de inadimplentes é retirado? Aqui não há escolha: pela Súmula 548 do STJ, a exclusão cabe ao credor em até cinco dias úteis após o pagamento integral. A especificação precisa dizer quando o prazo começa a contar e quem dispara a baixa.
• Comunicação: que mensagens o cliente recebe, por qual canal e com que tom? O Código de Defesa do Consumidor, no art. 42, proíbe expor o consumidor inadimplente ao ridículo ou submetê-lo a constrangimento ou ameaça.
• Superendividamento: o que acontece quando o cliente declara não conseguir pagar sem comprometer o mínimo existencial, fixado em R$ 600 pelo Decreto 11.150/2022, na redação dada pelo Decreto 11.567/2023?
• Contabilidade: em instituições financeiras, renegociar afeta a classificação do crédito. Pela Resolução CMN 4.966, em vigor desde 2025, atraso superior a 90 dias caracteriza o ativo como problemático, e a norma tem regras próprias para operações reestruturadas. A controladoria precisa estar na conversa.

Nenhum desses itens é técnico. Todos são decisões de negócio, e todos serão tomados de alguma forma. A única escolha real é se serão tomados por quem tem autoridade e informação para isso, ou por quem estiver programando quando a dúvida aparecer.

Especifique o próximo incremento, não o sistema#

A saída para a especificação interminável é dividir o trabalho em dois níveis:

1. Um mapa curto do todo, com objetivo do produto, limites do que entra e do que não entra, glossário e grandes regras. No exemplo, o glossário define o que é “acordo”, “quebra de acordo”, “entrada” e “faixa de atraso”. Cabe em poucas páginas e muda pouco.
2. Especificação detalhada só do próximo incremento, o que o time vai construir nas próximas semanas. No exemplo, o primeiro incremento pode ser apenas o acordo à vista, com desconto para atrasos entre 31 e 180 dias e sem exceções. O parcelamento, a aprovação de exceções e o tratamento de quem já quebrou acordo ficam para os incrementos seguintes.

Fatiar assim reduz o número de decisões que precisam sair ao mesmo tempo, e esse é o ponto. Em vez de trinta definições disputadas entre seis áreas, o primeiro ciclo depende de cinco ou seis.

O resto do trabalho anda em paralelo: enquanto o time desenvolve um incremento, produto e negócio especificam o seguinte. É o que se chama de dual-track: descoberta e entrega como dois tipos de trabalho feitos pelo mesmo time, ao mesmo tempo. A especificação fica um passo à frente do desenvolvimento, não trinta meses à frente.

O Guia do Scrum de 2020 tem um critério útil aqui: um item está pronto para entrar numa sprint quando o time consegue concluí-lo dentro dela. Uma especificação detalhada do sistema inteiro nunca passa nesse teste; a de um incremento bem fatiado passa.

Dê dono a cada decisão#

O DACI, modelo usado e publicado pela Atlassian, separa quatro papéis em cada decisão:

• Condutor: reúne as pessoas e as informações, define o escopo e garante que a decisão saia na data combinada.
• Aprovador: a única pessoa que decide. O modelo insiste que seja uma só.
• Contribuidores: têm conhecimento sobre o assunto e fazem recomendações. Têm voz, mas não voto.
• Informados: são avisados do resultado porque o trabalho deles é afetado.

No exemplo do desconto máximo, o condutor pode ser o responsável pelo produto, o aprovador o diretor financeiro, e os contribuidores as áreas comercial, jurídica e de controladoria. O atendimento é informado. A disputa entre comercial e financeiro continua existindo, mas passa a ter um lugar, uma data e alguém que encerra a discussão.

Duas regras completam o arranjo:

• Toda decisão em aberto tem responsável e prazo, registrados junto com a especificação.
• A regra de escalada é combinada antes do conflito: se a decisão não sair no prazo, o patrocinador decide, ou o item sai do incremento. “O desenvolvimento resolve” não é uma das opções.

Sessões curtas para revelar o que ninguém sabe#

Reuniões longas de levantamento de requisitos produzem atas, não decisões. Uma técnica mais eficiente é o Example Mapping, descrito por Matt Wynne em 2015. Em cerca de 25 minutos por funcionalidade, um grupo pequeno, em geral alguém de negócio, alguém de desenvolvimento e alguém de qualidade, preenche cartões de quatro cores:

• Amarelo: a história, ou funcionalidade, em discussão.
• Azul: as regras.
• Verde: exemplos concretos de cada regra.
• Vermelho: perguntas que ninguém na sala sabe responder.

O resultado se lê pela quantidade de cartões. Muitos vermelhos indicam que ainda há muito a descobrir. Muitos azuis indicam uma funcionalidade grande demais, que precisa ser fatiada. Os cartões vermelhos viram, direto, a lista de decisões em aberto, cada uma com seu aprovador.

No exemplo do acordo, com valores ilustrativos:

• Regra (azul): o desconto incide sobre juros e multa, nunca sobre o principal.
• Exemplo (verde): dívida de R$ 1.000 de principal e R$ 400 de encargos, com desconto de 50% sobre os encargos, gera um acordo de R$ 1.200.
• Pergunta (vermelho): a regra vale para quem quebrou um acordo nos últimos 12 meses?

Escrito como critério de aceite, o exemplo verde vira algo verificável, sem espaço para interpretação:

Dado um cliente com R$ 1.000 de principal e R$ 400 de encargos, em atraso há 60 dias, quando ele aceita a proposta de acordo à vista, então o valor do acordo é R$ 1.200 e o boleto vence em até 3 dias úteis.

Esse formato, dado, quando e então, é também o que a Thoughtworks recomenda para especificações usadas por agentes de IA: linguagem do domínio, estrutura consistente e atenção ao caminho crítico, sem tentar enumerar todos os casos possíveis.

Use a IA para escrever, não para decidir#

A mesma IA que acelera o código acelera a especificação, desde que as decisões continuem com pessoas. Usos que funcionam:

• transformar a transcrição de uma sessão em um primeiro rascunho estruturado;
• listar casos de exceção que ninguém mencionou: e se o pagamento cair no fim de semana? e se o cliente tiver duas dívidas?
• apontar contradições entre o que duas áreas disseram;
• gerar as perguntas que um desenvolvedor faria antes de começar.

Ferramentas de spec-driven development, como o Spec Kit, do GitHub, já incluem etapas opcionais de esclarecimento e de análise de consistência antes da implementação. O trabalho humano deixa de ser redigir e passa a ser decidir e validar, e é aí que o tempo cai de meses para dias. A Thoughtworks ressalta, no mesmo texto citado acima, que a revisão de especificações continua exigindo um humano no processo e que ainda não há forma sistemática de avaliar sua qualidade.

As pesquisas sobre IA no desenvolvimento apontam na mesma direção. O modelo de capacidades de IA do DORA, publicado pelo Google em 2025, lista entre as práticas que ampliam o efeito positivo da IA o trabalho em lotes pequenos e o foco no usuário. Sem foco no usuário, segundo o estudo, a adoção de IA pode ter impacto negativo no desempenho do time: o time anda depressa, na direção errada.

Torne visível o custo de não decidir#

Interesse departamental resiste a argumento, mas costuma ceder a número. Quatro medidas simples ajudam:

• Decisões em aberto e há quanto tempo estão abertas.
• Tempo parado: quantos dias o desenvolvimento esperou por uma definição.
• “Evoluções” que corrigem algo já conhecido: regras que deveriam ter sido decididas antes.
• Retrabalho depois da homologação.

Quando o patrocinador vê que a indefinição sobre a base do desconto custou três ciclos de correção e duas semanas de time parado, o prazo para decidir passa a ser levado a sério. O número não elimina o conflito entre áreas, mas tira dele a vantagem de ficar escondido.

Por onde começar#

1. Escolha um piloto onde já dói, com retrabalho conhecido e um patrocinador disposto a arbitrar. Não anuncie uma transformação.
2. Escreva o mapa curto do todo e especifique só o primeiro incremento.
3. Defina o aprovador de cada decisão importante antes da primeira sessão.
4. Faça as primeiras especificações em dupla com quem já fez, como se faz com revisão de código, e guarde os bons exemplos. Quem nunca escreveu uma especificação aprende mais vendo três boas do que lendo um manual.
5. Guarde a especificação junto com o código, no mesmo repositório e com histórico. Mudar a regra continua permitido; a mudança só passa a ficar registrada, com motivo e responsável.
6. Meça antes e depois, por dois ou três incrementos, e mostre os números.

Também ajuda saber o que evitar: um “escritório de especificação” que vira mais uma fila, modelos com dezenas de seções obrigatórias e especificação detalhada para ajustes triviais. O tamanho da especificação deve acompanhar o risco da mudança. Uma regra de desconto pede exemplos e aprovação; um ajuste de texto na tela pede uma linha.