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

Paulo Castilho — Sun, 18 Oct 2026 19:59:00 -0300

Como organizar a especificação de software em incrementos curtos, com dono para cada decisão, mesmo com conflitos entre áreas. Exemplos de crédito e cobrança.

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:

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.
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#

Escolha um piloto onde já dói, com retrabalho conhecido e um patrocinador disposto a arbitrar. Não anuncie uma transformação.
Escreva o mapa curto do todo e especifique só o primeiro incremento.
Defina o aprovador de cada decisão importante antes da primeira sessão.
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.
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.
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.

Crédito e cobrança — Blog AreaCli