Dívida Técnica de Gente: o Que É e Como Evitar

Todo mundo entende o que é dívida técnica em código: atalho tomado sob pressão de prazo, que cobra juros depois, na forma de retrabalho. Poucos aplicam a mesma lógica para squads. Quando um time é formado rápido demais, sem curadoria real, o passivo é o mesmo, só que em gente: turnover, retrabalho e conhecimento que ninguém documentou.

Este artigo aprofunda o conceito de dívida técnica de gente, mostra como quantificá-la antes que vire prejuízo, e o que fazer para pagar essa dívida antes que ela comprometa a entrega. Para o cenário completo de mercado por trás desse risco, o [LINK INTERNO SUGERIDO] Guia de Alocação de Squads de TI e Recrutamento com IA traz o contexto de escassez de talentos que torna esse problema mais comum.

O que é dívida técnica de gente

O paralelo com dívida técnica de código não é força de expressão, é estrutural. Nos dois casos, uma decisão tomada sob pressão de prazo parece resolver o problema imediato, mas empurra um custo maior para o futuro. A diferença é que dívida técnica de código aparece em métricas de engenharia. Dívida técnica de gente aparece em turnover, retrabalho e decisões apressadas que ninguém documentou.

Um cenário comum: uma empresa precisa de um squad formado em duas semanas para atender um prazo de negócio. A triagem é acelerada, a curadoria técnica fica superficial, e o squad começa a trabalhar. Nos primeiros meses, tudo parece funcionar. Só que decisões de arquitetura importantes vão sendo tomadas sem revisão adequada, e ninguém percebe até o primeiro incidente sério de produção, quando fica claro que ninguém no squad tinha autoridade real para questionar aquelas escolhas antes.

Como esse passivo se acumula

Raramente é um evento único. É uma sequência de pequenas decisões que, isoladas, parecem razoáveis.

• Contratar rápido demais, sem avaliação prática de competência. A entrevista de currículo passa, mas ninguém testou se a pessoa sabe fazer o que o cargo exige.
• Não nomear um tech lead com autoridade real. Decisões técnicas ficam sem dono, e cada integrante do squad decide sozinho, sem revisão.
• Não documentar decisões de arquitetura. O conhecimento fica só na cabeça de quem tomou a decisão, e some quando essa pessoa sai.
• Medir o squad só por hora alocada. Sem métrica de entrega, ninguém percebe a queda de qualidade até ela virar incidente de produção.

Cada um desses pontos, isolado, parece um detalhe administrativo. Somados, formam o mesmo tipo de passivo que um sistema legado acumula quando ninguém paga o preço de fazer certo na hora certa.

A diferença entre um squad saudável e um squad endividado raramente aparece no primeiro mês. Aparece quando o time já cresceu, já passou por pelo menos uma troca de profissional, e alguém pergunta “por que decidimos fazer dessa forma” sem que ninguém consiga responder com segurança.

Como colocar um número nesse risco

Assim como débito técnico em código pode ser quantificado (horas de retrabalho estimadas, incidentes gerados, tempo de manutenção acima do esperado), dívida técnica de gente também pode.

O custo de substituir um profissional de tecnologia pode chegar a 1,5 a 2 vezes o salário anual dele, considerando tempo de ramp-up, perda de contexto e produtividade reduzida da equipe ao redor durante a transição. Esse número normalmente não entra na conta de quem está comparando propostas só pelo valor da hora alocada.

Vale aplicar essas quatro perguntas antes de assinar qualquer contrato de squad: qual o tempo médio de rampagem que o fornecedor entrega historicamente, quanto do conhecimento crítico fica documentado fora da cabeça das pessoas, qual o turnover real nos últimos 12 meses, e quem tem autoridade explícita para barrar uma decisão técnica ruim.

Quem dentro da empresa deveria acompanhar esse indicador

Na maioria das empresas, dívida técnica de código é acompanhada pelo time de engenharia. Dívida técnica de gente costuma ficar sem dono, dividida entre RH (que olha turnover) e liderança técnica (que olha entrega), sem ninguém juntando os dois lados da mesma métrica.

Faz sentido que CTOs e Heads de Engenharia tratem esse indicador com a mesma seriedade que tratam débito técnico de código: com revisão periódica, não só quando o problema já virou incidente visível.

O papel da IA no recrutamento nesse problema

A IA no recrutamento promete acelerar a triagem, e de fato acelera. Mas quando a triagem inteira depende de IA, sem curadoria humana na etapa final, o risco de formar um squad sem o perfil certo aumenta, não diminui.

Candidatos também usam IA para otimizar currículos e respostas de entrevista, o que infla artificialmente o volume de candidaturas. O resultado é um loop: IA gera conteúdo de candidatura, IA avalia esse conteúdo, e a pessoa real por trás do perfil pode nunca ser avaliada com profundidade suficiente antes de entrar no squad.

Squads formados nessas condições já nascem carregando parte da dívida técnica de gente, antes mesmo do primeiro dia de trabalho. O problema não é a ferramenta, é a ausência de julgamento humano na decisão final.

Isso não significa abrir mão da IA no processo. Significa definir claramente onde ela acelera (triagem inicial de volume, organização de currículos, agendamento) e onde a decisão continua precisando de avaliação humana com critério, principalmente na etapa final de avaliação técnica prática.

Como pagar essa dívida antes que ela vire prejuízo

Nomeie um tech lead com autoridade explícita. Autoridade real significa poder dizer não a uma decisão técnica ruim, mesmo sob pressão de prazo, não apenas ter o título no organograma.

Documente decisões de arquitetura no momento em que são tomadas. Esperar para documentar “quando der tempo” quase sempre significa nunca documentar.

Meça entrega, não só presença. Velocity, qualidade de código e tempo de ciclo revelam problemas que horas faturadas escondem.

Inclua avaliação prática de competência antes de qualquer contratação. Currículo bem escrito, com ou sem ajuda de IA, não substitui teste de capacidade real.

Trate turnover como métrica de saúde do squad, não como estatística isolada de RH. Turnover recorrente sem investigação da causa tende a se repetir, e cada repetição aumenta o passivo acumulado.

Faça sobreposição na troca de profissionais críticos. Um período curto de transição, com quem está saindo e quem está entrando trabalhando junto, custa mais no curto prazo, mas evita perder de vez o conhecimento que só existia na cabeça de uma pessoa.

Perguntas frequentes sobre dívida técnica de gente

Dívida técnica de gente é a mesma coisa que turnover alto?

Não exatamente. Turnover alto é um dos sintomas. Dívida técnica de gente é o conceito mais amplo, que inclui também retrabalho, decisões apressadas e conhecimento não documentado.

Como saber se meu squad atual já tem esse problema?

Sinais comuns incluem rampagem lenta de novos integrantes, decisões técnicas sem dono claro, e contrato medido só por hora alocada, sem métrica de entrega acompanhada.

IA no recrutamento sempre aumenta o risco de dívida técnica de gente?

Não por si só. O risco aumenta quando a triagem depende inteiramente de IA, sem curadoria humana na decisão final. Com supervisão adequada, a IA pode reduzir esse risco, não aumentá-lo.

Vale a pena investir em documentação mesmo com prazo apertado?

Sim. O custo de documentar no momento da decisão é muito menor do que o custo de reconstruir esse conhecimento depois que a pessoa que o detinha já saiu do squad.

Dívida técnica de gente pode ser revertida, ou o dano é permanente?

Pode ser revertida, mas exige investimento deliberado: documentação retroativa do que ainda é possível recuperar, nomeação de autoridade técnica clara, e mudança na forma de medir o squad, de presença para entrega.

O preço de ignorar essa dívida sempre aparece, só demora

Dívida técnica de gente não é um risco abstrato. É um custo real que, como qualquer dívida, cresce enquanto ninguém paga. A diferença entre squads que entregam resultado consistente e squads que vivem apagando incêndio geralmente está em quem percebeu esse passivo antes que ele virasse prejuízo visível.

A pergunta que vale levar para a próxima reunião de squad não é “estamos entregando rápido”. É “estamos acumulando um passivo que ainda não apareceu no relatório, mas já está lá”.