Como você identifica, prioriza e liquida dívida técnica?

Question

Accepted Answer

**Dívida técnica** é a lacuna entre como o código está e como deveria estar, contraída (deliberada ou não) para se mover mais rápido. Um pouco de dívida é aceitável; o trabalho é gerenciá-la, não eliminá-la. A chave é priorizar a dívida que realmente *prejudica*.

## Priorize por impacto, não por incômodo

```text
For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
```

## Um exemplo concreto

Um módulo frágil que quebra a cada lançamento e bloqueia o time semanalmente vale a pena corrigir. Um utilitário feio mas estável que ninguém toca *não*, mesmo que o ofenda. Refatorá-lo é vaidade, não valor.

## Como financiar o trabalho

Spints puros de "dívida" raramente são aprovados. Táticas melhores:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Por que isso importa

Dívida não gerenciada se intensifica: a velocidade diminui silenciosamente até que o time mal consiga entregar.

Mas perseguir cada imperfeição desperdiça tempo em dívida que não importa.

O valor de um TL é conhecer a diferença e fazer o caso à liderança em termos de *negócio*, não apenas de engenharia.