Como você decide quanto tempo gastar com dívida técnica versus novas funcionalidades?

Trate dívida como custo de negócio, não como questão moral. Quantifique: quanto ela deixa a entrega mais lenta, quantos incidentes causa, o que acontece se falhar. Depois financie isso na mesma conversa das funcionalidades, seja como alocação fixa (muitas vezes quinze a vinte por cento), seja atrelada ao trabalho de roadmap que toca aquela área. Pague a dívida que realmente está cobrando juros, não o código de que você não gosta.

Eu me recuso a conduzir isso como um argumento moral separado, porque engenharia sempre perde essa briga. Transformo em conversa de custo. Mantemos um registro de dívida com uma estimativa do que cada item nos custa: este serviço adiciona dois dias a toda funcionalidade que o toca, aquele causou quatro dos últimos dez incidentes, esta dependência sai de suporte em nove meses e trava uma renovação de compliance. Depois priorizo por taxa de juros e não por quão feio o código é, porque muito código horrível é estável, ninguém encosta nele e pode ficar assim para sempre. Sobre financiamento, meu padrão são vinte por cento fixos mais limpeza atrelada ao trabalho de roadmap, então se já estamos naquela área, arrumamos enquanto estamos lá. O argumento que pega com produto é sempre o de entrega. No meu último time, eu conseguia mostrar que dois terços do nosso tempo de incidente vinham de um caminho legado, e uma vez enquadrado como perdemos uma semana por mês com isso, as seis semanas de conserto viraram venda fácil em vez de briga.