Dívida Técnica: A Conta Que Você Já Está Pagando Parcelada

Cinco pilares para transformar risco técnico em decisão de negócio — com evidência, com honestidade intelectual e sem prometer o que você não pode entregar.

Você já viveu essa cena. O time levanta que o motor de cobrança precisa ser reestruturado. Alguém monta um slide. A palavra “refatoração” aparece três vezes, “acoplamento” aparece duas, e há um diagrama com muitas setas. A reunião termina com um “faz sentido, vamos avaliar no próximo trimestre” — que é a forma corporativa de dizer não sem ter que justificar.

A explicação confortável para o que aconteceu é que a diretoria não entende de tecnologia. A explicação honesta é mais desconfortável: o pedido foi feito numa moeda que ninguém do outro lado da mesa sabe converter.

O problema raramente é indiferença. Executivos aprovam investimentos difíceis o tempo todo — trocam o core bancário, compram empresa, aceitam três anos de payback. O que eles não fazem é aprovar algo que chega descrito em qualidade de código, cobertura de teste e framework depreciado, sem nenhuma tradução para receita, custo, risco ou posição competitiva. E há uma falha ainda mais comum: apresentar um caso genérico e único para todo mundo ao mesmo tempo, obrigando cada executivo a fazer a tradução sozinho — o que, na prática, termina em decisão nenhuma.

A escala do problema não é anedota. Numa pesquisa da McKinsey com 50 CIOs de instituições financeiras e empresas de tecnologia com receita acima de US$ 1 bilhão, os entrevistados estimaram que a dívida técnica representa entre 20% e 40% do valor de todo o parque tecnológico antes da depreciação, e relataram que de 10% a 20% do orçamento nominalmente destinado a produtos novos acaba desviado para resolver problemas decorrentes dela. Do outro lado da régua, o CISQ estimou o custo da má qualidade de software nos Estados Unidos em US$ 2,41 trilhões, com a dívida técnica acumulada em torno de US$ 1,52 trilhão.

Pilar 01: Recupere o significado da metáfora antes de usá-la

Você não consegue precificar um conceito que cada pessoa na sala entende de um jeito. E “dívida técnica” virou exatamente isso: um guarda-chuva onde cabe desde uma falha arquitetural que impede a empresa de lançar produto até o desgosto de alguém com o nome de um pacote.

Lição 1.1 → A metáfora nasceu num banco, e nasceu para falar com executivos

Ward Cunningham cunhou o termo em 1992, num relatório de experiência apresentado na OOPSLA sobre o WyCash — um sistema de gestão de portfólio. Ele estava cercado de gente de finanças, precisava justificar tempo investido em melhorar código existente, e escolheu deliberadamente uma linguagem que aquela audiência já dominava.

Repare na ironia: a metáfora foi inventada como ferramenta de comunicação com o C-level, dentro de uma empresa financeira. Nós é que a sequestramos e transformamos em jargão interno de engenharia.

E há uma segunda perda, mais séria. Numa entrevista de 2009, Cunningham voltou ao tema para dizer que a metáfora nunca foi sobre código bagunçado, e sim sobre o custo de operar com um entendimento incompleto do domínio. Michael Feathers formulou isso da maneira mais útil que já vi: dívida técnica é a distância acumulada entre o seu entendimento do problema e o entendimento que o sistema reflete. Você começa codificando o que entendeu; depois aprende mais; se o código não acompanha o aprendizado, você passa a tropeçar num descompasso conceitual toda vez que mexe ali.

Essa definição é infinitamente mais defensável numa reunião do que “o código está ruim”. Porque ela é verificável: quantas vezes, no último trimestre, uma regra de negócio nova exigiu contornar o modelo em vez de usá-lo?

Lição 1.2 → Classifique a dívida antes de cobrá-la

Nem toda dívida tem a mesma origem, e a origem muda completamente quem deve responder por ela.

Steve McConnell, num artigo da IEEE Software de 2007, propôs a primeira taxonomia séria: dívida não intencional, produzida por desconhecimento ou processo falho; dívida de curto prazo, assumida deliberadamente por um ganho imediato; e dívida de longo prazo, acumulada pela evolução natural do sistema. Foi ele também quem tornou explícito o par principal/juros.

Martin Fowler foi além em 2009 com o quadrante de dívida técnica, cruzando dois eixos:

                    PRUDENTE              IMPRUDENTE
                ┌─────────────────────┬─────────────────────┐
   DELIBERADA   │ "Entregamos agora,  │ "Não temos tempo    │
                │  refatoramos no     │  para desenhar       │
                │  próximo ciclo"     │  isso direito"       │
                ├─────────────────────┼─────────────────────┤
   INADVERTIDA  │ "Agora entendemos   │ "O que é camada     │
                │  como deveria       │  de domínio?"        │
                │  ter sido feito"    │                      │
                └─────────────────────┴─────────────────────┘

Por que isso importa numa conversa com gestão? Porque muda o pedido. Dívida deliberada e prudente é uma promessa que a empresa fez a si mesma e agora precisa honrar — você está cobrando uma decisão anterior, não pedindo um favor. Dívida inadvertida e prudente é aprendizado do domínio; é o quadrante mais honesto e o mais fácil de defender, porque ninguém errou. Já dívida imprudente, deliberada ou não, é um problema de processo ou de capacitação — e apresentá-la como se fosse trade-off estratégico é desonesto e, pior, não resolve, porque a mesma dívida vai voltar em seis meses pela mesma porta.

Lição 1.3 → Diga em voz alta qual dívida você não vai pagar

Este é o movimento mais contraintuitivo do artigo e talvez o de maior retorno.

Quem chega no fórum de arquitetura pedindo para zerar a dívida está pedindo para não ser levado a sério — porque zerar dívida significaria alocar todo o recurso disponível em remediação, sem construir nada que diferencie a empresa. A própria McKinsey é explícita ao dizer que o objetivo não é chegar a zero, e a orientação prática é que raramente compensa reduzir abaixo de algo em torno de 10%: parte da dívida simplesmente nunca vale o custo de pagar.

Então inverta. Leve uma lista de três itens que o seu time decidiu conscientemente não corrigir, com a razão de cada um: “esse módulo é feio mas não é tocado há dois anos e não é caminho crítico”, “essa duplicação é intencional para desacoplar dois times”, “esse serviço vai ser desligado em 2027, não vamos investir nele”.

O efeito prático

No instante em que você mostra o que decidiu não fazer, o seu pedido deixa de ser preferência estética e passa a ser priorização. Você para de ser o engenheiro que sempre quer reescrever tudo e vira a pessoa que já filtrou o ruído antes de ocupar o tempo da liderança. Isso não é técnica de retórica — é o subproduto natural de ter feito o trabalho de análise de verdade.

Pense comigo — antes de dizer a palavra “dívida”

• Isso atrapalha o negócio ou atrapalha a mim? A pergunta honesta é: se ninguém mais mexer nesse código nos próximos dois anos, alguma coisa acontece? Se a resposta é não, você tem uma preferência, não uma dívida.

• Em que quadrante isso está? Se for deliberada e prudente, quem prometeu pagar? Quando? Está registrado em algum lugar, ou só na memória de quem estava na sala?

• Qual é a distância entre o sistema e o meu entendimento atual do domínio? Conte as vezes em que uma regra nova precisou de gambiarra em vez de encaixar no modelo. Esse número é a sua evidência.

• O que eu vou dizer que NÃO vamos corrigir? Se você não consegue nomear três itens, você ainda não priorizou — só listou incômodos.

Pontos altos do Pilar 1

1. A metáfora nasceu para conversar com executivos, dentro de uma empresa financeira. Nós a transformamos em jargão de engenheiro.

2. Dívida é a distância entre o sistema e o entendimento atual do domínio — não a feiura do código.

3. Levar uma lista do que você decidiu não corrigir transforma o pedido de preferência em priorização.

Pilar 02: Traduza para a moeda de quem decide

O diretor não precisa entender o problema técnico. Precisa entender a unidade de medida. E, felizmente, a unidade certa já existe e é justamente a que ele usa todos os dias.

Lição 2.1 → Separe principal de juros — e apresente os dois

A referência aqui é o livro de Philippe Kruchten, Robert Nord e Ipek Ozkaya, Managing Technical Debt: Reducing Friction in Software Development (SEI Series, 2019), que dedica um capítulo inteiro à distinção entre principal e juros, custo e valor, dívida potencial e dívida efetiva.

A tradução é direta:

• Principal — o custo de remediar. É um número único, em horas ou reais, com data.

• Juros — o arrasto recorrente que você paga todo mês por não ter remediado. É um número por período.

Quase todo engenheiro apresenta só o principal: “são seis semanas de duas pessoas”. E é exatamente por isso que o pedido é arquivado — porque, isolado, o principal é puro custo. Sem os juros ao lado, você está pedindo para a empresa gastar seis semanas em troca de nada visível.

Com os juros, a conversa muda de natureza. Deixa de ser “quero gastar” e passa a ser “estamos gastando, só que parcelado e sem abater o saldo devedor”.

Lição 2.2 → Os juros são invisíveis por natureza — o seu trabalho é dar rosto a eles

Juros de dívida técnica não aparecem em nenhuma linha de orçamento. Eles se escondem dentro de custos que já foram normalizados pela organização: plantão, conciliação manual, retrabalho, incidente, prazo de entrega que ninguém mais questiona porque “sempre foi assim”.

Vamos a um caso concreto do nosso mundo. Motor de cobrança sem reprocessamento idempotente:

PRINCIPAL
  6 semanas × 2 engenheiros ................... R$  96.000

JUROS (por ano, hoje)
  Conciliação manual pós-falha
    4h/semana × 52 × R$ 120/h ................. R$  24.960
  Plantão acionado por reprocesso duplicado
    ~2 incidentes/mês × 5h × 2 pessoas ........ R$  28.800
  Retrabalho de atendimento (estorno indevido)
    ~35 casos/mês × 40 min × R$ 45/h .......... R$  12.600
  Janela de entrega travada
    3 iniciativas adiadas no ano (ver adiante)
  ─────────────────────────────────────────────────────────
  Subtotal mensurável ......................... R$  66.360/ano

Duas coisas acontecem quando você apresenta assim. Primeiro, o principal deixa de ser caro: R$ 96 mil contra R$ 66 mil por ano é payback em pouco mais de dezoito meses, e todo diretor sabe ler payback. Segundo — e mais importante — você acabou de tornar visível um gasto que a empresa já vinha fazendo sem saber que fazia.

A frase que funciona

“A gente já pagou o principal dessa dívida uma vez e meia nos últimos doze meses. Só que parcelado, em plantão e conciliação manual — e sem abater um centavo do saldo devedor.”

Não é retórica. É a descrição literal do que está acontecendo.

Lição 2.3 → Quantifique o custo de atraso — porque a intuição alheia sobre ele é péssima

Repare que na conta acima ficou uma linha em aberto: “3 iniciativas adiadas no ano”. Essa linha costuma ser a maior de todas, e quase ninguém a preenche.

O conceito é o Custo de Atraso, formulado por Donald Reinertsen em The Principles of Product Development Flow (2009). Ele mede o impacto econômico do tempo sobre a realização de valor: receita não realizada, custo de oportunidade e riscos que se acumulam enquanto algo espera na fila. O conselho dele é célebre — se você só puder quantificar uma coisa, que seja o custo de atraso.

E há dois dados no trabalho de Reinertsen que valem ouro numa reunião:

• Cerca de 85% dos gestores de produto não conhecem o próprio custo de atraso.

• Quando estimam por intuição, as estimativas divergem entre si numa proporção de até 50 para 1.

Traduzindo: quem chega com esse número calculado tem uma vantagem informacional enorme sobre todo mundo que chega com sensação — inclusive sobre pessoas hierarquicamente acima. Não porque seja mais inteligente, mas porque fez uma conta que os outros presumiram impossível.

O caso mais citado é o da Maersk Line: uma funcionalidade que ficou 38 semanas parada em filas, com custo de atraso superior a US$ 200 mil por semana — perto de US$ 8 milhões em receita não realizada por algo que ninguém percebia como custo, porque fila não aparece em relatório.

Para ordenar iniciativas concorrentes, Reinertsen propõe o CD3: custo de atraso dividido pela duração. É a régua que responde à pergunta que o seu gestor realmente tem — não “isso é importante?”, mas “isso é mais importante do que as outras sete coisas que estão na minha mesa?”.

Aplicando ao domínio bancário

Uma integração de Pix travada por um mês não custa “um mês de time”. Custa a receita de tarifa não capturada nesse mês, mais o custo de aquisição dos clientes que abriram conta em outro lugar, mais o risco de multa se houver prazo regulatório envolvido. Quando você monta essa conta, descobre com frequência que o custo de atraso é uma ordem de grandeza maior do que o custo do trabalho — e essa é a informação que muda a decisão.

Pense comigo — antes de apresentar um número

• Eu estou apresentando principal, juros, ou os dois? Se for só o principal, você está pedindo custo puro. Sem os juros, a resposta racional do outro lado é não.

• Onde os juros estão escondidos hoje? Plantão, conciliação manual, retrabalho de atendimento, prazo inflado. Procure em orçamentos que já existem e ninguém questiona.

• Quanto custa cada semana de atraso? Receita não capturada, custo de oportunidade, exposição regulatória. Se você nunca fez essa conta, faça uma vez — o resultado costuma surpreender você antes de surpreender o gestor.

• Isso é mais importante do que as outras coisas na mesa dele? Essa é a pergunta real. Responder a ela com CD3 é mais honesto do que responder com convicção.

Pontos altos do Pilar 2

1. Principal e juros é a estrutura mental que a área financeira já domina. Use a linguagem dela em vez de inventar a sua.

2. Juros de dívida técnica se pagam parcelados e invisíveis — dar rosto a eles é metade do trabalho de convencimento.

3. Quantifique o custo de atraso: a intuição alheia sobre ele erra por ordens de grandeza, e quem calculou tem vantagem informacional real.

Pilar 03: Meça sem fingir precisão

Vamos para o pilar que separa o profissional maduro do vendedor interno. Porque o Pilar 2 tem um efeito colateral perigoso: quando você aprende a produzir números, fica tentador produzi-los com uma confiança que os dados não sustentam.

E diretor experiente detecta falsa certeza. Uma vez detectada, tudo que você disser depois entra com desconto — inclusive o que era verdade.

Lição 3.1 → Medir é reduzir incerteza, não eliminá-la

A referência é Douglas Hubbard, How to Measure Anything: Finding the Value of “Intangibles” in Business. A tese central liberta o engenheiro do impasse mais comum: “não dá para medir isso”.

Hubbard trata medição como redução de incerteza baseada em observação — não como obtenção de certeza. E faz questão de distinguir as duas coisas: reduzir incerteza é possível, eliminá-la não é, porque o mundo é complexo demais. A consequência prática é enorme: mesmo uma redução modesta de incerteza já tem valor econômico, e organizações deixam muito valor na mesa ao operar por intuição quando técnicas simples dariam clareza suficiente para escolher melhor.

Ele também é direto sobre por que as pessoas acham que algo não pode ser medido, e nenhuma das razões tem a ver com o objeto: ou a definição de medição está mal compreendida, ou o objeto da medição não foi bem definido, ou os métodos disponíveis são desconhecidos. Na esmagadora maioria dos casos em engenharia, o problema é o segundo — “a dívida do motor de cobrança” não é mensurável, mas “horas de plantão por mês atribuíveis a reprocesso duplicado” é trivial.

Lição 3.2 → Decomponha, depois fale em faixas de 90%

Duas técnicas específicas, ambas do arsenal de Hubbard, e ambas aplicáveis na próxima segunda-feira.

Decomposição. Só quebrar uma estimativa muito incerta em componentes menores já produz uma melhora substancial na estimativa — antes mesmo de coletar qualquer dado novo. Foi o que fizemos na tabela de juros do Pilar 2: ninguém sabe responder “quanto custa essa dívida”, mas todo mundo consegue estimar horas de plantão, número de incidentes e custo-hora.

Intervalo de confiança de 90%. Em vez de um número, você declara uma faixa que tem 90% de chance de conter o valor real. E há um teste simples para calibrar os limites: um intervalo de 90% implica 5% de chance de o valor real estar acima do teto e 5% abaixo do piso. Então pergunte-se se você está 95% seguro de que o valor real fica abaixo do teto que escreveu. Se não estiver, suba o teto. Faça o mesmo com o piso.

✗  "Isso vai economizar R$ 480 mil por ano."

✓  "Entre R$ 320 mil e R$ 700 mil por ano, com 90% de confiança.
    A maior fonte de incerteza é o volume de incidentes —
    trabalhamos com 18 a 30 por trimestre; se ficar perto de 18,
    o retorno vai para a ponta de baixo da faixa."

A segunda versão parece mais fraca. Não é. Ela é a única das duas que sobrevive a uma auditoria dos números daqui a um ano — e, portanto, a única que constrói credibilidade em vez de gastá-la.

Há ainda um efeito que vale mencionar: pessoas não são naturalmente boas em produzir intervalos calibrados, mas essa é uma habilidade treinável, com melhora mensurável por repetição e feedback. Vale exercitar em time, comparando estimativas passadas com resultados reais.

Lição 3.3 → Use evidência de sistema, não evidência de opinião — e pare de medir o que não muda a decisão

Números que você produziu sozinho, sobre o seu próprio pedido, têm um problema óbvio de credibilidade. Por isso vale ancorar parte do argumento em métricas que o time já coleta e que não foram inventadas para essa reunião.

As métricas DORA — lead time para mudança, frequência de deploy, taxa de falha de mudança e tempo de restauração de serviço, popularizadas em Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim — funcionam bem porque descrevem o comportamento do sistema ao longo do tempo, não a sua opinião sobre ele. “A taxa de falha de mudança nesse serviço é 3× a média dos demais, há seis trimestres” é um fato observável.

Com uma ressalva que aumenta a sua credibilidade justamente por ser dita em voz alta: DORA é indicador de sistema e de time, não instrumento de avaliação individual. Se você não disser isso, alguém em algum momento vai usar o seu gráfico para avaliar pessoas, e o dano será atribuído a você.

Por fim, o critério que economiza semanas de análise, também de Hubbard: se a informação não tem influência sobre a decisão, ela não tem valor. Antes de o time gastar duas sprints instrumentando algo, pergunte qual o limiar em que aquele número mudaria a escolha. Se não existe limiar — se o “sim” ou “não” será o mesmo em qualquer resultado — a medição é curiosidade, não evidência.

Pense comigo — antes de dizer que tem certeza

• Eu consigo decompor isso em três coisas que eu de fato observo? Se não consigo, o problema não é falta de dado — é que a variável ainda não foi definida direito.

• Estou 95% seguro de que o valor real fica abaixo do meu teto? Se hesitei, o teto está baixo demais. Suba antes que a realidade suba por mim.

• O que eu explicitamente não sei aqui? Declarar isso primeiro tira do outro lado o trabalho de descobrir depois — e é a diferença entre ser corrigido e ser desacreditado.

• Se esse número der o contrário do que eu espero, a minha recomendação muda? Se não muda, eu não estou medindo. Estou procurando munição.

Pontos altos do Pilar 3

1. Medir é reduzir incerteza, não eliminá-la — e reduzir já é suficiente para decidir melhor.

2. Fale em faixas de 90%. Ponto único é promessa disfarçada de análise, e ela vence com juros.

3. Declarar o que você não sabe aumenta, não diminui, o peso do que você sabe.

Pilar 04: Classifique a decisão antes de pedir a decisão

Grande parte da fricção entre engenharia e gestão vem de um erro de enquadramento: tratamos decisões muito diferentes com o mesmo protocolo. Coisas triviais viram reunião de arquitetura; coisas irreversíveis são resolvidas numa thread de Slack de quinze minutos.

Lição 4.1 → Porta de uma via ou porta de duas vias

A formulação mais útil que o mercado produziu sobre isso está na carta de acionistas da Amazon. Decisões Tipo 1 são portas de uma via: consequentes e irreversíveis ou quase, e devem ser tomadas com método, lentidão, deliberação e consulta. Decisões Tipo 2 são portas de duas vias: reversíveis, e podem — devem — ser tomadas rapidamente por indivíduos ou grupos pequenos.

O diagnóstico que acompanha a ideia é o que interessa: à medida que organizações crescem, elas tendem a aplicar o processo pesado de Tipo 1 à maioria das decisões, inclusive às de Tipo 2. O resultado é lentidão, aversão a risco irrefletida, experimentação insuficiente e, por consequência, menos invenção.

Aplicando ao nosso ofício, com a nuance honesta: em software, quase nada é porta de uma via de verdade, porque quase tudo pode ser mudado com trabalho suficiente. A pergunta prática não é “é reversível?”, e sim “é reversível a que custo?”.

PORTA DE UMA VIA (ou quase)          PORTA DE DUAS VIAS
─────────────────────────────        ─────────────────────────────
Modelo de dados do razão             Biblioteca de cliente HTTP
Chave de partição no DynamoDB        Estratégia de cache
Provedor de core banking             Formato de log
Contrato de API pública              Ferramenta de observabilidade
Esquema de chaves de idempotência    Framework de teste

E aqui está o movimento que muda a reunião: declare a classificação antes de pedir a decisão. “Essa é reversível, sugiro decidirmos hoje e revisarmos em 60 dias” devolve poder ao gestor e elimina o teatro de aprovação. “Essa é de uma via, custa aproximadamente X para reverter, e por isso trouxe três alternativas com as consequências de cada uma” comunica seriedade sem drama.

Lição 4.2 → Instrumente a decisão: ADR, registro de dívida e pre-mortem

Três ferramentas concretas que transformam conversa de corredor em evidência auditável.

ADR — Architecture Decision Record. Formato proposto por Michael Nygard: contexto, decisão, consequências. O campo que quase todo mundo esquece é o das alternativas descartadas e por quê. É esse campo que protege você da pergunta “por que ninguém pensou nisso?” dois anos depois, feita por alguém que não estava na sala. Um ADR de meia página é o registro mais barato de responsabilidade compartilhada que existe.

Registro de dívida técnica. Kruchten, Nord e Ozkaya recomendam manter um registro explícito, com os itens de dívida armazenados nas mesmas ferramentas de trabalho do time e dentro de um único backlog. A lógica é simples e boa: dívida, assim como defeito e funcionalidade, representa trabalho a ser feito — então precisa ser visível e planejável, não viver numa planilha paralela que só engenheiro abre.

Isso resolve, de quebra, o problema da Lição 1.2: quando a dívida deliberada é registrada no momento em que é contraída, cobrar o pagamento depois deixa de ser opinião e passa a ser conferência.

Pre-mortem. Técnica de Gary Klein: reúna o time, declare que estamos um ano no futuro e o projeto fracassou, e peça a autópsia. Funciona porque inverte o incentivo social — em vez de precisar ter coragem para levantar um risco na frente do patrocinador, a pessoa é convidada a fazê-lo. Numa cultura em que ninguém quer ser o pessimista da sala, isso muda o que chega à mesa.

Lição 4.3 → Saber perder é parte da técnica

Você vai perder discussões. Vai apresentar a conta certa, com a faixa calibrada e o custo de atraso, e mesmo assim a decisão vai ser outra — por razões que talvez nem lhe contem, porque nem toda informação é sua para ter.

O complemento indispensável dos Tipos 1 e 2 é o disagree and commit: seguir adiante mesmo sem consenso, especialmente quando a decisão é reversível e o custo de estar errado é baixo. Mas a prática exige duas coisas que costumam ser omitidas:

• Registrar a discordância sem sabotar a execução. Um parágrafo no ADR — “esta opção foi escolhida contra a recomendação da engenharia, pelas razões X; o risco identificado é Y; sugerimos revisar em Z” — é registro, não é passivo-agressividade. O que é passivo-agressivo é executar mal para provar o ponto.

• Não cobrar a fatura depois. Quando o risco se materializa, a tentação de dizer “eu avisei” é enorme e o retorno é zero. O profissional que ganha autoridade de verdade é o que aparece com a solução e deixa o registro falar sozinho — ele está lá, datado, e todo mundo sabe.

Perder bem é o que compra o direito de ser ouvido na próxima. E vai haver próxima.

Pense comigo — antes de marcar a reunião

• Essa porta é de uma via ou de duas — e reverter custa quanto? Se for barata de reverter, talvez você não precise de aprovação nenhuma. Precise de um prazo para reavaliar.

• Estou pedindo decisão ou pedindo cobertura? São coisas diferentes, e misturá-las é o que faz reuniões de arquitetura durarem duas horas sem concluir nada.

• Se isso der errado em um ano, qual será a explicação? Faça o pre-mortem antes de a decisão sair, não depois do incidente.

• Se eu perder essa, eu executo bem mesmo assim? Se a resposta honesta for “não com vontade”, o problema deixou de ser técnico.

Pontos altos do Pilar 4

1. Diga se a porta é de uma via ou de duas antes de pedir aprovação — isso define o processo inteiro e devolve poder a quem decide.

2. Tratar decisão reversível como irreversível é a forma mais cara de parecer prudente.

3. ADR, registro de dívida e pre-mortem convertem memória de corredor em evidência datada.

Pilar 05: Construa crédito antes de precisar dele

Vamos ser explícitos sobre o que este pilar não é. Não é sobre puxar conversa no cafezinho, não é sobre virar amigo do diretor, não é sobre política de corredor. É sobre uma coisa só, e ela é mensurável: histórico de previsões cumpridas.

Há uma leitura incômoda que sustenta o pilar inteiro: dívida técnica não é, na origem, um problema técnico. Ela se manifesta como rigidez no sistema, mas é subproduto de problemas de processo e comunicação, com raiz na cultura da organização. Empresas muito siladas — onde engenharia, produto e design trabalham isolados — acumulam muito mais dívida, porque decisões de trade-off tomadas no código ficam a camadas de distância da necessidade real do cliente. Onde falta confiança, sobra dívida.

Lição 5.1 → Um caso por interlocutor, não um caso genérico para todos

Este é o erro mais caro e o mais fácil de corrigir. O mesmo problema técnico precisa de argumentos diferentes conforme quem está do outro lado:

• CFO / diretor financeiro — risco financeiro quantificado, payback, custo evitado. Fale em principal, juros e prazo de retorno.

• Diretor comercial / de receita — churn, capacidade do time de vendas continuar vendendo, prazo de entrega prometido a cliente.

• Produto — proteção do roadmap. O argumento vencedor é: quantas entregas suas eu destravo, e quando.

• Risco e compliance — exposição regulatória, rastreabilidade, prazo de resposta a demanda de auditoria. Num banco, esse costuma ser o interlocutor mais poderoso e o menos procurado por engenheiros.

Apresentar um único caso genérico para todos ao mesmo tempo obriga cada pessoa a traduzir sozinha para a própria realidade — e o resultado quase sempre é decisão nenhuma. Não porque discordem, mas porque ninguém se sentiu diretamente endereçado.

Lição 5.2 → Pense em campanha, não em reunião única — e volte com o número prometido

Ninguém aprova investimento estrutural na primeira exposição ao tema. Vale pensar como publicitário pensa: alcance e frequência. Quantas pessoas o argumento atinge, e quantas vezes.

Na prática, isso significa que o tema aparece em três ou quatro contextos antes de virar pedido formal — uma menção no relatório mensal, um dado no pós-mortem de um incidente, uma conversa de dez minutos com produto, um slide de contexto numa apresentação sobre outra coisa. Quando o pedido formal chega, ele não é novidade para ninguém. É a conclusão de algo que a organização já vinha percebendo.

A parte que quase todo mundo pula

Se você pediu aprovação prometendo “reduzir em 40% o tempo de resposta a incidente de liquidação”, volte em 90 dias com esse número exato, na mesma linguagem, mesmo que ele tenha ficado em 22%.

Sem isso, a próxima proposta parte do zero — e a organização aprende que investimento em engenharia é um lugar para onde recursos vão e do qual nenhuma notícia volta. Ter entregado 22% e reportado honestamente constrói mais crédito do que ter entregado 40% e nunca ter contado.

Lição 5.3 → Não use medo como alavanca — e reconheça que parte da desconfiança é merecida

O apelo catastrofista funciona uma vez. “Se não fizermos isso, o sistema vai cair” produz atenção imediata na primeira ocorrência. Na segunda, você é o engenheiro que grita lobo. Na terceira, o risco real que você trouxer vai ser descontado exatamente como os anteriores — e o custo desse desconto não é seu, é da empresa.

Existe uma versão mais honesta e mais eficaz: apresentar probabilidade e consequência separadas. “A chance de isso causar indisponibilidade no próximo semestre é baixa, algo entre 10% e 20%. Mas, se acontecer durante fechamento, o impacto é alto e não temos plano de contingência.” Isso é informação. O outro é chantagem emocional com sotaque técnico.

E cabe uma dose de honestidade coletiva para fechar o pilar. Parte da resistência que encontramos não é preconceito contra tecnologia — é histórico. Nós já pedimos reescrita completa que não entregou nada. Já chamamos preferência de arquiteto de necessidade de negócio. Já estimamos três meses para algo que levou onze e nunca voltamos para explicar por quê. Se formos honestos, temos uma parcela real de responsabilidade pela dificuldade que temos hoje em ser levados a sério.

A boa notícia é que crédito se reconstrói exatamente do mesmo jeito que se perde: uma previsão por vez.

Pense comigo — antes de pedir qualquer coisa

• Qual foi a última previsão que eu fiz para essa pessoa, e ela se cumpriu? Se você não lembra, ela lembra. Essa é a sua linha de crédito.

• Estou falando com o interlocutor certo, na moeda dele? Em banco, risco e compliance frequentemente têm mais poder de destravar orçamento do que tecnologia — e quase nunca são procurados.

• Esta é a primeira vez que essa pessoa ouve falar disso? Se for, o pedido é prematuro. Primeiro o tema precisa existir; depois ele vira decisão.

• Estou usando risco como informação ou como pressão? Se a frase precisa de tom dramático para funcionar, o número por trás dela provavelmente é fraco.

Pontos altos do Pilar 5

1. Credibilidade é ativo acumulado, não argumento apresentado. Ela se constrói muito antes da reunião em que você vai precisar dela.

2. Um caso por interlocutor. O caso genérico obriga cada um a traduzir sozinho, e o resultado é decisão nenhuma.

3. Voltar com o número prometido — mesmo quando ele decepciona — vale mais do que superar a meta em silêncio.

O que muda na segunda-feira

Os cinco pilares não são cinco assuntos. São uma sequência única, e ela cabe em cinco perguntas feitas na ordem certa, antes de abrir qualquer slide:

A linha de raciocínio, em cinco perguntas

1. O que é essa dívida, na definição precisa? Distância entre o sistema e o entendimento atual do domínio — não estética. E em que quadrante ela está.

2. Qual é o principal e quais são os juros, em reais e por período? Incluindo o custo de atraso das iniciativas que ela trava.

3. Qual é a minha faixa de 90%, e o que eu explicitamente não sei? Ponto único é promessa; faixa é análise.

4. Essa porta é de uma via ou de duas, e reverter custa quanto? Isso define quem decide e com que velocidade.

5. Eu tenho crédito para pedir isso — e vou voltar com qual número, em quanto tempo?

Repare no que essas perguntas têm em comum: nenhuma delas é sobre convencer. Todas são sobre fazer o trabalho de análise antes de ocupar o tempo de outra pessoa. A persuasão, quando aparece, é consequência — não método.

E vale terminar situando isso no momento que estamos vivendo. Se a IA de fato funciona como amplificador — acelerando quem tem fundamento e multiplicando o caos de quem não tem —, então a capacidade de traduzir risco técnico em decisão de negócio deixou de ser um diferencial de senioridade. Virou requisito. Times vão produzir código mais rápido do que a organização consegue avaliar, e a pessoa capaz de dizer, com número e com faixa de confiança, onde vale a pena desacelerar, passa a ser a mais valiosa da sala.

Quem só souber descrever o problema em termos de engenharia vai continuar tendo o pedido arquivado. Só que agora mais rápido.

A boa notícia — e é uma notícia boa de verdade — é que nada aqui exige talento especial. Exige uma planilha, uma conversa de minutos com quem entende do negócio, e a disciplina de voltar em noventa dias com o resultado. É trabalho, não dom.

Para ir além

• Kruchten, Nord & Ozkaya — Managing Technical Debt: Reducing Friction in Software Development (SEI Series, 2019). A referência definitiva sobre principal, juros e registro de dívida.

• Donald Reinertsen — The Principles of Product Development Flow (2009). Custo de atraso e CD3.

• Douglas Hubbard — How to Measure Anything. Decomposição, intervalos calibrados e valor da informação.

• Forsgren, Humble & Kim — Accelerate. As quatro métricas e a evidência empírica por trás delas.

• Kim, Behr & Spafford — The Phoenix Project. Romance sobre um líder de TI que aprende justamente a traduzir problema de tecnologia em termo de negócio. Boa porta de entrada.

• Michael Feathers — Toward a Galvanizing Definition of Technical Debt (ensaio). A definição que salva a metáfora.

• Martin Fowler — TechnicalDebtQuadrant (bliki) e Steve McConnell — Managing Technical Debt (IEEE Software, 2007).

• Relatórios — DORA 2025 (State of AI-assisted Software Development), CISQ 2022 (Cost of Poor Software Quality), McKinsey (Tech debt: Reclaiming tech equity).