O Bug Squash de 70%: O Que um Hackathon Me Ensinou Sobre Débito Técnico

Fui contratado como consultor técnico por um grande marketplace brasileiro de e-commerce. O tipo de empresa em que milhões de transações passam pela plataforma todo mês, onde uma página de checkout lenta não é um inconveniente, mas um evento de receita, e onde a organização de engenharia havia crescido rápido o suficiente para que ninguém soubesse ao certo quantos microsserviços estavam rodando.

Os números contavam a história antes que alguém precisasse dizê-la em voz alta. Quatro times de desenvolvimento, um time de infraestrutura, e um uptime do site oscilando em 92%. Isso soa quase aceitável até você fazer as contas: 8% de downtime em uma plataforma de e-commerce significa aproximadamente 58 horas por mês em que clientes não conseguem comprar. No e-commerce brasileiro, onde a concorrência é acirrada e a fidelidade do cliente é frágil, essas horas se traduzem diretamente em receita perdida e confiança corroída.

Mas o número de uptime era um sintoma, não a doença. O problema real vivia no bug tracker: mais de 200 tickets abertos, alguns com mais de um ano. Filtros de busca quebrados que retornavam resultados errados. Callbacks de pagamento que falhavam silenciosamente sob condições específicas. Funcionalidades do painel administrativo que nunca funcionaram corretamente desde o lançamento. Edge cases no sistema de inventário que ocasionalmente revendiam produtos, criando pesadelos de fulfillment.

Os engenheiros sabiam de tudo isso. Eles próprios haviam registrado os bugs. Mas ticket após ticket ficava no backlog, envelhecendo em silêncio, porque sempre havia uma feature para entregar, sempre um prazo para cumprir, sempre um product manager com um roadmap que não tinha espaço para "consertar a coisa que está quebrada há seis meses".

A moral estava previsivelmente baixa. Não o tipo dramático de baixa em que as pessoas pedem demissão ruidosamente. O tipo silencioso, em que os engenheiros param de se importar com qualidade porque aprenderam que qualidade não é o que é recompensado. Entregue a feature. Bata a meta do sprint. Siga em frente. Os bugs ainda estarão lá no próximo trimestre.

O diagnóstico: bugs pequenos, backlog grande, zero permissão

Passei minha primeira semana fazendo o que sempre faço quando chego a um lugar novo: eu leio. Li o bug tracker. Li os relatórios de incidente. Li os logs de deploy. Conversei com engenheiros de todos os times, não sobre o que estavam construindo, mas sobre o que estava quebrado e por que não havia sido consertado.

O padrão era notavelmente consistente. Categorizei cada bug em aberto por tempo estimado de correção, e a distribuição era quase comicamente distorcida:

Setenta por cento dos bugs eram pequenos. Trivialmente pequenos. Uma checagem de null faltando. Uma ordem de sort errada. Um overflow de CSS no mobile. Um timeout mal configurado. Uma string hardcoded que deveria ter sido um valor de config. Cada um levaria menos de duas horas para um engenheiro experiente corrigir, incluindo testes.

Mas em uma cadência de sprint orientada a features, duas horas são um luxo. Quando o time de produto se comprometeu a entregar três features neste sprint, ninguém vai tirar um engenheiro do trabalho de feature para consertar um filtro de busca que "funciona na maior parte do tempo". O custo de cada bug individual é pequeno. O custo acumulado de 140 bugs pequenos é uma plataforma que parece quebrada, um número de uptime que envergonha a todos, e um time de engenharia que internalizou a mensagem de que qualidade não importa.

Os bugs não eram difíceis. Eles simplesmente nunca recebiam permissão para serem corrigidos.

O hackathon: dois dias, uma regra, sem code review

Propus algo simples à liderança de engenharia: me dê os times por dois dias. Dois dias em que o único trabalho permitido são correções de bugs. Sem features. Sem itens de roadmap. Sem reuniões de planejamento. Apenas engenheiros, um backlog de bugs, e permissão para consertar coisas.

Houve resistência, naturalmente. Dois dias sem trabalho de feature são uma eternidade em uma empresa de e-commerce com velocidade de startup. Product managers calcularam a velocidade de features que perderiam. Engineering managers se preocuparam com compromissos de sprint. Argumentei com os números: os bugs estavam custando mais no agregado — via downtime, reclamações de clientes, workarounds e frustração dos engenheiros — do que dois dias de trabalho de feature pausado. E o número de uptime estava se tornando uma conversa em nível de conselho.

Eles concordaram. Chamamos de hackathon, porque "sprint de correção de bugs" não inspira ninguém, e o enquadramento importa.

As regras eram deliberadamente mínimas:

• Apenas bugs. Sem features, sem projetos de refactoring, sem "já que estou aqui, posso aproveitar". Corrija o bug, feche o ticket, siga em frente.
• Escolha do backlog. Cada time trabalha a partir do backlog de bugs compartilhado. Escolha o que você conhece, escolha o que te irrita, escolha o que os seus usuários reclamam. Quem chega primeiro, leva.
• Sem code review obrigatório. Isto foi controverso. Mas os bugs eram pequenos, os engenheiros eram experientes, e o gargalo que precisávamos remover era a fricção. Confie no time. Entregue diretamente.
• Acompanhe tudo em um board. Um board físico (e um espelho digital) com três colunas: A Fazer, Em Progresso, Concluído. Cada bug eliminado é movido com um gesto físico satisfatório. Visibilidade importa para o momentum.

Esse último ponto — o board — acabou sendo mais importante do que eu esperava. Há algo profundamente motivador em assistir a uma parede se encher de tickets concluídos ao longo de um dia. No almoço do primeiro dia, a coluna Concluído havia transbordado o espaço alocado. Engenheiros tiravam fotos e postavam no chat do time. A energia no escritório era diferente — as pessoas riam, batiam palma, competiam informalmente para ver qual time fechava mais tickets.

Parecia os primeiros dias de uma startup, quando entregar era rápido e consertar coisas era o trabalho inteiro. Porque, por dois dias, era.

Os resultados: 70% eliminados em 48 horas

Ao fim do segundo dia, os números eram difíceis de contestar:

O backlog de bugs caiu de mais de 200 tickets para aproximadamente 60. Os 60 restantes eram os bugs genuinamente difíceis — os que exigiam mudanças arquiteturais, coordenação entre times ou investigação profunda. Os 140+ que foram eliminados eram exatamente o que a análise previa: problemas pequenos e corrigíveis que só precisavam de alguém sentado fazendo o trabalho.

Em um mês, o uptime subiu de 92% para 99%. Não porque havíamos reconstruído a infraestrutura ou implantado algum novo sistema de monitoramento. Porque havíamos corrigido as cem pequenas coisas que, coletivamente, puxavam a plataforma para baixo. Um callback de pagamento que falhava silenciosamente uma vez a cada mil requisições. Um bug de invalidação de cache que servia dados de produto desatualizados. Um connection pool que não estava dimensionado corretamente para o tráfego de pico. Cada um contribuía com uma fração de um por cento de downtime. Juntos, respondiam por sete pontos percentuais.

Mas o resultado mais importante não estava nas métricas. Estava nas conversas que ouvi após o hackathon. Engenheiros dizendo coisas como: "Não acredito que esse bug estava lá há oito meses — levei quarenta minutos para corrigir." E: "Por que a gente não faz isso todo mês?" E, mais revelador: "Eu realmente me sinto bem com a nossa base de código pela primeira vez em um ano."

O hackathon não apenas corrigiu bugs. Ele consertou a relação do time com o próprio código.

A lição mais profunda: permissão é o gargalo

Aqui está o que a maioria das pessoas entende errado sobre débito técnico. Elas pensam que o problema é técnico. Que a base de código é complexa demais, a arquitetura é emaranhada demais, o débito está profundamente embutido demais para ser resolvido. E às vezes isso é verdade — algum débito técnico é realmente estrutural e exige investimento significativo para ser resolvido.

Mas a maior parte não é. A maior parte do débito técnico — o tipo que derruba o uptime, frustra usuários e desmotiva engenheiros — é uma pilha de pequenos problemas individualmente corrigíveis que se acumulam porque a estrutura de incentivos da organização não recompensa corrigi-los.

Engenheiros sabem o que está quebrado. Eles registraram os bugs. Eles têm contornado os problemas há meses. Eles esboçaram mentalmente as correções durante a standup enquanto ouviam mais uma spec de feature. A habilidade está lá. O conhecimento está lá. A motivação está lá — engenheiros querem trabalhar em uma base de código da qual se orgulhem.

O que falta é permissão. Permissão explícita, inequívoca, top-down para parar de entregar features e consertar as coisas. Não "você pode trabalhar em bugs se sobrar tempo no final do sprint" — esse tempo nunca se materializa. Não "precisamos mesmo endereçar o débito técnico em breve" — "em breve" é uma palavra que significa "nunca" em roadmaps de produto. Permissão de verdade. Dois dias. Todo mundo. Apenas bugs. Sem exceções.

O hackathon funcionou não porque era um formato inteligente. Funcionou porque era uma estrutura de permissão. Deu aos engenheiros algo que eles não podiam dar a si mesmos: tempo legítimo e protegido para corrigir as coisas que já sabiam como corrigir. O hackathon não foi uma intervenção técnica. Foi uma intervenção cultural.

É por isso que digo aos líderes de engenharia: se o seu time tem um backlog grande de bugs e um uptime mediano, a primeira pergunta não é "o que há de errado com a nossa arquitetura?". A primeira pergunta é "quando foi a última vez que demos permissão aos nossos engenheiros para consertar as coisas?".

O que mudei depois do hackathon

Um hackathon é uma explosão. Produz resultados dramáticos, mas explosões não se sustentam. O bug squash de 70% teria sido uma lembrança agradável que desapareceria em meses se não tivéssemos construído práticas de sustentação ao seu redor. Eis o que colocamos em prática:

Política de code review com testes obrigatórios

Antes do hackathon, o code review era opcional e os testes eram aspiracionais. Instituímos uma política: todo pull request requer pelo menos um revisor e deve incluir testes para o comportamento alterado. Isso soa básico — porque é. Mas "básico" e "implementado" são coisas diferentes. A política impediu que o backlog voltasse a encher no mesmo ritmo. O código novo passou a ser avaliado por um padrão mais alto. Bugs ainda aconteciam, mas menos deles eram do tipo trivial que dominava o backlog antigo.

Treinamento de desenvolvedores estagiários

A empresa tinha vários desenvolvedores estagiários que eram ansiosos, mas não haviam recebido mentoria estruturada. Montei um programa de treinamento focado em práticas de teste, metodologia de debugging e habilidades de code review. Isso serviu a dois propósitos: desenvolveu talento júnior (investimento de longo prazo) e criou capacidade adicional para manter a qualidade do código (benefício de curto prazo). Em poucos meses, os estagiários estavam pegando bugs em code review que antes chegariam à produção.

Fix-it Fridays

Toda sexta-feira à tarde, quinzenalmente, era reservada para correções de bugs e pequenas melhorias. Sem necessidade de aprovação, sem justificativa exigida. Este foi o legado duradouro do hackathon: permissão recorrente. Isso evitou a lenta reacumulação de pequenos bugs que havia criado o problema original. Também deu aos engenheiros uma válvula previsível para as melhorias de qualidade que queriam fazer, o que mensuravelmente melhorou a moral.

Entrega contínua em Kubernetes

Construímos um pipeline de CD apropriado em Kubernetes, substituindo um processo manual de deploy que envolvia fazer SSH em servidores e rodar scripts. Isso teve dois efeitos: tornou o deploy de correções rápido e seguro (minutos em vez de horas, com rollback automático) e removeu uma fricção oculta que havia desencorajado pequenas correções. Quando o deploy é doloroso, os engenheiros agrupam mudanças em grandes releases. Quando o deploy é indolor, eles entregam correções assim que estão prontas.

O padrão para outros times

Desde então, usei variações desta abordagem em outras empresas. Os detalhes mudam — o tamanho do backlog, a estrutura do time, o sabor particular do débito técnico — mas o padrão é consistente. Eis o playbook:

Passo 1: Avalie o backlog honestamente

Categorize cada bug em aberto por tempo estimado de correção. Seja honesto — não infle estimativas para fazer o problema parecer mais difícil do que é. Se 60-70% dos seus bugs são pequenos, você tem um problema de permissão, não um problema técnico. Se a maioria dos bugs é genuinamente complexa, você tem um problema diferente (provavelmente arquitetural) que um hackathon não vai resolver.

Passo 2: Obtenha buy-in da liderança para dois dias

Este é o passo mais difícil. Apresente os dados: o tamanho do backlog, o custo em uptime, o impacto na moral. Calcule o que os bugs estão custando em termos concretos — minutos de downtime, reclamações de clientes, tempo de engenheiros gasto em workarounds. Dois dias de trabalho de feature pausado são quase sempre mais baratos do que o custo contínuo do débito. Defenda esse caso com números, não com sentimentos.

Passo 3: Rode o hackathon com regras mínimas

Mantenha simples. Apenas bugs. Escolha do backlog. Acompanhe em um board. Não super-organize — o ponto inteiro é remover fricção. A energia e o momentum vão emergir naturalmente assim que os engenheiros perceberem que realmente têm permissão para consertar as coisas.

Passo 4: Celebre e meça

Torne os resultados visíveis. Compartilhe os números antes/depois com a empresa inteira. Deixe os engenheiros falarem sobre o que consertaram e quanto tempo levou. As histórias do tipo "não acredito que isso foi só uma correção de 20 minutos" são a advocacia mais poderosa para tornar isso uma prática regular.

Passo 5: Construa práticas de sustentação

É aqui que a maioria dos times falha. O hackathon produz uma explosão de progresso, todo mundo se sente ótimo, e três meses depois o backlog está exatamente onde começou. As práticas de sustentação — requisitos de code review, mandatos de teste, tempo recorrente de correção, pipelines de deploy rápidos — são o que impede a regressão. Sem elas, você só está fazendo um exercício agradável que precisará repetir a cada trimestre.

O que dá errado quando você pula etapas

Pule a avaliação, e você desperdiçará o hackathon em bugs complexos que não podem ser corrigidos em duas horas — desmotivando em vez de energizar. Pule o buy-in da liderança, e o hackathon será interrompido no primeiro dia por pedidos de feature "urgentes". Pule as práticas de sustentação, e você estará de volta aos 200 bugs em seis meses. Cada etapa importa. O hackathon em si é apenas o catalisador.

Capture o que você aprende, ou perca

Um hackathon produz uma explosão de conhecimento institucional. Ao longo de dois dias, engenheiros tocam partes da base de código que não olham há meses. Eles descobrem por que as coisas estão quebradas, como a quebra se manifesta e como é a correção. Encontram dependências escondidas, comportamentos não documentados e código que ninguém lembra ter escrito.

Se você não capturar esse conhecimento, ele evapora. Os bugs são corrigidos, mas a compreensão do porquê eles existiam e do que revelavam sobre o sistema volta para as cabeças individuais dos engenheiros, onde será esquecida em semanas.

Na empresa, exigimos que cada engenheiro escrevesse uma breve nota para cada bug que corrigiu: qual foi a causa raiz, qual foi a correção, e o que isso revelou sobre o sistema. Essas notas iam para uma base de conhecimento compartilhada. Algumas delas acabaram sendo mais valiosas do que a própria correção do bug — "este módulo não tem cobertura de testes e uma dependência hardcoded do gateway de pagamento" é uma nota que previne bugs futuros, não apenas corrige bugs passados.

Este é um padrão sobre o qual já escrevi: construir uma base de conhecimento que capitaliza o entendimento do seu time sobre o sistema ao longo do tempo. Um hackathon é uma fonte particularmente concentrada desse conhecimento. Não deixe ir pelo ralo.

A história real

As pessoas lembram dos números: 70% dos bugs eliminados, uptime de 92% para 99%. Esses números são reais e importaram para o negócio.

Mas a história real daquele hackathon é mais simples. Uma sala cheia de engenheiros já sabia o que estava quebrado. Eles já sabiam como corrigir. Eles vinham carregando esse conhecimento por meses, assistindo à contagem de bugs subir, sentindo a lenta erosão do orgulho no próprio trabalho.

Tudo o que precisavam era alguém dizer: "Pare. Conserte. Você tem permissão."

Se o seu time tem um backlog crescente de bugs e métricas de qualidade em declínio, pergunte a si mesmo honestamente: o problema é que os bugs são difíceis demais de corrigir? Ou o problema é que sua organização nunca deu a ninguém permissão explícita para corrigi-los?

A resposta é quase sempre a segunda. E a correção é quase sempre mais simples do que você imagina.