O time pede uma sprint pra pagar dívida técnica. O negócio diz que não dá agora. Isso se repete até alguém desistir ou até quebrar.
A leitura comum do lado da engenharia é que o negócio não entende. Às vezes é. Na maioria das vezes o problema é outro: o argumento apresentado não é decidível.
“O código está ruim” não permite decidir nada. Não tem custo, não tem prazo, não tem alternativa e não tem consequência de não fazer.
Por que “dívida técnica” é um termo ruim nessa conversa
A metáfora é boa entre engenheiros e péssima com quem decide orçamento, porque dívida financeira tem número: valor, juros, prazo.
Quando o time usa a palavra sem os números, quem ouve entende “os engenheiros querem tempo pra deixar o código do jeito que eles gostam”. E, sendo honesto, às vezes é isso mesmo.
Vale separar antes de conversar:
Existe dívida que custa dinheiro todo mês. Essa é argumentável.
Existe dívida que só incomoda quem escreve. Essa é preferência, e ela é legítima, e não compete por orçamento.
Misturar as duas destrói a credibilidade da primeira.
A tradução que funciona
Quatro elementos. Sem os quatro, não é proposta, é reclamação.
O custo que já está sendo pago. Não hipotético, medido.
“Toda alteração no módulo de cobrança leva em média quatro dias em vez de um, porque não tem teste e a gente precisa validar tudo na mão. Foram onze alterações no último trimestre. São 33 dias de engenharia por trimestre pagos em atrito.”
O risco quantificado. Com o que já aconteceu.
“Três dos cinco incidentes do último semestre vieram desse módulo. O de março deixou o checkout fora por 40 minutos.”
O custo de arrumar. Com uma faixa, não com um número falso.
“Duas semanas de uma pessoa pra cobrir o caminho principal com teste. Não resolve tudo, e derruba o tempo de alteração pra um ou dois dias.”
A alternativa de não fazer. Honesta, incluindo o cenário em que não fazer é razoável.
“Se a gente não fizer, continua funcionando. O custo por alteração segue igual e sobe conforme o módulo cresce.”
Com esses quatro, quem decide consegue decidir. Pode até decidir não fazer, e aí é uma decisão informada em vez de uma recusa por incompreensão.
Onde achar os números
A objeção imediata é que ninguém tem esses dados. Quase sempre eles existem espalhados.
Tempo de ciclo por área do sistema, no rastreador de tarefas. Quantos incidentes vieram de cada módulo, no histórico de incidente. Quantas vezes um PR naquele arquivo voltou com correção. Quantas horas de plantão foram gastas ali.
Não precisa de precisão contábil. Precisa de ordem de grandeza defensável. “Cerca de um terço do nosso tempo de manutenção está concentrado em 8% do código” é uma frase que muda reunião.
O timing importa mais que o argumento
Pedir orçamento pra dívida técnica no meio de um trimestre planejado quase nunca funciona, por melhor que seja o argumento.
Os momentos em que funciona:
Logo depois de um incidente, quando o custo está fresco. Não como cobrança, como proposta: “isso vai acontecer de novo, e aqui está o que reduz a chance”.
No planejamento do trimestre, junto com as outras iniciativas, competindo pelo mesmo espaço. Dívida técnica que aparece como item do planejamento é tratada como item. Dívida que aparece como pedido extra é tratada como pedido extra.
E quando existe uma iniciativa de negócio que vai passar por aquela área. “Pra entregar a nova cobrança, a gente precisa mexer nesse módulo. Fazer com a base atual leva seis semanas, arrumando primeiro leva quatro e a segunda entrega fica mais rápida.”
Esse último é o mais eficaz de todos, porque não pede um espaço separado: melhora a entrega que já foi aprovada.
A regra que evita a conversa
O melhor jeito de não precisar pedir sprint de dívida técnica é não acumular ao ponto de precisar.
A regra do escoteiro, deixar o código um pouco melhor do que você encontrou, resolve a maior parte quando aplicada de forma consistente. Não como projeto: como parte do trabalho normal, embutida na estimativa, sem pedir permissão.
Isso exige que a estimativa inclua o cuidado. Se toda estimativa é do caminho feliz e o cuidado precisa ser negociado à parte, a dívida vai acumular por construção. Escrevi sobre isso em estimativa honesta.
O que não fazer
Não faça refatoração grande escondida. Além do risco, quando der problema, o time perde a credibilidade pra pedir da próxima vez de forma aberta.
Não use o argumento do medo sem dado. “Isso vai explodir” repetido por dois anos sem explodir treina quem ouve a descontar.
E não trate toda dívida como urgente. Boa parte do código feio está em área que ninguém toca, e código feio e estável custa quase zero. Priorizar por onde dói é o que faz o argumento ser levado a sério nas vezes em que ele realmente importa.
O ponto de fundo
O negócio não precisa entender de arquitetura. Precisa entender de custo, risco e prazo.
Traduzir isso não é vender a ideia: é fazer com que a decisão possa ser tomada. E é uma das habilidades que mais separa quem executa de quem é chamado antes da decisão, como escrevi em o engenheiro que entende produto.