O dia em que percebi que o problema não era o código
Antes de culpar o time, vale entender o ambiente em que ele está inserido.
Você já entrou num time de tecnologia e pensou: “Como deixaram chegar nesse ponto?”
Eu entrei numa empresa onde o sistema caía todo dia, o time era mínimo, e o ambiente local nem sequer funcionava. Um dev tinha sido demitido por um erro grave em produção, mas quando olhei com calma, percebi que o erro era estrutural.
Ninguém contava a verdade nas entrevistas. A cultura era de apagar incêndio, e não de assumir responsabilidade real sobre o que precisava ser consertado.
Pedi liberdade para montar um time e implementar processos. E com clareza, estrutura e gente boa, conseguimos recuperar a plataforma.
Só me dei conta de que tínhamos tirado a plataforma do caos no dia em que fui almoçar e ninguém me ligou para dizer que o sistema tinha caído.
A real é que:
👉 Bons desenvolvedores não ficam em ambientes desorganizados.
👉 Processos mal feitos não são corrigidos com pressão ou discursos de “ownership”.
👉 O caos cansa. E cansa rápido.
📝 Se quiser entender os bastidores dessa história, contei tudo em detalhes (inclusive os absurdos) no post original em inglês: One Day After Recovery.
Quer melhorar a performance do time? Comece pela clareza, não pelo código.
Mas qual é o problema?
A história que contei, com sistema caindo, dev demitido e plataforma desestruturada dá a impressão de que o problema era técnico, código mal feito, arquitetura ruim, e desenvolvedores despreparados.
Mas essa é só a superfície. Esses são os efeitos colaterais de uma causa muito mais profunda (e, muitas vezes, invisível).
Quem não tem experiência na área pode achar que, se o problema é “o código”, a solução é simples: contratar desenvolvedores melhores.
Mas… e quando o problema não é técnico?
Pra entender de verdade o que está em jogo, precisamos voltar à origem.
Afinal, por que criamos produtos de software?
No fundo, um produto de software é uma solução para um problema real.
Alguém tem uma dor, uma necessidade, um desafio.
A tecnologia entra como meio de transformar isso em algo funcional, eficiente, escalável.
Mas pra isso funcionar, três coisas precisam estar claras desde o começo:
Qual é o problema que estamos resolvendo?
Como a solução proposta sustenta o negócio?
Qual é, de fato, a solução técnica?
Se essas três pontas não estão conectadas, nasce o verdadeiro caos.
E é aí que começa o problema: quando a criação de um produto vira uma batalha entre negócio e tecnologia.
Ao invés de atuarem juntos, cada lado começa a defender o próprio território.
👉 Negócio exige entregas e clientes satisfeitos.
👉 Tecnologia luta por estabilidade, escalabilidade, qualidade.
Nesse conflito, o que se perde é justamente aquilo que deveria unir os dois: a clareza.
E quando não há clareza, surgem aberrações como essa que presenciei:
“Cara, estou com um problema no pagamento. Os devs falaram que não tem como resolver e o cliente quer pagar. O cliente quer pagar e eu tenho que dizer que não posso receber porque nosso sistema não suporta?”
Essa fala não foi piada. Era real. O sistema não havia sido planejado para certos tipos de pagamento. Mesmo assim, o dono (tentando resolver do jeito que dava) aceitava o pagamento de forma improvisada e jogava o problema no colo de um desenvolvedor sem poder de decisão.
Essa situação representa algo maior: o negócio tentando se adaptar à falha técnica, quando, na verdade, tecnologia e negócio deveriam estar negociando limites juntos.
Mas quando essa ponte não existe, a empresa entra em modo de sobrevivência. E nesse modo, ninguém ganha:
O negócio se frustra porque “a tecnologia atrasa tudo”.
A tecnologia se desgasta porque é forçada a corrigir decisões que nunca participou.
E o cliente, no fim, percebe (com ou sem bug) que algo está errado.
Quem está vencendo o jogo hoje não é quem tem mais devs, mais dinheiro ou mais ideias.
É quem aprendeu que clareza entre negócio e tecnologia não é um luxo é a única forma de construir algo que dure.