Como você explica dívida técnica para um público não técnico?

Question

Accepted Answer

**Traduzo tech debt para a linguagem que o público já usa: dinheiro, velocidade e risco.** Um stakeholder não técnico não se importa com acoplamento ou cobertura de testes; ele se importa que as features estão ficando mais lentas e mais caras de entregar. Então enquadro a dívida como um problema financeiro e de entrega, não como um problema de código.

## O enquadramento que uso

- **A metáfora financeira, usada com cuidado.** "Pegamos um atalho para entregar rápido, como pegar um empréstimo. Funcionou, e agora pagamos juros sobre isso a cada sprint. Cada feature nova nessa área custa mais por causa desses juros." Isso pega porque todo mundo entende dívida e juros.
- **Torne concreto com as métricas deles.** Não "o código está bagunçado", mas "esta feature levou três semanas; dois anos atrás o mesmo tamanho levava uma. A diferença é o overhead de manutenção que acumulamos."
- **Atrele a resultados que importam para eles.** Entrega mais lenta, mais bugs chegando aos clientes, onboarding mais difícil para novos contratados, risco crescente de uma queda. Conecte a dívida a receita, reputação e velocidade do roadmap.

## Como transformo isso em uma decisão, não uma reclamação

- Apresento como um **trade-off com opções**, não uma exigência: "Podemos continuar entregando features no ritmo cada vez mais lento atual, ou investir dois sprints agora para cortar o custo de features futuras em cerca de um terço."
- Quantifico onde posso: tempo perdido por sprint, frequência de incidents, o percentual de capacidade gasto apagando incêndios.
- Sou honesto que **alguma dívida é aceitável.** Nem toda dívida precisa ser paga; o ponto é pagar a dívida que está ativamente taxando a entrega.

## Armadilhas

- **Usar jargão** ("refatorar", "acoplamento", "a arquitetura está errada"). Isso faz você parecer querer fazer gold-plating no código.
- Enquadrar como engenheiros querendo código limpo por si só; isso soa como autoindulgência.
- Gritar lobo — chamar tudo de dívida corrói a credibilidade quando algo realmente urgente aparece.

## Por que isso importa

Se você não consegue explicar tech debt em termos de negócio, ela nunca é financiada, e o time lentamente trava enquanto a liderança se pergunta por que a velocidade está caindo. Enquadrá-la como custo, velocidade e risco é o que lhe dá o tempo para consertá-la antes que vire uma crise.