No artigo anterior, conhecemos a história de uma empresa de serviços financeiros que, depois de decidir que sua área de Tecnologia iria se tornar ágil, encontrou diversos problemas na arquitetura de seus sistemas que impediam a realização das práticas ágeis. Esta história continua aqui.
Entusiasmo e Apreensão
Carlos saiu ao mesmo tempo energizado e preocupado da reunião com Ana, Jorge e os outros membros mais sêniores do time. Eles tiveram um acalorado debate sobre por que o time não conseguia trabalhar em ciclos curtos nem entregar valor com frequência, por que as estimativas de esforço acabavam quase sempre erradas e envolviam mudar muito mais componentes que o previsto e por que o time era frequentemente interrompido por problemas urgentes no ambiente de produção.
Ele estava energizado porque, pela primeira vez em muitos anos, viu o time discutir abertamente problemas reais com os sistemas, expondo várias causas raízes de problemas que os afetavam há anos. Por outro lado, Carlos estava preocupado porque sabia que atacar essas causas raízes significaria fazer mudanças profundas na arquitetura do sistema. E isso iria demandar mais tempo e dedicação do time, que já estava sendo questionado sobre por que a implantação da tão esperada metodologia ágil ainda não havia trazido resultados.
A Falta de Progresso
Nas próximas semanas, Carlos trabalhou intensamente com Ana, Jorge e um pequeno grupo de desenvolvedores mais experientes para priorizar as principais mudanças no sistema que iriam trazer os maiores impactos positivos sobre os problemas discutidos. Eles tentaram priorizar essas atividades junto com os gestores de produto, que definiam os backlogs dos times.
Porém, as semanas e meses seguintes foram de frustração. Os times já estavam com seus backlogs totalmente comprometidos com entregas de valor imediato para o negócio e os problemas que vinham encontrando já tinham provocado atrasos nas estimativas iniciais. Apenas algumas pequenas atividades de melhoria da arquitetura foram feitas nos meses que se seguiram e a situação continuou ruim.
Choque de Realidade
Após um incidente que deixou o principal sistema fora do ar por mais de uma hora em um horário de pico, Carlos concluiu que a situação só iria melhorar se o time realizasse uma mudança radical na arquitetura do sistema. Ele sentiu que todos aqueles problemas vindo à tona eram como um “despertar” para uma realidade que já estava presente há muito tempo. Transformar a arquitetura do sistema era uma questão de vida ou morte.
O Despertar nas Organizações
O momento vivido por Carlos e seu time, de forma geral, não é raro nas organizações. Pelo contrário: frequentemente empresas de sucesso enfrentam dificuldades em seus processos de desenvolvimento e entregas sem perceber, ou sem aceitar, que estão lidando com sintomas de problemas muito mais profundos. Esses problemas são tipicamente ligados a questões estruturais e arquiteturais dos sistemas, cuja resolução exige esforços maiores que ajustes pontuais nos processos ou nos times. O que Carlos estava vivenciando é o que chamamos de “Despertar”.
O Despertar acontece quando uma organização percebe, geralmente de forma intensa, que a arquitetura atual dos seus sistemas não consegue mais suportar as necessidades do negócio. Normalmente, esse momento não é súbito; ele surge como um acúmulo de problemas recorrentes, interrupções frequentes e dificuldades crescentes no desenvolvimento e manutenção do software.
Esses problemas podem ter origens diversas, que frequentemente são agrupadas em três categorias principais:
- Negócio: crescimento acelerado da empresa, surgimento de novos modelos de negócios, expansão geográfica, mudanças em regulamentações, entre outros fatores externos que exigem respostas rápidas e robustas do sistema.
- Organizacional: mudanças na estrutura da organização, como aumento expressivo do time de desenvolvimento, fusões, aquisições ou cisões, que geram complexidade adicional na comunicação e coordenação entre times e departamentos.
- Tecnologia: mudanças tecnológicas significativas, aumento de dívidas técnicas, surgimento de novos canais digitais (como aplicativos móveis ou plataformas adicionais), necessidade de redução de custos, fim do ciclo de vida de tecnologias utilizadas, além do acoplamento crescente entre componentes que dificultam alterações rápidas e seguras.
No caso da equipe liderada por Carlos, a origem do Despertar foi uma combinação desses três fatores. A tentativa frustrada de implantar agilidade, as interrupções constantes devido a problemas técnicos e a dificuldade de entregar funcionalidades no ritmo exigido pelo mercado apontaram claramente que havia um grande descasamento entre a arquitetura atual e o que o negócio precisava para avançar.
A equipe de Carlos se encontrava em uma situação na qual a única saída seria uma iniciativa dedicada para a transformação da arquitetura. Essa é a única solução quando as seguintes duas condições fundamentais estão presentes:
- Descasamento arquitetural: Existe um claro e evidente descompasso entre as capacidades atuais da arquitetura e as necessidades presentes ou futuras do negócio.
- Incapacidade de adaptação orgânica: Pequenos ajustes incrementais ou melhorias pontuais nos backlogs das equipes não são mais suficientes para resolver os problemas; é preciso uma intervenção profunda, radical e dedicada.
Quando essas duas condições são identificadas, fica claro que apenas ajustes paliativos não resolverão a situação. Um Despertar efetivo significa reconhecer a necessidade de uma mudança arquitetural profunda, geralmente envolvendo decisões difíceis e investimento significativo por parte da organização.
Uma vez que o Despertar aconteça, é fundamental trabalhar a conscientização contínua de toda a empresa sobre os impactos negativos da arquitetura existente e os benefícios potenciais da transformação arquitetural. Essa conscientização não deve ser limitada à área de tecnologia, mas deve incluir lideranças de todas as áreas, garantindo que estejam “no mesmo barco” e compreendam claramente o que está em jogo.
Carlos percebeu isso claramente após o incidente crítico no sistema. Para ele, estava evidente que não bastava apenas identificar o problema; ele precisava criar um plano claro e realista para comunicar à organização a importância e urgência dessa mudança. Além disso, seria necessário apresentar um caminho sólido e convincente para resolver esses problemas estruturais, destacando os riscos graves caso nenhuma ação significativa fosse tomada.
O Despertar não é apenas a identificação de sintomas técnicos ou operacionais. É um momento crítico de consciência organizacional sobre a necessidade urgente de uma transformação profunda, uma verdadeira revolução arquitetural que permita à empresa evoluir de forma saudável, inovar rapidamente e se manter competitiva em um mercado cada vez mais exigente e acelerado.
Depois de perceber que uma mudança radical precisava acontecer, Carlos pesquisou e viu que não estava sozinho. Empresas mundialmente famosas como LinkedIn, PayPal, eBay, Spotify, Uber e Airbnb já tinham enfrentado momentos semelhantes. Esses gigantes também tiveram seu próprio momento de Despertar quando perceberam que a arquitetura dos seus sistemas não acompanhava mais as necessidades do negócio.
Esses exemplos ilustram claramente que não existe uma receita universal, mas há um padrão em comum: o momento do Despertar. Além disso, mostram que empresas de sucesso passaram por grandes desafios em relação a suas arquiteturas de sistemas e conseguiram sobreviver e prosperar. Em outras palavras, o momento do Despertar pode ser decisivo para o futuro de uma organização. Carlos, na sua empresa, percebeu isso claramente após o incidente crítico e entendeu que precisava agir.
E você, líder de tecnologia, como está a situação da arquitetura dos sistemas na sua empresa? Você tem conseguido evoluir de forma saudável e sustentável? Ou os sintomas apresentados neste artigo lhe parecem familiares? Se as mudanças necessárias forem muito profundas e seu time não conseguir realizá-las organicamente ou por meio de melhorias incrementais, talvez seja o momento de encarar uma verdadeira revolução arquitetural. Não espere por mais uma crise: o momento de agir é agora.
Siga o Itshow no LinkedIn e assine a nossa News para ficar por dentro de todas as notícias do setor de TI e Telecom!
