Este é mais um artigo da série que aborda como conduzir uma transformação na arquitetura de sistemas de software. Seguimos os acontecimentos em uma empresa imaginária de serviços financeiros que tentou se tornar ágil, mas descobriu que sua arquitetura de software era um fator limitante. Eles agora alcançam uma nova etapa em sua jornada.
Um Balde de Água Fria
Depois de criar seu plano inicial e garantir um espaço na reunião estratégica que definiria o orçamento do ano seguinte, Carlos chegou confiante e bem preparado. No entanto, sua expectativa logo se transformou em decepção. Durante a reunião, a alta direção apresentou sérios desafios financeiros previstos para o próximo ano. Nesse contexto, um projeto como o de Carlos, que não traria diretamente novas receitas ou novos produtos, mas demandaria tempo e recursos dos times, acabou enfrentando resistência.
A conscientização contínua que Carlos vinha criando ajudou, pelo menos, a evitar que seu plano fosse totalmente descartado. A diretoria aprovou apenas parte da versão mais básica do seu plano, restringindo-o às ações mais urgentes. Todas as demais atividades previstas ficaram suspensas até uma reavaliação futura. Além disso, Carlos recebeu a notícia frustrante de que custos adicionais com licenças e infraestrutura deveriam sair de seu já apertado orçamento.
Nos meses seguintes, antes do fechamento definitivo do orçamento, Carlos e seu time fizeram várias projeções para o próximo ano. Analisaram detalhadamente volumes de transações, crescimento esperado e outros fatores críticos. Em uma dessas projeções, Carlos percebeu algo alarmante: os custos para manter em operação o sistema legado cresceriam rapidamente, ultrapassando o orçamento disponível antes do final do ano. A única solução viável seria começar algumas etapas da transformação arquitetural antes mesmo do final do ano, para que fosse possível retirar o quanto antes os componentes mais problemáticos do sistema antigo.
Diante da urgência da situação, Carlos decidiu levar esse alerta para a reunião semanal da diretoria. Enquanto apresentava suas projeções e explicava a gravidade da situação, foi subitamente interrompido por uma ligação urgente de Ana, sua desenvolvedora mais experiente. Um dos sistemas mais críticos da empresa estava fora do ar, impactando diretamente os clientes e operações.
Carlos, diante da diretoria, deu imediatamente a notícia sobre o incidente, ressaltando que se tratava de um problema recorrente da arquitetura antiga. Deixou claro que a equipe vinha gastando muito tempo e energia em soluções provisórias, enquanto a saída definitiva seria a migração para a nova arquitetura.
Após explicar brevemente a situação, Carlos pediu licença e saiu rapidamente da reunião, dirigindo-se diretamente à sala de crise, onde seu time técnico tentava restabelecer o sistema. Naquele momento, os executivos que ficaram na reunião tomaram um susto. Eles entenderam, pela primeira vez, a real gravidade dos riscos apresentados por Carlos. Uma revolução na arquitetura dos sistemas deixava de ser apenas um desejo do time de tecnologia e passava a ser percebida como uma necessidade urgente para a sobrevivência da organização.
Um Choque de Realidade
Conseguir prioridade e orçamento para iniciativas que envolvem transformações profundas, como uma revolução arquitetural, pode ser especialmente desafiador. Muitas vezes, a alta gestão prioriza projetos claramente conectados ao aumento imediato de receita ou ao lançamento de novos produtos. Projetos técnicos, especialmente aqueles focados na melhoria estrutural, são considerados menos urgentes, apesar dos riscos reais e imediatos que apresentam. Nesse contexto, para convencer os executivos da empresa, pode ser conveniente que o líder de tecnologia “Dê um Susto Neles”.
A ideia central é simples: para convencer executivos e líderes sobre a importância e urgência de transformar a arquitetura existente, demonstre claramente (e até dramaticamente) os riscos que a situação atual representa para a organização. Muitas vezes, líderes de negócio e executivos só conseguem perceber plenamente a gravidade de um risco quando confrontados com eventos negativos reais ou iminentes, como atrasos significativos, falhas críticas ou indisponibilidade dos sistemas mais importantes.
A aplicação efetiva dessa tática requer assertividade, clareza e coragem. Líderes técnicos precisam estar preparados para usar eventos negativos recentes como exemplos concretos. É necessário que os problemas sejam apresentados com transparência e honestidade, sem amenizar ou suavizar a realidade por receio de parecer irresponsável. Pelo contrário: assumir abertamente a responsabilidade pelos problemas atuais, explicando claramente suas causas e consequências, é essencial para gerar confiança e demonstrar compromisso genuíno com a solução definitiva.
Essa abordagem deve ocorrer de preferência em momentos estratégicos, como reuniões executivas regulares ou reuniões convocadas especificamente para tratar dos desafios arquiteturais. No entanto, ela também pode surgir espontaneamente, durante crises ou incidentes inesperados, como no caso do Carlos, quando uma falha crítica surgiu justamente durante sua apresentação para a diretoria. Aproveitar esses momentos para demonstrar a conexão direta entre a arquitetura deficiente e impactos críticos no negócio pode acelerar significativamente a percepção da necessidade da mudança.
Porém, “Dar um Susto Neles” não se limita a apenas expor o problema: é essencial que, logo após destacar os riscos de forma enfática, a liderança de tecnologia esteja preparada para apresentar uma solução concreta e viável. Por isso, é importante ter na manga um plano estruturado e modular, capaz de direcionar imediatamente a conversa para ações práticas. Além disso, esteja pronto para receber críticas, ouvir contrapontos e negociar adaptações, mantendo uma postura aberta e colaborativa durante toda a discussão.
É importante que a liderança de tecnologia faça uma leitura cuidadosa do ambiente antes de “Dar um Susto Neles”. Em algumas organizações, a transparência excessiva pode ser punida, inclusive com a demissão do mensageiro das más notícias. Além disso, se as ameaças referidas não forem tão graves como se está sugerindo, pode-se ficar com a impressão de que a liderança técnica está dando um alarme falso, prejudicando a iniciativa da revolução de arquitetura, ao invés de ajudá-la. Por fim, se não existir um plano concreto e acionável, o ato de dar o susto pode ser visto apenas como uma choradeira sem propósito, trazendo consequências negativas para quem o coloca em prática.
A ideia “Dê um Susto Neles” não é assustar por assustar, mas sim tornar visíveis e claros os riscos reais que estão frequentemente escondidos sob soluções paliativas. É transformar o medo abstrato em consciência real, engajamento genuíno e ação concreta. Assim, as organizações podem ser mobilizadas para não apenas de perceber a necessidade urgente da revolução arquitetural, mas de apoiá-la de maneira efetiva e estratégica.
Siga o Itshow no LinkedIn e assine a nossa News para ficar por dentro de todas as notícias do setor de TI e Cibersegurança!
