Dívida técnica: o que é e quanto ela custa para o seu negócio, explicado sem tecniquês
Rafael Oliveira · · 7 min de leitura
O sistema funciona, mas toda mudança pequena demora três semanas. O time de desenvolvimento diz que precisa "refatorar" antes de entregar a funcionalidade nova. O orçamento de uma alteração simples vem com um valor que não faz sentido. E quando alguém pergunta o porquê, a resposta vem cheia de termos que ninguém na sala entende. Se essa cena parece familiar, seu software provavelmente carrega dívida técnica. E, como toda dívida, ela cobra juros. A diferença é que esses juros não aparecem em nenhum boleto: aparecem no prazo que estoura, na funcionalidade que trava e no concorrente que lança antes de você.
Quem já passou por um projeto travado sabe do que estou falando. Neste artigo eu explico o que é dívida técnica sem tecniquês, como ela nasce mesmo em projetos bem-intencionados, quanto ela custa em números que você consegue levar para uma reunião, e o que fazer a respeito.
O que é dívida técnica, na prática
Dívida técnica é toda decisão de desenvolvimento que troca qualidade por velocidade. O time escolhe o caminho mais rápido hoje sabendo que ele vai custar mais caro depois. Às vezes essa escolha é consciente e correta: lançar um MVP em oito semanas com atalhos assumidos é melhor do que lançar o produto perfeito em oito meses. Outras vezes ela é acidental: falta de experiência, pressa mal administrada ou um fornecedor que sumiu deixando o código pela metade.
A analogia financeira funciona bem. O principal da dívida é o trabalho que ficou por fazer: o código mal estruturado, o teste que não existe, a documentação que ninguém escreveu. Os juros são o custo extra de trabalhar em cima dessa base todos os dias: cada funcionalidade nova demora mais, cada correção quebra outra coisa, cada dev novo leva meses para entender o sistema.
E, como no banco, o problema não é ter dívida. Praticamente todo sistema em produção tem. O problema é não saber quanto você deve, nem quanto está pagando de juros por mês.
Como a dívida técnica nasce, mesmo em projetos bons
Ninguém acorda decidindo escrever código ruim. A dívida se acumula por caminhos previsíveis:
- Prazo apertado com escopo cheio. Quando o prazo não cede e o escopo não cede, a qualidade cede. É a única variável que ninguém está olhando na reunião.
- MVP que virou produto definitivo. O sistema foi construído para validar uma ideia em três meses e está rodando há três anos sem nenhuma reforma. Os atalhos que faziam sentido no lançamento viraram fundação.
- Rotatividade de fornecedor. Cada dev ou empresa que passou pelo projeto resolveu do seu jeito. O resultado é um sistema com quatro estilos diferentes, onde ninguém domina o todo.
- Crescimento que ninguém previu. O sistema foi feito para 50 usuários e hoje atende 5.000. Não é culpa de ninguém, mas a estrutura original não aguenta mais.
- Dependências abandonadas. Bibliotecas e versões de linguagem que ficaram para trás. Atualizar dá trabalho, então ninguém atualiza, até que uma falha de segurança ou uma incompatibilidade força a mão no pior momento possível.
Quanto custa: a conta em reais e em risco
Não existe resposta única, mas existe conta certa. A dívida técnica cobra em três moedas, e você consegue estimar cada uma:
1. Horas a mais em cada entrega
Num sistema saudável, uma funcionalidade média sai em, digamos, 40 horas. Num sistema endividado, a mesma funcionalidade leva 70 ou 80, porque o dev precisa entender código confuso, contornar estruturas frágeis e testar manualmente o que deveria ser automático. Se sua empresa paga R$ 120 a hora de desenvolvimento e pede quatro melhorias por mês, essa diferença de 30 a 40 horas por entrega custa entre R$ 14.000 e R$ 19.000 mensais. Só de juros. Sem amortizar nada do principal.
2. Bugs em produção e retrabalho
Sistema sem testes automatizados e com código acoplado quebra em lugares inesperados. Cada bug em produção custa as horas de correção, mais o tempo da sua equipe operando no improviso, mais o cliente que teve uma experiência ruim. Um e-commerce que fica quatro horas fora do ar num dia de campanha sabe exatamente quanto isso custa em faturamento.
3. Velocidade competitiva
Esta é a mais cara e a menos visível. Quando o concorrente lança uma integração em três semanas e você leva quatro meses para a mesma coisa, a dívida técnica virou desvantagem estratégica. Não aparece em nenhuma planilha de custo, mas decide quem ganha o mercado.
Os sinais de que seu sistema está endividado demais
Você não precisa ler código para diagnosticar. Antes de assinar qualquer contrato de evolução ou aceitar mais um orçamento que parece inflado, pergunta isso:
- Toda mudança pequena vem com orçamento grande? Se trocar um texto ou adicionar um campo custa dezenas de horas, algo está errado na base.
- As entregas quebram coisas que já funcionavam? Regressões frequentes indicam ausência de testes automatizados, um dos sintomas mais comuns de dívida.
- Só uma pessoa sabe mexer em partes do sistema? Conhecimento concentrado é dívida com risco embutido. Se essa pessoa sair, o custo explode.
- O time evita mexer em certas áreas do código? Quando o próprio fornecedor tem medo de uma parte do sistema, essa parte é uma bomba com prazo indefinido.
- As dependências estão anos desatualizadas? Peça a lista de versões de linguagem, framework e bibliotecas. Defasagem grande é dívida acumulando juros de segurança.
- Ninguém consegue estimar prazo com confiança? Estimativas que sempre estouram indicam que nem o time sabe o que vai encontrar quando abrir o código.
Três ou mais respostas "sim" significam que a dívida já está ditando o ritmo do seu negócio.
Pagar, renegociar ou dar calote: as três estratégias
O barato que sai caro aqui é o seguinte: ignorar a dívida não a faz desaparecer, só transfere o pagamento para o pior momento. Mas isso não significa que a resposta seja sempre uma grande reforma. Existem três caminhos honestos:
Amortização contínua
Reservar uma fatia de cada ciclo de desenvolvimento, algo entre 15% e 25% das horas, para melhorar a base enquanto entrega funcionalidade. É o caminho certo para a maioria dos sistemas em produção. O custo se dilui, o sistema melhora sem parar a operação, e você nunca precisa vender internamente um projeto de "seis meses sem entregar nada novo".
Reforma dirigida
Quando uma área específica concentra a dor, vale um projeto focado: reescrever o módulo de faturamento, migrar a integração mais frágil, adicionar testes na parte crítica. Escopo fechado, prazo definido, retorno mensurável. Funciona quando o resto do sistema é aproveitável.
Reescrita completa
É a opção mais cara e mais arriscada, e quase sempre é a errada. Só faz sentido quando a tecnologia original está morta, o custo de manter supera o de reconstruir, e o negócio consegue conviver com meses de investimento antes de ver resultado. Antes de aceitar uma proposta de reescrita total, peça a justificativa por escrito e uma segunda opinião. Muitos fornecedores propõem reescrever porque é mais confortável para eles, não porque é melhor para você.
Como cobrar isso do seu fornecedor atual (ou do próximo)
Dívida técnica só se controla com visibilidade. Independente de quem desenvolve seu sistema, você pode exigir:
- Um inventário da dívida. Lista das áreas problemáticas, com impacto e esforço estimado para cada uma. Se o fornecedor não consegue produzir isso, ele não conhece o sistema que mantém.
- Testes automatizados nas partes críticas. Não precisa cobrir tudo, mas fluxo de pagamento, cadastro e integrações principais precisam de rede de proteção.
- Dependências atualizadas com rotina. Atualização pequena e frequente custa pouco. Atualização acumulada de três anos custa um projeto inteiro.
- Documentação mínima de arquitetura. O suficiente para que um dev novo entenda o sistema em dias, não em meses. É o seu seguro contra dependência de uma pessoa só.
Na OCA, boa parte dos projetos que chegam até a gente são sistemas herdados de outros fornecedores, e a primeira entrega é sempre esse diagnóstico: o que existe, o que aguenta evoluir e o que precisa de reforma. Nosso próprio produto, o Revo App, roda com mais de 40 mil usuários e 300 eventos por mês, e ele só sustenta esse volume porque tratamos a amortização da dívida como parte do trabalho, não como luxo. É a mesma disciplina que aplicamos nos sistemas que construímos e mantemos para clientes.
O próximo passo prático
Antes de contratar qualquer coisa, faça o diagnóstico gratuito: passe pelo checklist de seis perguntas acima com quem mantém seu sistema hoje e anote as respostas. Esse documento de uma página já muda a qualidade de qualquer conversa com fornecedor, o atual ou o próximo.
E se você quiser uma avaliação técnica independente do estado do seu sistema, com a conta da dívida traduzida em horas e reais, a gente faz isso antes de propor qualquer projeto.
