Que Ideia Eles Têm Para Resolver O Problema

O que acontece quando a equipe entra na sala de reunião

Você já sentou em uma reunião dessas. O técnico levanta, desenha um diagrama no quadro, e tudo parece elegante na teoria. Na prática, seis meses depois, você ainda está corrigindo o mesmo bug que o diagrama prometia eliminar. A questão que todo mundo faz é simples: qual é a abordagem real que eles estão propondo? Antes de aprovar qualquer projeto, antes de liberar budget, antes de começar a codar, existe uma pergunta que separa o que funciona do que vira dívida técnica. Que ideia eles têm para resolver o problema. Não a apresentação de slides. O que realmente vai ser construído, onde vai doer, e o que vai quebrar primeiro. Eu trabalhei em três empresas diferentes onde a resposta era sempre a mesma coisa: um sistema novo que substituía o legado. Sempre. E sempre, no segundo trimestre de uso, aparecia o mesmo cenário que ninguém tinha mapeado. A diferença entre os projetos que deram certo e os que falharam foi o nível de detalhe com que a solução foi discutida antes do primeiro commit.

O mecanismo por trás das soluções que sobrevivem

A maioria das equipes pula direto para a implementação. Elas identificam o sintoma, propõem a ferramenta nova, e começam a trabalhar. O que separa as soluções que funcionam das que não funcionam não é a tecnologia em si. É o nível de rigor com que o problema foi decomposto antes de qualquer decisão ser tomada. Quando eu vejo uma proposta de solução, meu primeiro passo é pedir para alguém explicar o problema nos menores termos possíveis. Não a versão de apresentação para stakeholders. O problema real, com dados reais. Quantos usuários são afetados. Qual é o throughput atual. Qual é a latência observada nos picos. Sem esses números, qualquer solução é adivinhação com mais custo. Existe um viés cognitivo muito forte aqui. Quando você passa duas semanas pesquisando uma solução, seu cérebro quer confirmar que a pesquisa valeu a pena. Você começa a enxergar dados que se encaixam e ignora os que não se encaixam. Eu já vi um time descartar uma correção de três linhas porque "não parecia escalonável", quando a métrica real mostrava que o gargalo estava em outro lugar completamente.

Um caso específico que eu vivi recentemente

Em 2023, lidamos com um problema de processamento de filas em um sistema de pagamento. A proposta inicial era migrar para um broker diferente. Kafa, basicamente. A apresentação era impecável. Throughput teórico, disponibilidade, eco-system maduro. Tudo certo nos slides. Eu pedi para ver os logs de produção dos últimos noventa dias antes de qualquer decisão. O padrão de acesso mostrava algo que a arquitetura proposta não considerava: a maioria das mensagens eram extremamente pequenas, com taxa de chegada altamente bursty, e cerca de quinze por cento delas precisavam de processamento síncrono dentro de um janela de duzentos milissegundos. O broker proposto tinha latência de rede addicional de cem a cento e cinquenta milissegundos em configuração padrão. Só isso já consumia metade da janela disponível. A solução real foi muito mais simples. Mantivemos o sistema existente, mas implementamos um cache de resultado com TTL de cinco segundos para as requisições idempotentes que representavam oitenta e dois por cento do volume. O custo de infraestrutura caiu em cerca de sessenta por cento. A latência média caiu de quatrocentos para cento e vinte milissegundos. Nada de novo, nada de revolucionário. Apenas a solução que respondia ao problema real em vez do problema percebido.

O que as pessoas normalmente não consideram

Existem pelo menos dois pontos que toda equipe subestima quando propõe uma solução. O primeiro é o custo de migração disfarçado de benefício. Todo mundo calcula o ganho de performance. Poucos calculam o tempo de transferência dos dados, a revalidação dos caches, o período de operação dual, e a janela de rollback se algo der errado. Em sistemas com petabytes de dados, esse custo pode equivaler a meses de trabalho de infraestrutura apenas para mover informação de um lugar para outro. O segundo ponto é a complexidade operacional que a solução introduz. Um sistema mais moderno geralmente significa mais componentes para monitorar, mais pontos de falha, mais runbooks para escrever. Eu já vi times implementarem uma arquitetura que reduziu a latência em quarenta por cento e aumentou o tempo médio de resolução de incidentes em três vezes. O trade-off nunca foi explícito. Outra armadilha comum é confundir correlação com causalidade. Você observa que um sistema lento e propõe uma solução que otimiza o gargalo errado. A equipe acha que o banco de dados é o problema porque as queries demoram. O que elas não veem é que o delay real está na camada de rede entre o serviço e o banco, causada por configurações de MTU incompatíveis entre duas sub-redes que foram unificadas sem teste de conectividade adequada. Correção: trinta minutos de ajuste de configuração. A solução proposta teria levado quatro meses.

Como avaliar se a ideia deles tem fundamento

Existem algumas perguntas práticas que você pode fazer para testar se uma proposta tem solidez antes de investir recurso algum. A primeira é pedir o plano de rollback. Se a pessoa não conseguir descrever em três passos o que faria para reverter a mudança em caso de falha, a proposta não está madura o suficiente para ser implementada. Isso não é pessimismo. É engenharia básica. A segunda pergunta é sobre as métricas de sucesso. Qual número vai mudar. Qual é a linha de base atual. Qual é a meta. Quando você vai saber que deu certo. Sem essas respostas, não há como avaliar se a solução funcionou ou se você apenas gastou dinheiro esperando que funcionasse. A terceira é sobre o que não vai mudar. Toda solução tem limitações. As boas propostas explicitam essas limitações antes da implementação, não depois, quando já existe compromisso político e financeiro envolvido. Se ninguém mencionou o que a solução não resolve, provavelmente ela não resolveu nada importante.

Quando vale a pena insistir e quando vale a pena deixar pra lá

Nem toda ideia ruim precisa ser bloqueada. Às vezes, o aprendizado que vem de uma implementação mal-sucedida vale o custo, especialmente em equipes que estão amadurecendo sua capacidade técnica. O problema é quando o custo é alto e o aprendizado é baixo. Quando a solução proposta substitui um sistema que funciona por um que promete funcionar melhor, mas não há dados suficientes para justificar a mudança, o risco é puramente negativo. Eu tenho um critério simples que uso internamente: se a solução proposta não pode ser explicada em uma página A4 com diagramas, métricas atuais, métricas esperadas, plano de migração e plano de rollback, ela não está pronta para discussão de implementação. Pode ser uma ideia válida. Mas ideias sem especificação são apenas opiniões caras. No fim das contas, a pergunta original continua sendo a mais útil que existe em qualquer reunião de tecnologia: qual é a ideia real por trás da proposta. Não o nome da ferramenta. Não o slide bonito. O que efetivamente vai ser feito, com quais dados, e o que vai acontecer se der errado. Tudo o mais é decoração.