A dívida técnica visível: mapear e priorizar com evidência
A dívida técnica só aparece quando explode, num incidente ou numa feature que devia levar dias e leva semanas. A IA mapeia essa dívida com evidência conferível; priorizar o que pagar agora continua sendo julgamento de negócio seu.
Há meses o time repete a mesma frase nas retros: "aquele módulo de faturamento é uma bagunça, um dia vai explodir". Ninguém aponta onde exatamente, quanto custa manter, ou o que vai estourar primeiro. É opinião compartilhada, não um mapa. Aí alguém pede pra IA varrer o repositório inteiro e listar onde a lógica se repete, quais dependências estão desatualizadas com vulnerabilidade conhecida, e qual módulo tem a pior cobertura de teste. O relatório sai com arquivo, linha e número. A pergunta que sobra não é mais "o que está ruim", é "o que dessa lista custa caro agora, e o que pode esperar".
O escritório convive com a lenda de que "o sistema de gestão de prazos processuais falha às vezes", sem saber quando nem por quê. A IA varre os registros de erro da ferramenta e aponta que as falhas se concentram exatamente nos processos que têm mais de uma instância, porque a lógica de cálculo de prazo nunca foi atualizada pra tratar prazo recursal corretamente. O achismo virou uma categoria específica de processo com uma causa técnica nomeada. Priorizar o conserto antes ou depois de outra entrega do fornecedor da ferramenta continua sendo decisão de quem responde pelos prazos, não da varredura.
Todo mundo no time de gente e gestão comenta que "o sistema de avaliação de desempenho trava toda temporada de ciclo", mas ninguém tinha medido o tamanho do problema. A IA varre os chamados de suporte interno da ferramenta e aponta que 40% deles se concentram numa única funcionalidade, a de calibração cruzada entre gestores, sempre na mesma semana do ciclo. O achismo virou um padrão datado e localizado. Mas decidir se vale investir num conserto agora ou esperar o próximo fornecedor de RH ser avaliado é chamada de negócio, não da varredura.
A equipe de produto sempre soube que "o onboarding do app está com uma taxa de erro estranha", sem saber onde. A IA varre os logs de erro do fluxo de onboarding e aponta que 22% das falhas se concentram numa única tela de verificação de documento, associada a uma biblioteca de terceiro que mudou o formato de resposta há dois meses sem aviso. O achismo virou uma tela específica e uma causa provável. Só que decidir se conserta agora ou espera a migração de fornecedor já planejada pro próximo trimestre depende do impacto real na conversão, não da varredura em si.
O time comercial reclama que "o CRM está lento e trava direto", sem saber apontar onde. A IA varre os relatórios de performance do sistema e aponta que uma consulta específica, usada toda vez que alguém abre o histórico de um cliente, demora doze vezes mais que a média, porque busca em uma tabela sem índice adequado desde uma migração de dois anos atrás. O achismo virou um ponto exato, com o tempo de resposta medido. Decidir se essa correção entra nesta sprint ou espera depende de quanto tempo comercial perde por dia com isso, um cálculo que é seu, não da IA.
A operação convive há meses com a fama de que "o sistema de roteamento de entrega é instável no fim do dia", sem saber a causa. A IA varre os logs de erro e aponta que o problema se concentra numa função que recalcula rotas, cuja complexidade cresceu tanto ao longo dos anos que ela hoje testa mais de 40 condições diferentes numa única chamada, um sinal clássico de complexidade acumulada sem refatoração. O achismo virou uma função nomeada, com o número de condições que ela testa. A decisão de parar a operação pra refatorar isso, ou empurrar pro próximo trimestre, é chamada de negócio.
A área de risco convive com o rumor de que "o sistema de consentimento de dado tem furo", sem detalhe nenhum. A IA varre o código e aponta que existe uma rota de API antiga, sem uso documentado no fluxo atual, que ainda aceita requisição sem verificar o consentimento do titular, um remanescente de uma versão anterior do produto. O achismo virou uma rota específica, com o arquivo e a ausência exata de verificação. Decidir se isso é crítico o bastante pra travar outra entrega desta semana é julgamento do responsável por risco, não da varredura.
O time de design convive com a impressão de que "o app fica pesado depois de um tempo de uso", sem saber apontar onde. A IA varre o código da tela principal e aponta que um componente de lista carrega todos os itens de uma vez, sem paginação, desde que a base de usuários era dez vezes menor, e hoje isso derruba a performance em aparelhos mais antigos. O achismo virou um componente específico com a causa exata. Mas decidir se essa correção entra antes ou depois do redesenho já planejado da tela é chamada de prioridade que cabe ao time, não à varredura que só apontou o sintoma.
O board sempre ouviu dizer que "a plataforma de análise de mercado está desatualizada" sem nenhum número que sustente isso numa decisão de investimento. A IA varre o histórico de manutenção da plataforma e aponta que 60% dos relatórios gerados no último trimestre precisaram de correção manual antes de ir pro board, um retrabalho que nunca tinha sido medido. O achismo virou um número que justifica, ou não, investir num redesenho antes do próximo ciclo de planejamento. A decisão de priorizar esse investimento, olhando o retorno contra outras apostas do trimestre, continua sendo do board, não da IA.
Putz, toda equipe de tecnologia tem aquele módulo do qual todo mundo fala mal nos corredores e ninguém consegue explicar direito o tamanho do problema. "Isso aqui é uma bomba-relógio" é a frase, e ela é opinião, não diagnóstico. Pensa comigo: quanto tempo o seu time já perdeu discutindo se vale a pena mexer numa dívida que ninguém sabe medir? A dívida técnica não é mistério, ela é só invisível até você olhar com a ferramenta certa.
A ideia central desta aula. A dívida técnica fica invisível até estourar, num incidente ou numa entrega que devia levar dias e leva semanas, porque ninguém rastreia ela sistematicamente. A IA muda esse jogo: ela varre o sistema e devolve evidência conferível, arquivo e linha de lógica duplicada, número de CVE de uma dependência velha, percentual de cobertura de teste de um módulo crítico. Isso troca achismo por mapa. Mas o mapa não decide sozinho o que pagar primeiro. Nem toda dívida pesa igual, e priorizar com julgamento de negócio, olhando o risco real de cada item, continua sendo seu.
Qual é a diferença entre o achismo de dívida técnica ('esse módulo é uma bagunça') e o mapa que a IA produz?
Não conta nota. É para você ver o que já pensa — a aula responde logo abaixo.
01Por que a dívida fica invisível até estourar
Dívida técnica tem uma característica cruel: ela não manda aviso. Ninguém abre um ticket dizendo "hoje a dívida técnica do módulo X aumentou 3%". Ela só aparece de dois jeitos, e os dois custam caro. O primeiro é o incidente: o sistema quebra numa hora ruim e, investigando, descobre-se que a causa era uma fragilidade conhecida havia meses, só que ninguém tinha priorizado. O segundo é mais sutil: uma feature que devia levar três dias leva três semanas, porque o código em volta dela é um campo minado que ninguém quer tocar sem cuidado redobrado.
Lembra do porém mortal que abriu este módulo: velocidade sem revisão vira dívida e incidente. É exatamente aqui que ele aparece na prática. Cada atalho, cada correção apressada, cada código gerado rápido e aceito sem revisão profunda, vai empilhando numa conta que ninguém está olhando, até que ela vence de uma vez, na pior hora possível.
O problema não é a dívida existir, toda operação real tem alguma. O problema é ela ser invisível. Sem visibilidade, o time só reage depois que ela já cobrou o preço.
02O que a IA faz bem: varrer e apontar evidência
Aqui a IA é excelente, porque o trabalho é justamente o tipo que ela cobre bem: varrer um volume de código que nenhuma pessoa releria inteiro, e apontar padrões concretos, com referência que dá pra conferir. Repara na palavra: evidência, não opinião.
- Duplicação de lógica, com arquivo e linha. A mesma regra de negócio escrita de formas levemente diferentes em lugares diferentes, cada cópia um risco de divergir da outra na próxima correção.
- Dependência desatualizada, com CVE. Uma biblioteca presa numa versão antiga, com uma vulnerabilidade catalogada publicamente, algumas com nível de gravidade documentado.
- Cobertura de teste baixa, com percentual. Um módulo crítico (o que calcula dinheiro, o que autentica gente, o que processa dado sensível) rodando com pouco ou nenhum teste automatizado protegendo ele.
- Complexidade acumulada, com o ponto exato. Uma função que, ao longo dos anos, foi ganhando condição sobre condição até virar um emaranhado difícil de entender e mais fácil de quebrar do que de consertar.
O que muda com isso não é só a clareza. É a possibilidade de decidir. Com achismo, toda conversa sobre dívida vira debate de opinião. Com evidência, a conversa vira sobre prioridade, que é onde ela devia estar.
Saiba mais: por que "evidência" precisa ser conferível, não só detalhada
Uma lista longa e detalhada não é a mesma coisa que uma lista com evidência. A IA pode devolver um relatório extenso, cheio de adjetivo técnico, sobre por que um módulo "apresenta sinais de complexidade elevada e potencial acoplamento excessivo". Isso soa rigoroso e pode não valer nada, se ninguém consegue abrir o arquivo e ver o problema descrito. O teste certo pra qualquer item do mapa de dívida é simples: dá pra apontar o dedo (o arquivo, a linha, o nome da CVE, o número exato de cobertura) e outra pessoa confirmar olhando a mesma fonte? Se a resposta é sim, é evidência. Se a resposta é "confia em mim, ela disse que é grave", ainda é achismo, só que com roupagem de relatório.
03O que continua sendo do time: priorizar com julgamento de negócio
O mapa não termina o trabalho, ele começa a parte que importa. A pergunta certa diante de qualquer item da lista nunca é "o que está mais feio". É outra, mais dura: essa dívida específica vai causar um incidente, ou está travando uma entrega que importa agora?
Pensa nos quatro achados do início da aula. A duplicação de regra de imposto em quatro arquivos é feia, mas se o imposto raramente muda, o risco de divergência é baixo, ela pode esperar. Já a CVE crítica numa biblioteca de processamento de imagem exposta publicamente é um risco concreto e datado, ela compete por atenção imediata. Os 8% de cobertura no módulo de comissão só viram urgência de verdade se esse módulo está prestes a ser alterado; se ninguém vai mexer nele tão cedo, o risco é menor do que parece à primeira vista. A complexidade acumulada na função de roteamento vira prioridade se ela já está causando instabilidade medida, não só porque é feia de ler.
Repare que nenhuma dessas quatro chamadas veio da varredura. Vieram de cruzar o achado técnico com o que o negócio precisa nas próximas semanas: o que vai mudar, o que está exposto, o que já está doendo. Isso é leitura de contexto, e contexto é seu.
04O perigo de tratar toda dívida igual
Aqui mora o erro mais comum depois que o mapa chega pronto: tratar a lista como se cada item pesasse o mesmo. É tentador pegar os itens mais fáceis de resolver, um sprint inteiro arrumando a dívida barata e visível (renomear variável, organizar import, refatorar um trecho pequeno), porque dá a sensação boa de "progresso visível" e cabe bem numa retro.
O problema é que, enquanto isso, a dívida cara e escondida (a CVE crítica, o módulo sem teste que vai ser alterado semana que vem) continua acumulando, sem ninguém tocar nela, porque ela é mais difícil, mais arriscada de mexer, e menos visível no dia a dia. Um sprint de faxina cosmética pode até melhorar a sensação do time, e não mudar nada no risco real da operação.
A régua certa não é o tamanho do esforço nem o quanto o item incomoda visualmente. É o risco de negócio que cada item carrega se ninguém tocar nele nas próximas semanas. Gastar energia limitada na dívida errada é desperdício disfarçado de produtividade.
05Fechamento: o mapa vira fonte pro resto do sistema
O mapa de dívida não vive isolado. Ele é o antídoto direto pro porém mortal que abriu este módulo: torna visível exatamente o que a velocidade sem revisão esconde. Antes, a dívida acumulava no escuro. Agora, ela tem endereço.
E ele também alimenta a coreografia da aula anterior: quando um incidente aparece na triagem de backlog, o mapa de dívida é mais uma fonte que ajuda o time a confirmar a severidade real, porque agora existe uma lista de fragilidades conhecidas pra cruzar contra o ticket novo. Achismo vira mapa, mapa vira prioridade, e prioridade vira menos incidente de madrugada. Vamos?
Faça agora
Pegue um sistema ou módulo real do seu ambiente, a sua tarefa real ou aquele que todo mundo já reclamou informalmente. Peça pra IA varrer e listar 3 evidências concretas de dívida técnica, cada uma com referência: arquivo e linha, número de CVE, ou percentual de cobertura de teste.
Agora faça a parte que é sua: para cada uma das 3 evidências, classifique em "custa caro agora" ou "pode esperar", e escreva em uma frase o motivo de negócio da classificação (o que vai mudar em breve, o que está exposto, o que já está doendo).
Se as 3 evidências vieram sem nada que dê pra conferir (sem arquivo, sem CVE, sem número), volte um passo: isso ainda é achismo com roupagem de relatório, peça a evidência de novo antes de priorizar qualquer coisa.
Pratique
1. A varredura aponta duas dívidas: uma CVE crítica numa biblioteca exposta publicamente, e uma regra de cálculo duplicada em código raramente alterado. Qual a leitura correta?
2. Como o mapa de dívida técnica se conecta com o resto do módulo de Tecnologia desta trilha?
Para o quadro
Sobre o achismoisso aqui é uma bomba-relógio é opinião, não diagnóstico.
Sobre o teste da evidênciadá para apontar o dedo numa fonte que outra pessoa abre e confirma. Sem isso, ainda é achismo.
Sobre a prioridadea pergunta não é o que está mais feio. É o que causa incidente ou trava algo que importa agora.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.