Um revisor adversarial ataca a decisão pelas lentes de custo, risco operacional e simplicidade. As respostas são obrigadas a admitir o que não refutam, e um modelo de outro fornecedor dá a segunda opinião.
O problema
A revisão de arquitetura depende de alguém disposto a comprar a briga com o autor. Na prática, o documento circula, dois colegas dizem "faz sentido", e a primeira objeção séria aparece em produção, com juros.
O contraditório é parte do processo: objeção com lente e severidade, resposta com veredito, e o que procede fica registrado no próprio entregável. A divergência da segunda opinião idem: registrada, em vez de resolvida por votação.
Como funciona
Cada objeção declara por onde ataca (custo, risco operacional ou simplicidade), por que importa e o que a confirmaria. A resposta recebe um veredito: refutada, procede, ou procede parcialmente.
Objeção que procede fica registrada de propósito. Objeção verdadeira escondida é o pior resultado possível deste processo.
Objeções consideradas
Um revisor adversarial tentou derrubar esta recomendação, inclusive com as objeções que não foram vencidas.
Com crescimento de 8% ao mês, o custo por consulta dobra antes de 18 meses.
A projeção sobre a série real chega a R$ 3.280 no mês 18, dentro do teto aprovado. Acima disso, a premissa de volume já teria quebrado antes e reaberto a decisão.
Duas ferramentas onde uma daria conta dos painéis de hoje.
Procede para os três painéis atuais. Fica registrada: se o uso não crescer, a simplificação entra na próxima revisão.
Objeção que procede fica registrada de propósito. Objeção verdadeira escondida é o pior resultado possível deste processo. E o ataque vem de um modelo de fornecedor distinto do que recomendou.
Um modelo de fornecedor diferente revisa a mesma decisão, para os dois não compartilharem os vícios de treinamento. Onde discordam, a divergência é publicada dentro do entregável.
O selo "Objeções respondidas" anda junto com o registro completo: quantas objeções, quantas refutadas, quantas continuam de pé.
Modelo transacional para e-commerce
Versão 2 · auditado · 6 entidades, 31 colunas
| DDL executado em banco real | feito |
| Perguntas de negócio respondidas por query | feito |
| Revisão adversarial | feito |
| Prova sob carga | não medida |
Segunda opinião, de um modelo diferente
Discorda da normalização de stock_movements: em volume alto, o saldo calculado por soma vira o gargalo. Sugere materializar. A divergência ficou registrada, não resolvida.
Por dentro
O que impede o ataque de virar teatro.
O que vem depois
Script executado num PostgreSQL descartável, perguntas de negócio respondidas por query, e o selo mostrando o que foi e o que não foi verificado.
Ver por dentro →MétodoCânon de metodologiaDAMA-DMBOK, Kimball, Inmon, Data Vault, TOGAF e Well-Architected, curados e versionados, com a citação no achado do parecer.
Ver por dentro →DecisãoMatriz de decisãoCritérios ponderados, nota justificada, e cada opção declarando quanto custa e quanto demora sair dela em 18 meses.
Ver por dentro →Cole a estrutura, receba os achados mais graves em cerca de dois minutos e decida depois se vale abrir uma consultoria. Sem conta, sem cartão.