← Voltar aos artigos
·1 min de leitura·#engenharia#soft skills

O Monstro Invisível 👹

Prazos que não fecham, entregas que atrasam, problemas sem fim. Quase sempre a culpa não é técnica — é de tudo aquilo que deixamos passar. Uma conversa sobre o monstro invisível que sabota os times.

Você já esteve em alguma situação no seu time em que nada dava certo? Nenhum prazo era alcançado, entregas atrasavam, os problemas eram intermináveis e não havia visão clara de para onde ir ou o que fazer. Isso é bem comum, e a solução pode ser mais simples do que parece.

🔍 O que é “melhorar”, afinal?

Existe uma frase que muita gente repete: “Temos que melhorar 1% a cada dia.” Mas, na prática, o que é melhorar? Quando falhamos em uma entrega, deixamos de resolver um problema ou o cliente reclama de algo terrível que aconteceu na operação, isso é apenas o resultado de uma série de fatos que foram se acumulando, muitas vezes silenciosamente, e passaram despercebidos. Ou, pior, foram percebidos e negligenciados.

Há muita coisa no nosso dia a dia à qual não damos importância. Quer alguns exemplos? Quantas vezes você entrou em reuniões para discutir um problema, todos falaram por horas e, ao final, não havia nenhum documento formal sobre como aquilo seria resolvido, qual o prazo, o impacto ou a forma de mitigar? Quantas vezes você repetiu um processo manual sem nunca parar para estudar como automatizá-lo? Quantas vezes você viu um problema, principalmente de outras áreas, e apenas reclamou que ele existia, sem propor ideias (ou sequer pesquisar) sobre como melhorá-lo, porque “já estava aqui quando eu cheguei”?

🧩 O problema quase nunca é técnico

Parece simples demais, mas é isso que realmente muda o jogo. Quando temos um problema técnico, sempre queremos resolvê-lo pelo lado técnico: vamos implementar a tecnologia XYZ, mudar para o framework ABC, migrar da arquitetura A para a B. Quando, na verdade, o problema costuma ser cultural. Sendo transparente: uso a palavra “cultural”, mas talvez não concorde 100% com o termo. É apenas o que mais se aproxima do que quero expressar.

🍽️ A analogia do restaurante

Saindo do técnico e trazendo para a prática: se o restaurante serviu uma comida ruim, a culpa não é do cozinheiro, e muito menos do ingrediente usado. A culpa é do garçom que não percebeu o problema e ainda serviu atrasado; do cozinheiro que não viu problema em fazer daquele jeito; de quem estocou os alimentos de qualquer forma; do comprador que talvez não tenha escolhido a melhor qualidade; do gerente que não supervisionou a compra, a cozinha e o garçom; do dono que não instruiu o gerente a implementar processos claros. Enfim. Enquanto não ficar claro que o produto final é resultado de problemas em todas as áreas, nada vai dar certo.

🌐 Trazendo para o nosso mundo

Agora, trazendo para o nosso mundo: enquanto o dev não entender que problema no financeiro é problema da empresa, que problema de infra também é problema de engenharia, que observabilidade também é problema dele, que custo de cloud também é problema dele, nada muda. Esse tipo de comportamento faz a gente pensar no todo, e não só no que estamos fazendo. E isso muda o jogo, porque, se todos pensam assim, a chance de reduzir os erros é enorme.

“Mas, Bruno, você está me dizendo que devo ir até o financeiro me preocupar com a planilha de gastos, mesmo que esteja tudo certo?” Sim e não. Se você vê alguém com um problema que consegue ajudar a resolver, sem prejudicar o andamento das suas próprias tarefas, ajude. Às vezes, uma automação simples (simples para nós) economiza alguns milhares de reais para a empresa, liberando caixa para investir em áreas como a própria engenharia.

Uma vez ouvi uma frase que dizia: “Esta empresa parece um barco, mas com cada um remando para um lado.” É exatamente isso. Imagine cada pessoa construindo sua própria peça de Lego sem combinar com as demais: o que acontece na hora de encaixar? Uma grande bagunça.

🛠️ Não seja só um engenheiro. Seja um resolvedor de problemas.

O ponto principal é: não seja apenas um engenheiro, seja um resolvedor de problemas. Você vai sempre aprender algo novo (e conhecimento nunca é demais) e pode ser que as coisas comecem a entrar nos eixos.

O monstro invisível está em todos os passos que negligenciamos, não observamos, não melhoramos e não nos damos ao trabalho de mudar. E é aqui que aquele “1% a cada dia” finalmente faz sentido: melhorar não é adotar a tecnologia da moda nem trocar de framework. É enxergar o que estava invisível, assumir os problemas como seus, mesmo os que não nasceram na sua área, e agir sobre eles. Um passo notado, um processo documentado, uma automação a mais. Todo dia. É assim que se derrota, aos poucos, o monstro que ninguém vê.

Bruno Cunha

Bruno Cunha

Engenheiro de software. Escrevo sobre performance, .NET e os bastidores de sistemas que escalam.