Dívida técnica: o guia do fundador não-técnico (4 tipos, diagnóstico)

Numa quarta-feira de novembro, num escritório em Pinheiros, um fundador de uma fintech em Series A ouviu a mesma frase pela terceira vez no mês: “a gente precisa parar de fazer feature por seis semanas e pagar a dívida técnica”. Era a primeira vez que ele entendeu que aquilo era um problema dele, não do tech lead. Os investidores estavam pedindo um plano de produto para os próximos doze meses. O time de engenharia estava pedindo seis semanas paradas. Os dois pedidos colidiam, e cabia a ele decidir.

Esse é o ponto exato em que a maioria dos fundadores não-técnicos descobre o que é dívida técnica. Tarde demais para evitar, cedo demais para entender o que está sendo proposto.

O que é dívida técnica, em linguagem de fundador

Dívida técnica é toda escolha de engenharia que troca qualidade futura por velocidade hoje. Você escreve o código mais rápido agora, sabendo que vai pagar a diferença depois: em manutenção, em bugs, em refactor, ou em um engenheiro novo que demora três semanas para entender o que está acontecendo.

O termo foi cunhado por Ward Cunningham nos anos 90, e a metáfora é precisa. Igual à dívida financeira, dívida técnica tem juros. Cada release feito em cima de uma fundação ruim adiciona um pouquinho mais de fricção, um pouquinho mais de tempo, um pouquinho mais de risco. Se você nunca paga, os juros engolem a velocidade do time. Se você paga sempre, está deixando velocidade na mesa que poderia estar investida em produto.

“Dívida técnica” e “débito técnico” são a mesma coisa em português. São duas traduções do mesmo termo (technical debt), usadas de forma intercambiável no mercado brasileiro. Não se prenda à terminologia. Se um engenheiro fala de débito e outro fala de dívida, eles estão falando do mesmo conceito.

O que importa para o fundador não é a definição acadêmica. É entender que dívida técnica nunca é uma surpresa criada pelo time. Ela é o subproduto de decisões que foram tomadas, explícita ou implicitamente, para você poder fazer a demo do investidor, fechar o primeiro cliente, lançar o piloto antes do concorrente. A dívida não apareceu por incompetência. Apareceu porque alguém priorizou velocidade. Provavelmente você.

Por que isso vira problema seu, não do CTO

Três coisas mudam quando a dívida técnica deixa de ser uma conversa de engenharia e vira uma conversa de empresa.

A primeira é o ritmo de release. Times com dívida pesada começam a sentir cada feature ficar mais lenta. O que costumava sair em duas semanas começa a sair em quatro. Não porque os engenheiros ficaram piores. Porque cada vez mais do tempo deles é gasto desviando de armadilhas que o código antigo deixou.

A segunda é o risco de contratação. Times com dívida pesada são difíceis de ampliar. Quando você quer dobrar o squad para acelerar, descobre que o engenheiro novo precisa de seis semanas para conseguir abrir um pull request sem quebrar três coisas. Sua taxa de onboarding desaba. Você acha que está caro contratar; na verdade está caro fazer ramp-up.

A terceira é o risco de due diligence. Numa rodada de Series A ou numa aquisição, o investidor contrata uma consultoria de due diligence técnica. Ela passa quatro dias dentro do seu repositório, conversa com o time, e produz um documento que diz se a base de código suporta os próximos vinte e quatro meses ou não. Se a dívida estiver alta demais, o investidor pode pedir desconto na valuation. Pode pedir milestones de “pagamento de dívida” antes do tranche seguinte. Em casos raros, pode desistir.

Nenhum desses três efeitos é técnico. Todos são de negócio. E todos chegam ao fundador antes ou depois.

Os quatro tipos de dívida técnica que importam

Martin Fowler, um dos pesquisadores que mais escreveu sobre o tema, criou uma matriz de dois eixos que separa as quatro situações em que dívida técnica aparece. Para o fundador, a matriz é útil porque ela responde uma pergunta única e importante: meu time está fazendo isso de propósito, ou está fazendo isso por descuido? Essa pergunta divide a dívida “estratégica” (que você pode estar feliz de carregar) da dívida “perigosa” (que está te custando dinheiro silenciosamente).

1. Deliberada e estratégica: “sabemos o que estamos fazendo, e vamos pagar depois”

O time escolheu, consciente, escrever código mais simples e mais rápido porque precisava chegar a algum lugar primeiro. Talvez a demo do TechCrunch, talvez o piloto com a Localiza, talvez o release antes do feriado. Eles documentaram a escolha. Sabem onde está o atalho. Têm uma data, mesmo que aproximada, para voltar e fazer direito.

Essa é a dívida que você quer na empresa nos primeiros dezoito meses. Sem ela, você não chega no PMF a tempo.

2. Deliberada e imprudente: “sabemos o que estamos fazendo, e nunca vamos pagar”

O time escolheu o atalho, sabe que é atalho, e está convencido de que dá tempo de quebrar três coisas até o release. Muitas vezes essa dívida vem do próprio fundador: “preciso disso para sexta-feira, dá um jeito”. O time avisa que é uma má ideia. Você diz “depois a gente arruma”. Não arruma.

Esse é o tipo mais comum e mais caro. Não porque ele é o pior tecnicamente, mas porque o “depois” nunca chega. E porque ele se acumula em silêncio: você não vê a dívida no balanço. Vê só a feature pronta.

3. Acidental e estratégica: “agora a gente sabe como deveria ter feito”

O time fez o melhor que sabia na época, com a informação que tinha. Aprendeu mais sobre o problema, sobre a arquitetura, sobre os usuários, e hoje faria diferente. Não é descuido, é a curva de aprendizado natural de qualquer produto novo.

Essa dívida você vai ter, sempre. A pergunta certa para esse tipo não é “como evito?”. É “quando volto e refaço?”. E a resposta honesta é: quando a feature que está em cima da fundação errada começar a custar mais para evoluir do que para reescrever.

4. Acidental e imprudente: “nem sabemos que isso é dívida”

O time não sabe que escolheu um caminho ruim. Não documentou nada. Vai descobrir o problema na próxima vez que precisar mexer naquele pedaço do código, e a próxima pessoa que mexer vai sofrer sem entender o porquê. É a categoria mais perigosa porque é invisível. Você só percebe quando alguém pede demissão e o conhecimento sai com a pessoa, ou quando o novo dev sênior abre o repositório e respira fundo.

A diferença entre os tipos 2 e 4 é onde mora o trabalho do fundador. Tipo 2 você consegue rastrear conversando com o time. Tipo 4 você precisa de uma due diligence interna para descobrir, e quase nenhum fundador faz isso antes de a fatura chegar.

O diagnóstico de quatro perguntas

Você não precisa fingir profundidade técnica para descobrir quanta dívida o seu produto carrega. Precisa de quatro perguntas, vinte minutos com cada engenheiro, e a coragem de ouvir as respostas sem se defender.

Pergunta 1: “Qual é o pedaço do código que ninguém quer mexer?”

Toda base de código tem um. Pode ser o módulo de pagamento, o sistema de autenticação, o motor de cálculo de comissões. O que você está procurando é o nome próprio. Se três engenheiros respondem o mesmo nome, esse é o coração da sua dívida acidental imprudente.

Pergunta 2: “Quantas vezes na última sprint a gente fez um workaround porque a solução certa demoraria muito?”

Essa pergunta detecta dívida deliberada, a do tipo 2. A resposta saudável é “uma, e a gente abriu um ticket para refazer”. A resposta de alerta é “umas três ou quatro, mas nenhum ticket”. Workaround sem ticket é dívida que não vai ser paga.

Pergunta 3: “Se a gente quisesse dobrar o time amanhã, quantas semanas até o novo engenheiro abrir o primeiro PR?”

Times saudáveis respondem entre uma e duas semanas. Times com dívida alta respondem entre quatro e oito. Acima disso, sua dívida não é mais um problema de produto. É um problema de ampliação do time.

Pergunta 4: “Se a gente perdesse o engenheiro X, qual é o pedaço do produto que ficaria órfão?”

Essa pergunta é o cruzamento entre dívida técnica e bus factor. Conhecimento não-documentado é dívida acidental imprudente, e ele desaparece com a pessoa. Se a resposta é “metade”, você tem dois problemas, não um.

As quatro perguntas, somadas, dão um mapa razoável do estado da sua base de código. Não é uma due diligence técnica formal. Mas é o suficiente para você decidir, com cabeça fria, se o time precisa de seis semanas paradas para pagar dívida ou se está pedindo seis semanas paradas para reescrever coisa que funciona.

Quando pagar, quando carregar, quando ignorar

Nem toda dívida deve ser paga. Esse é o erro que a maioria dos fundadores faz na direção oposta: depois de entender o conceito, eles ficam ansiosos para “zerar a dívida”. Não é assim que funciona.

Carregue a dívida que está estável. Se um pedaço do código é meio bagunçado mas ninguém precisa mexer nele há seis meses, não toque. A regra é simples: a dívida só tem custo se você está pagando juros. Código que ninguém abre não tem juros.

Pague a dívida que está no caminho do roadmap. Se o próximo trimestre vai exigir mudanças no módulo X, e o módulo X é uma bagunça, vale pagar a dívida antes, porque você ia pagar pelo refactor de qualquer jeito, embutido na feature, sem visibilidade.

Refaça (não pague) a dívida que está bloqueando crescimento. Se o sistema de autenticação não suporta mais de mil usuários simultâneos, ou se o motor de cálculo demora três horas para rodar com cinco mil clientes, isso não é dívida. É arquitetura que precisa ser substituída. Você não está pagando juros. Está num beco sem saída. A conversa aí vira reescrita de software, que é uma decisão diferente e bem mais cara.

A heurística que costumamos usar quando trabalhamos com fundadores não-técnicos: olhe a dívida pelo lado do roadmap, não pelo lado do código. O que vai ser tocado nos próximos noventa dias, e está difícil de tocar? Isso é o que vale pagar. O resto é cosmética.

A conversa que precisa acontecer com o time

A conversa errada começa assim: “vocês podem me dar uma estimativa de quanta dívida técnica a gente tem?”. Você não vai conseguir resposta útil. Ninguém sabe quantificar dívida em horas ou em reais com precisão. O time vai chutar, você vai duvidar do chute, e a conversa não vai a lugar nenhum.

A conversa certa começa diferente. Pegue o roadmap dos próximos noventa dias. Para cada item, pergunte: “esse item vai mexer em algum pedaço onde a gente tem dívida que vale resolver antes?”. Se a resposta for sim para três ou quatro itens no mesmo módulo, esse é o pedaço onde você quer investir um sprint de refactor antes de seguir.

Essa conversa funciona porque ela amarra dívida ao que está sendo construído. Não é “pare tudo e arrume o passado”. É “vamos investir uma semana agora para fazer o próximo trimestre andar mais rápido”. Investidores entendem essa linguagem. Cofundadores entendem. Você consegue defender no board.

E ela tem um efeito secundário: ela obriga o time a apontar dívida específica, não dívida genérica. “A gente tem dívida no módulo de pagamentos que vai pesar nos três próximos projetos” é uma frase acionável. “A gente tem muita dívida técnica” não é.

O que muda quando você terceiriza o desenvolvimento

Se você não tem um time interno, e o seu produto está sendo construído por uma software house ou um parceiro de desenvolvimento, a dinâmica da dívida muda em dois pontos importantes.

O primeiro: dívida acidental imprudente é mais difícil de detectar. O time externo não está no seu Slack todo dia, então a pergunta “qual o pedaço do código que ninguém quer mexer?” precisa ser feita com mais frequência, e a resposta tem que vir com prints, commits, exemplos. Confie em dado, não em sensação.

O segundo: dívida deliberada estratégica é mais fácil de carregar, porque um parceiro experiente já vai te dizer, antes de cada release, o que está sendo deixado para trás e por quê. Bons parceiros fazem isso por hábito. Maus parceiros entregam o produto e somem. A diferença entre os dois aparece exatamente nessa transparência: você sabe ou não sabe onde está a dívida quando o release sai?

A regra que aplicamos quando construímos software para fundadores não-técnicos é simples: toda decisão de tomar dívida deliberada estratégica tem que ser registrada em uma frase no PR, e tem que aparecer no documento mensal de status. Se você não tem isso, está no escuro. Não é o parceiro que está mal-intencionado; é o processo que está mal-desenhado.

Quando dívida técnica vira problema de custo de manutenção

O custo de manutenção mensal do seu produto é, em parte, o pagamento dos juros da dívida que você tomou. Se o seu time gasta sessenta por cento do tempo “consertando coisas” e quarenta por cento “construindo coisas”, a maior parte desses sessenta por cento são juros, não bugs.

Times saudáveis ficam perto de oitenta-vinte (oitenta construindo, vinte consertando). Times com dívida pesada chegam invertido, sessenta-quarenta. Times em estado crítico chegam em vinte-oitenta, e a essa altura você não está mais construindo produto, está mantendo um esqueleto vivo enquanto seus concorrentes shipam features.

O ratio é uma das coisas mais fáceis de medir e uma das mais subestimadas. Se você não sabe qual é o seu, pergunte ao time. Eles sabem. Provavelmente já sabem há meses.

Perguntas frequentes

O que é uma dívida técnica?
É toda escolha de engenharia que troca qualidade futura por velocidade hoje. Como uma dívida financeira, ela tem juros: cada release feito em cima de uma fundação ruim adiciona um pouquinho mais de tempo, fricção e risco. Pode ser deliberada (você escolheu o atalho) ou acidental (o time aprendeu depois que poderia ter feito diferente).

Qual a diferença entre débito técnico e dívida técnica?
Não tem. “Débito técnico” e “dívida técnica” são duas traduções do mesmo termo em inglês (technical debt) e são usadas como sinônimos no mercado brasileiro. Se um engenheiro fala em débito e outro em dívida, eles estão falando da mesma coisa.

Quais são os tipos de débito técnico?
A matriz mais usada é a de Martin Fowler, que cruza dois eixos: deliberado/acidental e estratégico/imprudente. Isso dá quatro tipos: deliberado e estratégico (você escolheu o atalho e vai pagar), deliberado e imprudente (você escolheu o atalho e não vai pagar), acidental e estratégico (você aprendeu depois e refaz quando vale), acidental e imprudente (o time nem sabe que existe dívida ali). Os tipos 2 e 4 são os que mais machucam o fundador não-técnico.

O que é inadimplência técnica?
Não é um termo padrão na engenharia. Quem busca isso geralmente está confundindo com “dívida técnica”. O conceito de inadimplência (não pagamento de dívida financeira) não tem equivalente direto em engenharia de software. O fenômeno análogo é “dívida não-paga acumulando juros”, o que descrevemos ao longo deste artigo.

Quanto tempo leva para pagar dívida técnica?
Não tem resposta única. Depende do tamanho da base, do tipo de dívida e do quanto do roadmap futuro a atravessa. Uma regra prática que usamos: se uma área específica está bloqueando três ou quatro itens dos próximos noventa dias, invista uma a duas semanas de sprint focado nela antes de seguir. Tentativas de “pagar toda a dívida” em um esforço único raramente funcionam: o time perde meses e o backlog de produto congela.

A maioria dos fundadores não-técnicos descobre o conceito de dívida técnica na pior hora: quando o time pede para parar, quando o investidor pede para acelerar, ou quando uma due diligence aponta um problema que ninguém viu chegar. O fundador que decide bem nesse momento não é o que entende mais de código. É o que sabe ler a dívida como uma decisão de negócio e fazer a pergunta certa para o time: o que dos próximos noventa dias está mais difícil porque a gente não pagou ainda?

Esse fundador não precisa ser técnico. Precisa ser claro.