Como priorizar tech debt com o PM

O problema

Muita conversa sobre tech debt dá errado antes mesmo da decisão começar.

Engenharia fala:

• “isso precisa ser refeito”
• “essa base está horrível”
• “não dá para continuar assim”

Produto ou PM escuta:

• “vocês querem parar entrega”
• “isso não gera valor agora”
• “estão tentando empurrar refactor infinito”

E pronto.

A conversa vira disputa de agenda em vez de decisão de risco.

Modelo mental

Pensa assim:

dívida técnica só entra na fila direito quando deixa de ser incômodo interno e vira custo explícito para o produto.

Esse custo pode aparecer como:

• bug recorrente
• lentidão para entregar
• risco operacional
• retrabalho toda sprint
• bloqueio para iniciativa importante

Sem essa tradução, a conversa tende a soar moral:

• “o código está feio”
• “isso não é sustentável”

E isso raramente prioriza sozinho.

Quebrando o problema

Nem todo incômodo técnico é dívida técnica relevante

Esse filtro importa.

Tem coisa que é:

• código feio, mas estável
• padrão inconsistente, mas barato de manter
• detalhe arquitetural que irrita, mas não dói no negócio

E tem coisa que já virou cobrança real:

• mexer numa tela quebra outra
• deploy nessa área é sempre arriscado
• mudança pequena demora dias por acoplamento
• incidente sempre volta no mesmo módulo

O segundo grupo merece conversa séria de prioridade.

Produto responde melhor a impacto do que a abstração

Em vez de:

• “precisamos refatorar o módulo”

costuma funcionar melhor:

• “esse módulo está consumindo dois dias extras por entrega e concentrando falha em rollback”
• “se essa parte continuar assim, a iniciativa X vai sair mais lenta e com mais risco”

Você não está simplificando demais.

Está traduzindo.

Dívida técnica grande quase sempre precisa de recorte

Pedido amplo demais costuma perder a disputa.

Algo como:

• “reescrever o fluxo todo”

é difícil de comprar.

Algo como:

• “isolar cálculo de desconto para parar regressão recorrente em campanha”

fica mais negociável.

A melhor discussão não é feature vs debt

Na prática, quase nunca é uma guerra pura entre:

• entregar valor
• cuidar da base

O enquadramento melhor costuma ser:

• que parte da base precisa melhorar para manter entrega saudável?
• qual dívida já está cobrando caro demais?
• qual pedaço reduz risco ou custo sem abrir obra infinita?

Exemplo simples

Imagine um checkout em que toda campanha promocional vira tensão.

Resposta fraca de engenharia:

precisamos refatorar tudo porque o código está muito ruim.

Resposta melhor:

Hoje cada campanha nova mexe no mesmo bloco de desconto e costuma gerar regressão em recibo ou cálculo final. Em vez de pedir reescrita total, eu priorizaria isolar essa regra em um corte menor. Isso reduz risco recorrente e evita que a próxima campanha custe dias extras de validação manual.

Agora a conversa saiu de “feiúra técnica” e virou:

• custo recorrente
• risco conhecido
• corte negociável

Erros comuns

• Chamar qualquer desconforto técnico de dívida prioritária.
• Defender refactor total sem recorte.
• Falar de arquitetura sem traduzir impacto.
• Tratar PM como obstáculo moral à qualidade.
• Usar dívida técnica como justificativa genérica para desacelerar tudo.

Como um senior pensa

Quem está mais maduro normalmente faz duas separações importantes:

• o que é dor estética vs dor operacional
• o que precisa de obra grande vs corte menor e útil

Também costuma entrar na conversa com tradução pronta:

• risco que fica se nada mudar
• ganho concreto do corte proposto
• custo de oportunidade

Isso melhora bastante a aliança com produto porque a decisão deixa de parecer tribal.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador costuma procurar:

• capacidade de priorizar dívida com critério
• tradução de impacto técnico para impacto de negócio
• maturidade para negociar com PM sem cinismo
• noção de recorte em vez de reforma infinita

Uma resposta forte costuma soar assim:

Eu tento não defender tech debt como conceito abstrato. Primeiro separo o que é desconforto técnico do que já virou custo real de entrega, risco ou bug recorrente. Depois traduzo isso para impacto que produto consegue avaliar e proponho um corte menor, negociável, em vez de pedir reescrita total. Assim a conversa vira decisão compartilhada, não guerra entre engenharia e PM.

Dívida técnica mal explicada parece capricho. Dívida técnica bem explicada parece proteção da capacidade futura do produto.