O problema com "resolver" um problema

Todo desenvolvedor já passou por isso: um bug aparece, o prazo pressiona, e você faz algo - qualquer coisa - para o problema sumir da tela. Mas será que o problema foi realmente resolvido? Ou só foi empurrado para frente?

A verdade e que existem pelo menos três formas diferentes de responder a um problema técnico - e apenas uma delas e realmente resolve. Entender qual resposta você esta dando em cada situação muda completamente como você trabalha, como você prioriza e como você cresce como profissional.

Esse modelo de pensar em respostas a problemas e útil não só para bugs e incidentes técnicos, mas para qualquer desafio no trabalho: requisitos confusos, conflitos de equipe, divida técnica acumulada, features que ninguém usa. Veja as três respostas e identifique qual você usa mais.

Resposta 1: contornar o problema (workaround)

O workaround e a resposta mais comum no dia a dia de qualquer time de tecnologia. O problema existe, você sabe que existe, mas em vez de atacar a causa raiz você encontra um caminho ao redor. O sistema continua funcionando - pelo menos por enquanto.

Exemplos práticos que todo dev reconhece:

  • Adicionar um try/catch vazio porque "esse erro nunca deveria acontecer"
  • Um cronjob que reinicia o serviço toda meia-noite porque ele vaza memoria
  • Hardcodar um valor porque "o banco de dados esta retornando errado as vezes"
  • Um campo is_migrated booleano que nunca vai ser usado depois que a migração acabar

O workaround tem seu lugar legítimo: quando o custo de resolver a causa raiz agora e maior do que o custo de conviver com o sintoma. O problema e quando workarounds viram o padrão, e não a exceção. Cada um deles e uma aposta de que "o problema não vai piorar". E as apostas acumulam.

⚠️
Atenção

Um workaround sem documentação e pior do que a causa raiz. Sempre registre: o que é o workaround, qual e o problema real por baixo, e qual e a condição para remover o workaround. Sem isso, ele vira "código legado misterioso".

Resposta 2: ignorar o problema

Ignorar um problema e diferente de priorizar outros problemas acima dele. Ignorar e não reconhecer que o problema existe, ou reconhecer e conscientemente decidir que ele não vai ser tratado - sem registrar, sem comunicar, sem plano.

No contexto de desenvolvimento, isso aparece como:

  • Bugs no backlog que ninguém vai olhar nos próximos seis meses
  • Alertas de monitoramento que todo mundo silenciou porque "sempre dispara"
  • Testes que estão sempre pulados porque "eles são flaky"
  • Uma dependência com CVE de severidade alta que "vamos atualizar depois da release"

O problema com ignorar e que os problemas raramente desaparecem sozinhos. Eles ficam maiores. Um alerta que todo mundo ignora e um incidente que ninguém vai conseguir diagnosticar rapidamente quando a coisa explodir de verdade.

🔴
Cuidado

Silenciar alertas de monitoramento em vez de consertar o que os dispara e um dos erros mais caros que um time pode cometer. Alertas silenciados viram pontos cegos que mascaram incidentes reais.

Resposta 3: resolver a causa raiz

Resolver a causa raiz e a resposta mais cara a curto prazo e a mais barata a longo prazo. Ela exige entender o "por que" atrás do "o que", reproduzir o problema de forma controlada, e implementar uma solução que elimina a fonte do problema - não apenas o sintoma.

O processo que separa quem resolve de quem contorna geralmente segue essa lógica:

# Cinco porquês (5 Whys) - técnica clássica de análise de causa raiz
Problema: O deploy de hoje falhou

Por que falhou? -> A build quebrou
Por que a build quebrou? -> O teste de integração não passou
Por que o teste não passou? -> O banco de dados de teste estava vazio
Por que estava vazio? -> A migração não foi executada antes dos testes
Por que a migração não foi executada? -> Não existe step de migração no pipeline de CI

Causa raiz: ausência de step de migração no CI
Solução: adicionar o step, não workaround o teste

A técnica dos Cinco Porquês e simples mas poderosa. O objetivo não e chegar exatamente a cinco perguntas, mas continuar perguntando "por que" até chegar numa causa que você pode de fato controlar e corrigir.

💡
Dica

Antes de implementar qualquer correção, escreva um teste que reproduza o bug. Isso garante que você realmente entendeu o problema e que a correção funciona. E documentação viva do que foi corrigido.

Como começar a identificar qual resposta você esta dando

O primeiro passo e a autoconsciência. Na próxima vez que você for "consertar" algo, pare um momento e pergunte: estou resolvendo o problema ou estou respondendo a ele de outra forma?

Um checklist simples para avaliar sua resposta:

# Checklist antes de "fechar" um ticket
[ ] Eu entendo a causa raiz do problema?
[ ] A solução elimina a causa ou apenas mascara o sintoma?
[ ] Se for um workaround: esta documentado com data de revisão?
[ ] Se for ignorado: existe um ticket registrado com a justificativa?
[ ] Existe um teste que prove que o problema foi resolvido?

Não existe resposta errada por definição - workarounds e priorizações conscientes são parte da realidade de qualquer time. O que é errado e dar essas respostas sem consciência e sem registro.

Comparação: quando cada resposta faz sentido

A escolha entre resolver, contornar ou priorizar para depois depende de três variáveis: urgência, impacto e custo de resolução. Uma forma de pensar nisso:

Resolver agora: o problema esta causando impacto direto em produção, já foi ao menos uma vez, e a causa raiz e identificável. Cada hora sem resolução custa dinheiro ou reputação.

Workaround consciente: o impacto e baixo, a causa raiz e complexa e cara de corrigir agora, e o workaround pode ser removido facilmente quando houver capacidade. Documentar e criar o ticket da causa raiz e obrigatório.

Ignorar ou priorizar para depois: o problema existe mas o custo de resolução hoje supera o beneficio esperado no horizonte de tempo relevante. Registrar no backlog com contexto suficiente para que alguém no futuro possa avaliar se ainda vale a pena.

🚀
Pro tip

Times maduros revisam o backlog de workarounds e bugs ignorados a cada sprint ou iteração. Sem essa revisão, o backlog vira um cemitério de decisões passadas que ninguém mais entende ou confia.

Pontos positivos e armadilhas de cada abordagem

Cada resposta tem vantagens e riscos reais que você precisa conhecer:

Workaround - vantagem: rápido, desbloqueia o time imediatamente, preserva a opcao de investigar com mais calma depois. Armadilha: acumula divida técnica invisível; cada workaround e uma dependência frágil que ninguém vai querer tocar.

Ignorar/adiar - vantagem: libera capacidade para trabalho de maior impacto agora. Armadilha: problemas pequenos ignorados se tornam crises grandes. Sem registro, viram surpresas desagradáveis seis meses depois, quando o contexto se perdeu completamente.

Resolver a causa raiz - vantagem: elimina o problema definitivamente, melhora a qualidade do sistema e a confiança do time. Armadilha: pode ser caro demais para o momento; o perfeito pode ser inimigo do entregado.

Casos de uso reais no dia a dia de times de tecnologia

Incidente em produção: a pressão e máxima, o cliente esta ligando, o CEO esta no Slack. Nesse contexto, um workaround rápido para restaurar o serviço e a resposta correta - seguido obrigatoriamente de um post-mortem que identifica a causa raiz e planeja a correção real.

Bug reportado durante a sprint: depende do impacto. Se bloqueia outros, vai para o topo. Se e cosmético, entra no backlog com severidade e contexto. O erro seria ignorar sem registrar, ou interromper a sprint inteira para um bug de baixo impacto.

Divida técnica acumulada: o clássico "vamos refatorar isso depois". Sem reservar capacidade para pagar essa divida periodicamente, ela cresce exponencialmente. Times de alto desempenho reservam entre 20 e 30% de cada sprint para trabalho técnico sem feature nova.

Requisito confuso do cliente: o problema não e técnico, mas a resposta e a mesma. Você pode contornar (implementar o que você acha que o cliente quer), ignorar (implementar algo e esperar feedback) ou resolver a causa raiz (conversar com o cliente para entender o problema real por traz do requisito).

Dicas e boas práticas para times de tecnologia

💡
Dica

Crie uma label "workaround" no seu sistema de issues. Todo workaround implementado cria um ticket filho com essa label. Isso torna a divida técnica visível e rastreavel, não um custo oculto.

🚀
Pro tip

Nos post-mortems de incidentes, sempre pergunte: "Que workaround anterior nos colocou nessa situação?" A maioria dos incidentes em produção tem uma serie de workarounds não resolvidos em algum ponto da cadeia.

⚠️
Atenção

A cultura do time importa mais do que a técnica. Se o ambiente pune erros de forma pessoal, o time vai evitar relatar problemas e vai preferir workarounds invisíveis. Segurança psicológica e prerequisito para times que resolvem causas raiz.

Vale a pena pensar assim?

Sim, e muito. A diferença entre um desenvolvedor júnior e um sénior não e só o conhecimento técnico - e a capacidade de diagnosticar corretamente o tipo de problema que esta enfrentando e escolher conscientemente a resposta mais adequada para o momento.

Desenvolvedores que sempre tentam resolver tudo da forma definitiva ficam presos em perfeicionismo e nunca entregam. Desenvolvedores que sempre workaroundam acumulam divida técnica que eventualmente quebra o sistema. O equilíbrio consciente e o que define times de alta performance.

O próximo passo e prático: na próxima semana, antes de fechar qualquer ticket, pergunte explicitamente para si mesmo: "Estou resolvendo a causa raiz ou estou respondendo ao sintoma?" Só perguntar já muda o padrão de resposta da maioria das pessoas.