As 4 armadilhas que estão a impedir a atualização do seu sistema legado — e como escapar-lhes

Escalabilidade insuficiente, dívida técnica crescente e riscos de conformidade – estes são sinais de que o seu sistema legado precisa de ser substituído. Os sistemas legados podem parecer cavalos de batalha fiáveis—de confiança e familiares—mas, por baixo da superfície, podem acumular silenciosamente dívida técnica, bloquear a inovação e representar riscos significativos de conformidade.

Os sinais são claros e os riscos estão a aumentar, mas continua a adiar a decisão trimestre após trimestre. Como Mohan Sitaram salienta em Os Fantasmas das Redes do Passado, "os sistemas legados podem parecer inofensivos até começarem a causar estragos." Se esta situação lhe parece familiar, está a experienciar aquilo a que chamo "paralisia da migração" – e não está sozinho. 

Neste artigo, vamos analisar as quatro maiores barreiras à migração—perfeccionismo, medo do fracasso, adiamentos intermináveis e a busca de consenso—e apresentar estratégias práticas para as ultrapassar. Se tem vindo a adiar uma migração crítica, este guia ajudá-lo-á a ultrapassar a inércia e a tomar medidas decisivas antes de os custos se tornarem incomportáveis.

As Quatro Armadilhas da Paralisia da Migração

1. A Síndrome do "Próximo Trimestre"

Todos conhecemos esta situação: "Tratamos disso depois da época festiva, da próxima ronda de financiamento ou de uma grande versão." A verdade é que nunca existe uma altura perfeita para a migração. Esperar por esse momento perfeito e mítico cria problemas mais significativos do que aqueles que evitamos.

Recentemente, trabalhei com um CTO que planeava migrar o sistema de processamento de pagamentos há seis trimestres consecutivos. "Fazemo-lo logo depois da Black Friday" transformou-se em "Esperemos até depois das vendas do Dia dos Namorados" e, depois, em "Talvez depois da época de verão." Entretanto, as suas correcções "temporárias" estavam a tornar-se arquitectura permanente e a sua dívida técnica acumulava-se mais depressa do que uma conta de cartão de crédito depois do Natal.

O ponto de viragem surgiu quando começaram a acompanhar o "custo do adiamento" – não apenas em dinheiro, mas também no moral da equipa e nas oportunidades perdidas. Todas as segundas-feiras, analisavam um painel simples que apresentava as horas gastas em correcções de emergência, métricas de degradação do desempenho e o tempo perdido em novas funcionalidades. Quando perceberam que a equipa passava mais de 20% do seu tempo apenas a manter tudo a funcionar, o mito da "altura perfeita" acabou finalmente por desmoronar-se.

Eis o que acontece enquanto esperamos pelo próximo trimestre:

• Os problemas menores acumulam-se e transformam-se em problemas sistémicos
• As correcções rápidas tornam-se arquitectura permanente
• A dívida técnica acumula juros exponenciais
• A "altura perfeita" torna-se progressivamente mais difícil de encontrar

Estabeleça gatilhos inegociáveis para si próprio. Este CTO definiu uma regra simples: se as correcções de emergência ultrapassassem 20% do tempo de desenvolvimento durante dois meses consecutivos, a migração passaria automaticamente a ser discutida ao nível do conselho de administração. Não era necessário continuar à espera do momento perfeito – apenas tomar decisões claras e baseadas em dados.

2. A Falácia da Perfeição

"Se vamos fazer isto, temos de fazê-lo bem." Parece razoável, não parece? Isto é perfeccionismo disfarçado de profissionalismo. É a voz que o convence a adiar a acção até ter o plano perfeito, a equipa perfeita e as circunstâncias perfeitas.

Em tempos, fui mentor de um CTO de uma empresa fintech em crescimento que tinha o plano de migração mais detalhado que alguma vez tinha visto. Incluía diagramas abrangentes da arquitectura, avaliações de risco exaustivas, planos de contingência perfeitos – tudo o que possa imaginar. O único problema era estar guardado no Confluence há 18 meses, a receber actualizações regulares, mas sem nunca ver a luz do dia.

A descoberta surgiu na sequência de uma crise inesperada: um concorrente lançou uma funcionalidade que deveria ter demorado semanas a replicar, mas a equipa estimou que precisaria de meses devido às limitações do sistema legado. Foi então que percebeu que uma migração suficientemente boa, executada hoje, é melhor do que uma migração perfeita que nunca começa.

Abandonaram o plano gigantesco e começaram com uma pergunta simples: "Qual é a parte mais pequena que podemos migrar e que faria uma diferença real?" Identificaram o serviço de notificações – um componente gerível com limites claros.

O plano de migração era perfeito? Não. Encontraram alguns obstáculos? Sim. Mas, três meses mais tarde, tinham o primeiro serviço a funcionar numa infraestrutura moderna e, mais importante ainda, tinham criado dinâmica.

3. A Armadilha da Preservação da Carreira

Sejamos honestos: migrações falhadas já puseram fim a carreiras. Este medo leva muitos CTO a escolher o mal que conhecem em vez do mal que desconhecem. Afinal, ninguém foi despedido por manter o status quo... até isso acontecer.

Um colega meu aprendeu isto da forma mais difícil. Era o CTO de uma plataforma de comércio electrónico bem-sucedida que funcionava com um sistema cuja arquitectura tinha sido concebida pessoalmente por ele anos antes. "É estável", dizia nos nossos encontros. "Porque havemos de arriscar e perturbar o equilíbrio?" Era respeitado na empresa e elogiado por manter tudo a funcionar sem problemas.

Depois veio a Black Friday. O sistema de processamento de encomendas, que tinha sido "estável" durante anos, não conseguiu lidar com os novos padrões de carga. A interrupção durou seis horas – uma eternidade em tempo de comércio eletrónico. A primeira pergunta do conselho de administração não foi sobre a interrupção, mas sobre o motivo pelo qual não tinham sido avisados das limitações do sistema.

A ironia? Ao evitar o risco profissional de uma migração falhada, muitas vezes garantimos o resultado que estamos a tentar evitar. Os sistemas não envelhecem como o vinho fino.

4. A paralisia do consenso

"Precisamos que todos estejam de acordo antes de avançar." Embora o apoio das partes interessadas seja importante, esperar por um consenso universal é uma receita para a inação. Equipas diferentes têm prioridades diferentes e haverá sempre alguém com uma razão para esperar.

Lembro-me do CTO de uma empresa de software médico, determinado a fazer as coisas "da forma correta" – obter o apoio do responsável de cada departamento antes de iniciar a migração. O departamento financeiro estava preocupado com os custos, as vendas precisavam de garantias de tempo de inatividade zero, as operações queriam esperar até depois da época de maior procura e o departamento jurídico tinha preocupações relativamente à conformidade durante a transição.

Seis meses de reuniões depois, continuavam no ponto de partida. O momento decisivo surgiu quando mudou a sua abordagem: em vez de procurar uma aprovação unânime, começou a formar uma coligação de pessoas dispostas a avançar. Identificou as equipas mais afetadas pelas limitações do sistema legado – neste caso, os departamentos de agendamento de consultas e faturação – e transformou-as nas suas promotoras da migração.

Em vez de tentar responder antecipadamente às preocupações de todos, realizaram uma migração-piloto apenas com estes dois departamentos. Este esforço direcionado conseguiu fazer aquilo que meses de reuniões não tinham conseguido: demonstrou benefícios concretos que convenceram outras partes interessadas a aderir.

Liberte-se: o quadro de decisão

É aqui que se passa da teoria à prática. Depois de ver inúmeros CTOs a enfrentar estes desafios, desenvolvi um quadro que ultrapassa as barreiras psicológicas e o encaminha para a ação. Vamos percorrer cada passo, com exemplos reais de como líderes tecnológicos bem-sucedidos os utilizaram.

Passo 1: reconheça os seus preconceitos

Comece por reconhecer quais dos padrões acima estão a afetar a sua tomada de decisões. Isto não diz respeito a um CTO bem-sucedido que me disse certa vez: "A parte mais difícil não foi identificar os desafios técnicos – foi admitir que os meus medos eram o maior obstáculo." Ela tinha vindo a adiar uma migração crítica devido a uma falha anterior noutra empresa. Só ao reconhecer explicitamente este preconceito conseguiu avaliar objetivamente a situação atual.

Comece por colocar a si próprio estas perguntas:

• Estou a evitar esta migração devido a experiências passadas?
• Exagerei a estabilidade do nosso sistema atual perante as partes interessadas?
• Estou a deixar que o ótimo seja inimigo do suficientemente bom?

Isto não diz respeito a atribuir culpas – trata-se de eliminar obstáculos mentais.

A parte mais difícil da migração não é o desafio técnico—é decidir começar.

Passo 2: reformule a pergunta

"Devemos migrar?" é a pergunta errada. Coloca-o numa mentalidade de sim/não, na qual os riscos parecem impossivelmente elevados. Aprendi esta lição com o CTO de uma plataforma de comércio retalhista que estava a ter dificuldades com a decisão, até alterar completamente a forma como a encarava.

Em vez da pergunta avassaladora "Devemos migrar?", começaram a fazer perguntas mais específicas, que exigiam respostas concretas:

"Qual é o verdadeiro custo de esperar mais um trimestre?" 

Calcularam não só os custos de alojamento, mas também as horas dos programadores gastas em soluções alternativas, as funcionalidades que não conseguiam lançar e as oportunidades de mercado que estavam a perder. Quando perceberam que pagavam $50,000 por mês apenas para manter o status quo, a clareza relativamente à decisão surgiu naturalmente.

"Se fosse contratado hoje, o que faria?"

Este exercício mental libertou-os do peso das decisões passadas. "Foi libertador", disseram-me. "Quando analisei a nossa pilha tecnológica como um recém-chegado faria, o caminho a seguir tornou-se óbvio. Ninguém escolheria criar aquilo que estávamos a manter."

"Estou a preservar a estabilidade ou a preservar problemas?"

Esta pergunta revelou que o seu sistema «estável» era um castelo de cartas que exigia esforços cada vez mais heroicos. Aquilo a que chamavam estabilidade era apenas caos familiar.

Passo 3: O método das duas listas

Um diretor de tecnologia de uma empresa de tecnologia financeira com quem trabalhei estava bloqueado pela paralisia da análise até experimentarmos este exercício simples, mas poderoso. Pegámos num quadro branco e dividimo-lo em duas colunas:

«Problemas que vão piorar se esperarmos:»

• Os seus programadores mais experientes estavam a ficar frustrados e a dar indícios de que queriam sair
• A dívida técnica acumulava-se todos os meses
• A aplicação de correções de segurança estava a tornar-se mais complexa
• Cada nova funcionalidade demorava mais tempo a implementar do que a anterior
• As reclamações dos clientes sobre a velocidade do sistema estavam a aumentar

«Problemas que vão ficar mais fáceis se esperarmos:»

• As ferramentas de migração poderão amadurecer ainda mais
• A equipa poderá ganhar mais experiência com as novas tecnologias
• Poderemos poupar mais orçamento para o projeto

Ao olhar para estas listas lado a lado, a decisão tornou-se subitamente clara. A coluna «esperar» consistia sobretudo em benefícios hipotéticos, enquanto a coluna «agir agora» estava cheia de problemas concretos e crescentes.

Tome a decisão: uma abordagem baseada na realidade

A regra dos 70%

Não precisa de 100% de certeza – uma lição que aprendi com um diretor de tecnologia de software de saúde que esperou demasiado tempo por «clareza total». Após o terceiro trimestre de atraso, um concorrente lançou uma funcionalidade semelhante em metade do tempo porque compreendeu algo crucial: não precisa de ter todas as respostas; precisa de ter respostas suficientes.

Eis o que significa «suficiente»:

70% de confiança na sua avaliação

«Tinha uma folha de cálculo complexa onde acompanhava todos os riscos possíveis», contou-me ela, «mas o meu mentor fez-me uma pergunta simples: “Se tivesse de tomar esta decisão com base no que sabe neste momento, sentir-se-ia mais certa do que errada?” Foi então que percebi que me estava a esconder atrás da análise.»

70% das partes interessadas principais a bordo

Repare que isso não significa toda a gente – trata-se da massa crítica necessária para criar impulso. Um diretor de tecnologia do setor retalhista partilhou a sua estratégia: «Mapeei as preocupações das partes interessadas numa matriz simples: impacto elevado/impacto reduzido, favoráveis/resistentes. Quando o grupo favorável e de impacto elevado estava alinhado, isso foi suficiente para começar. Os restantes aderiram quando viram os primeiros resultados.»

70% das questões críticas respondidas

As questões a que não consegue responder agora tornar-se-ão mais claras assim que avançar. Uma equipa criou três categorias de perguntas:

• É obrigatório responder antes de começar
• Podemos responder à medida que avançamos
• Seria útil ter a resposta, mas não é um impedimento

Chegar aos 100% é frequentemente mais dispendioso do que lidar com os 30% de incerteza durante a execução. O seu trabalho não é eliminar todos os riscos – é torná-los geríveis.

O teste da reversibilidade

Um diretor de tecnologia de uma empresa de jogos ensinou-me esta abordagem. Para cada ponto de decisão importante, faça três perguntas:

É possível reverter esta decisão, se necessário?

Criaram «saídas de emergência» – caminhos claramente documentados de regresso ao estado anterior em cada fase da migração. «Ter uma forma de voltar atrás tornou-nos mais corajosos para avançar», explicou ele.

Qual é a nossa posição de recurso? 

Mantiveram o sistema antigo em modo só de leitura durante o dobro do tempo que consideravam necessário. Dispendioso? Sim, mas permitiu-lhes dormir descansados.

Qual é o custo real de estar errado?

Não o cenário catastrófico em que tudo falha, que a sua ansiedade imagina, mas o pior caso realista. Normalmente, é muito mais fácil de gerir do que receia.

Os primeiros 30 dias

Semana 1: Ciclo intensivo de decisão

• Segunda-feira: Reunir as métricas críticas
• Terça-feira: Entrevistas com as partes interessadas
• Quarta-feira: Avaliação dos riscos
• Quinta-feira: Elaborar o primeiro rascunho do plano
• Sexta-feira: Ponto de decisão

Semanas 2-3: Criação de dinâmica

• Anunciar a decisão com clareza
• Configurar um centro de comando para a migração
• Iniciar ações pequenas e concretas
• Celebrar as primeiras vitórias

Semana 4: Arranque da execução

• Lançar o projeto-piloto
• Estabelecer ciclos de retorno
• Definir métricas de progresso
• Agendar pontos de verificação regulares

Em suma

A parte mais difícil da migração não é o desafio técnico – é decidir começar. As barreiras psicológicas à migração ultrapassam frequentemente as barreiras técnicas. O medo do fracasso, o perfeccionismo, a procura de consenso e o fascínio do "próximo trimestre" podem paralisar até os líderes tecnológicos mais experientes.

Mas também vimos como os CTO bem-sucedidos ultrapassam estas barreiras. Fazem-no não eliminando todos os riscos ou alcançando um consenso perfeito, mas sim:

• Transformando receios vagos em métricas mensuráveis
• Dividindo decisões aparentemente monolíticas em passos mais pequenos e reversíveis
• Criando coligações em vez de esperar por um acordo unânime
• Usando a regra dos 70% para avançar com o "suficiente" em vez de com "tudo"

Talvez o mais importante seja termos aprendido que as decisões de migração não acontecem em momentos únicos e dramáticos. Resultam de estruturas sistemáticas, sinais claros e uma autoavaliação honesta.

As migrações mais bem-sucedidas a que assisti não foram as que tinham planos perfeitos – foram aquelas em que os líderes compreenderam e geriram a sua psicologia com o mesmo cuidado que dedicaram aos seus sistemas.

Subscreva o boletim informativo do The CTO Club para obter mais informações sobre migração de software.