Requisitos contraditórios: 16 achados antes do código

Requisitos contraditórios são duas regras que não podem valer ao mesmo tempo, ou uma situação que nenhuma regra cobre, nas fronteiras entre partes do sistema. Neste CRM de cobrança, a especificação de alto nível dos onze escopos que faltam implementar encontrou 16 deles: um durante a escrita e 15 numa revisão cruzada feita por um revisor sem o contexto da conversa. Nenhum dependia de código para aparecer, e todos viraram regra antes de existir uma linha. Este artigo mostra como o alto nível foi montado, os achados mais caros e um que quase passou com a solução errada.

O que é a especificação de alto nível#

Depois de quatro incrementos, a mudança de método da parte 11 passou a exigir duas coisas antes de qualquer código novo: os documentos que valem para o sistema inteiro (estados, permissões, dados pessoais, interface, verificação, operação e, desde a parte 12, políticas comerciais) e uma especificação de alto nível de todos os escopos restantes. O detalhe, com critérios em valores, continua sendo escrito perto da implementação.

O alto nível de cada escopo cabe numa página e meia: objetivo, o que entra e o que fica de fora, regras principais numeradas, estados que cria ou altera, interações com os outros escopos, políticas do credor com padrão, premissas e decisões em aberto. São onze escopos: cadastros, carteira revista, políticas, pagamentos revistos, acionamentos revistos, promessas, acordos, filas, régua de cobrança, mensageria e a fase de várias empresas credoras.

Respostas que mudaram o desenho#

Como nos incrementos, várias respostas foram além das opções apresentadas, e algumas mudaram a estrutura do escopo:

• Filas. A proposta era uma fila única. A resposta foi que “deve ser possível associar usuários a grupos e são os grupos que se associam a filas”. Viraram várias filas, com critérios próprios, e cada devedor numa só.
• Régua. “Há ações que são por título e ações que são por devedor”: o aviso de vencimento conta da data da fatura; o aviso de protesto, do atraso total do devedor.
• Termo do acordo. “Precisa ser gerado um draft do termo, para podermos falar em aceite do devedor.” O aceite passou a ser sobre um rascunho gerado pelo sistema.

Dois escopos inteiros não estavam no mapa e foram apontados no meio do trabalho: o cadastro do próprio credor e do devedor pela tela, e a mensageria. Nem as especificações nem a ferramenta tinham notado que o credor era só um nome no sistema.

Uma contradição achada na escrita#

Ao escrever os acordos, a pergunta “como o devedor paga as parcelas?” teve como resposta “política do credor”, entre o credor emitir a cobrança no sistema dele ou o CRM emitir. O mapa do produto, aprovado no primeiro dia, dizia que emitir boleto e Pix não entrava. As duas regras não podiam valer juntas. O mapa foi revisto: a emissão pelo CRM virou um escopo futuro e opcional, com decisão técnica e contratos próprios, e até lá o credor emite a partir de um arquivo exportado.

A conferência cruzada#

Quem escreve uma especificação tende a não ver as próprias contradições, porque lembra o que quis dizer. A conferência foi feita por uma sessão separada do Claude Code, sem acesso à conversa: ela leu os documentos transversais, os onze de alto nível e as regras dos incrementos já implementados, com uma tarefa só, achar regras incompatíveis e situações sem regra nas fronteiras entre escopos, com exemplo em valores e proposta. Encontrou 15. Quatro mostram o tipo:

A baixa com dois donos. Pela regra de pagamentos, o credor concilia e baixa os títulos originais. Pela regra de acordos, na amortização, o CRM abate os títulos a cada parcela paga. Um título de R$ 1.000,00 num acordo recebe uma parcela de R$ 400,00: o CRM abate R$ 400,00, o credor emite a mesma parcela no sistema dele e manda “parcial, R$ 400,00 pagos” no arquivo. Resultado: R$ 800,00 abatidos de um título que recebeu R$ 400,00. A decisão: com a baixa feita pelo credor, o acordo gera só uma instrução exportada, e a baixa chega pelo arquivo dele.

O título que o próprio sistema apagaria. Na quebra de um acordo por novação, o saldo do acordo vira um título novo. A carga completa da carteira retira todo título ausente do arquivo do credor, e o sistema do credor não conhece esse título. Na carga seguinte, o CRM retiraria da cobrança uma dívida que ele mesmo criou. A decisão: títulos em acordo, renegociados ou criados pelo CRM ficam fora da retirada e aparecem na conferência como “mantido por acordo”.

Multa sobre multa. O mesmo título novo nasceria com o saldo do acordo como valor original, já com R$ 200,00 de multa e juros dentro, e a regra de encargos aplicaria outra multa de 2% e juros sobre juros. Numa relação de consumo, é cobrança indevida. A decisão: o título novo guarda separados os componentes herdados, e a multa não se aplica de novo.

O título que nunca chega a pago. Na amortização com desconto, a dívida atualizada de R$ 1.200,00 é negociada em 3 parcelas de R$ 300,00. Pagas as três, o acordo está quitado, mas o título continua com R$ 300,00 de saldo, o desconto que nenhuma regra mandava lançar, e voltaria às faixas de atraso, à fila e à régua. A decisão: o desconto é lançado como abatimento registrado na quitação do acordo.

Os outros onze foram da mesma natureza: a fórmula do saldo que não comportava encargos pagos antes do principal; o devedor que oscilaria entre segmentos todo dia por causa dos próprios encargos; o retorno combinado que “passa na frente sempre” contra os limites de horário; a anulação de um contato que não desfazia o número marcado como inválido; a prestação de contas já enviada que um estorno reabriria.

Aceitar em lote, e a proposta que tinha um problema#

Cada achado veio com uma proposta de resolução. A decisão foi aceitar todas e trazer para discussão só as que tivessem uma escolha embutida. Foram cinco. Uma delas não era só escolha: era um problema.

Para reconhecer um devedor anonimizado que voltasse numa carga com o mesmo CPF, o revisor propôs guardar um “resumo irreversível” do documento. A Lei Geral de Proteção de Dados diz, no art. 12, que dado anonimizado não é dado pessoal, “salvo quando o processo de anonimização […] puder ser revertido” com esforços razoáveis. Um CPF tem poucas combinações possíveis, e um resumo dele se reverte por tentativa em pouco tempo. Guardar o resumo seria manter um dado pessoal depois de dizer que ele foi eliminado. A proposta foi recusada: a anonimização é de verdade, e o CPF que volta é um devedor novo, sem histórico.

Aceitar em lote foi a decisão certa para dez das quinze propostas, que não deixavam nada em aberto. A lição é sobre o filtro: o que tem escolha ou risco embutido precisa sair do lote antes, porque nem quem propõe nem quem aprova de uma vez costuma ver o problema.

Por que só o alto nível acharia esses problemas#

Os 16 achados têm uma coisa em comum: estão nas fronteiras. A baixa dupla junta pagamentos e acordos; o título apagado junta carteira e acordos; a multa sobre multa junta acordos e encargos. A especificação de um incremento olha para dentro dele, e o teste de um incremento confirma o que a especificação dele diz. Num projeto comum, o primeiro desses problemas apareceria na homologação dos acordos, com a carteira já em produção, e corrigir a baixa dupla ali significaria rever dados reais.

Em números#

O que vem a seguir#

A ordem de implementação foi decidida com a visão do todo. Primeiro vem a reforma das telas, especificada nos padrões de interface; depois a carteira revista, que também corrige um saldo negativo que existe hoje no código publicado. Cada etapa volta ao ciclo de especificação detalhada, artigo e código, agora coerente com um alto nível que já passou por uma conferência.