Bem-vinda à parte 3 de nossa série Rompendo com o legado – nove lições para líderes de negócios. Na parte 1, exploramos a cultura e ações, e na parte 2 exploramos clientes, ativos de dados e asseguramos que você tenha foco. Aqui, vamos explorar as lições específicas sobre aspectos que afetam a amplitude e a profundidade da sua modernização.
No ensaio “Things you should never do”, Joel Spolsky diz que reescrever o código para manter a mesma funcionalidade é o pior erro estratégico que uma organização pode cometer. Você está dando um presente de pelo menos dois ou três anos a seus concorrentes, pois não poderá fazer nenhuma mudança estratégica ou reagir a novas características que o mercado exige e provavelmente verá sua participação de mercado cair a pique. Há muitos exemplos de programas de software que tentam reescrever e, portanto, desperdiçam milhões de dólares.
Então, o que uma organização deve fazer se você for pego no Vórtice da Ruína – quando a mudança é lenta e dolorosa, e as organizações tentam consertá-la adicionando mais processos, o que torna as coisas mais lentas? Às vezes, surgem soluções criativas – que tentam ‘inovar’ adicionando uma nova interface de usuário sem arrumar as fundações. Mas você não pode esconder por muito tempo quando não está satisfazendo as necessidades das clientes, a concorrência te alcança.
Se você não investiu em seus sistemas por muito tempo e as melhorias incrementais não funcionarem no ritmo necessário, você pode não ter muitas opções; reescrever é algo que você deve considerar. Antes de embarcar nessa jornada, confira algumas considerações:
A base de códigos legada está realmente prejudicada, não tem conserto? Alguma coisa pode ser recuperada?
Os sistemas legados estão tão interligados que mesmo mudanças simples requerem uma cascata de mudanças para outras partes do código?
A escolha da tecnologia original está impedindo ou restringindo a realização de melhorias?
A tecnologia original não tem suporte?
A capacidade está diminuindo rapidamente na organização e na indústria?
Os concorrentes estão tirando vantagem de sua falta de responsividade?
Qual é a direção geral do mercado para seu produto ou serviço? Seu jeito atual de fazer as coisas ainda é perfeito ou precisa ser renovado ou repensado?
Se a reescrita é a abordagem correta, então algumas das coisas a ter em mente são:
Evite substituir seu software por uma nova versão da mesma coisa, mas construa algo novo sem jogar fora o que você tem;
Certifique-se de estar removendo funcionalidades que não são necessárias – e use dados, não sentimentos, para fazer isso.
Não entre num ciclo de pilotos e provas de conceitos que não vão a lugar algum, tenha um plano para operacionalizá-los ou eliminá-los logo quando você tiver os dados relevantes;
Assegure-se de buscar a solução do problema de maneira completamente diferente, dadas as opções que a nova tecnologia oferece;
Lembre-se de levar adiante os ensinamentos de seu legado, especialmente as ideias para uma abordagem fundamentalmente nova.
8. Não deixe a complexidade se infiltrar
A complexidade dos sistemas de software pode ser difícil e frustrante para um executivo compreender. O que pode parecer um simples pedido – “Eu só quero um novo botão em uma tela” –, às vezes pode ser realmente difícil e demorado para o time que o implementa, especialmente quando há uma grande complexidade e legado no interior do sistema.
Sistemas complexos muitas vezes se tornam mais lentos e morosos para mudar. Por causa disso, vemos que lentamente emerge uma atitude “eles e nós” na organização, em que a divisão entre negócios e TI começa a se tornar um abismo que parece impossível de ser transposto. Normalmente, devido à frustração empresarial ao achar que algo é simples quando na verdade não é.
Se tentarmos entender por que isto está acontecendo, precisamos compreender a diferença entre a complexidade inerente e a complexidade acidental. A complexidade inerente de um sistema é inevitável, algo com que qualquer pessoa que tente construir um sistema de software tem que lidar (e às vezes é necessária, dependendo de seu domínio). Por outro lado, a complexidade acidental é algo que acontece com as decisões de todos os envolvidos na criação de software – desde o desenvolvedor que escreve o código, o gerente de produto que decide a prioridade de uma feature, até o executivo que decide quais investimentos devem ser feitos.
O resultado de todas essas decisões muitas vezes termina no que os times chamam de “dívida técnica”. As características da dívida técnica são muito parecidas com a do mundo real – se ela se tornar insustentável, ela irá paralisar o sistema e os impactos serão generalizados.
Uma pesquisa realizada em 2018 pela empresa de pagamentos Stripe descobriu que, em média, 40% do tempo dos desenvolvedores é desperdiçado em lidar com códigos ruins e consertar dívidas técnicas. Médias nem sempre são medidas úteis, mas ajudam a entender tendências. Nossa experiência de trabalho com organizações nos diz que, na maioria dos sistemas (mais) antigos, especialmente qualquer coisa em produção e ainda em desenvolvimento ativo há mais de um ano, o número é significativamente maior. O custo do código ruim não é apenas o que é gasto em termos de horas para entender o que ele faz ou para refatorá-lo e limpá-lo, mas também em como ele prejudica os clientes. Isso é significativamente maior em termos de impacto econômico. Às vezes, é possível esconder um código ruim atrás de uma boa UX por um curto período, mas as falhas logo vêm à tona e logo você deixa de atender às necessidades dos clientes. Em um mundo altamente competitivo, os concorrentes tirarão vantagem de qualquer uma de suas ineficiências. Portanto, deve ser simples entender que a má qualidade de código é ruim para os negócios.
Aqui estão alguns dos pontos-chave que tentamos entender quando falamos com nossas clientes para avaliar o nível de complexidade acidental:
Qual é o tempo de processamento da ideia à produção para uma nova funcionalidade? Isto tem aumentado com o tempo para funcionalidades complexas e parecidas?
Qual é a cultura em torno dos testes automatizados, das falhas nos testes e das implantações?
Seus times examinam regularmente a complexidade ou outras análises relevantes em suas bases de código? Eles acompanham as tendências destas mudanças ao longo do tempo e entendem se são as tendências certas?
Como seu time trabalha com a dívida técnica (isto é, complexidade intencional)?
Quanto tempo leva para se recuperar de interrupções de serviço?
Quanto de seu esforço de desenvolvimento vai para suporte/manutenção dos sistemas existentes para mantê-los funcionando em comparação com a construção de novas características? O custo de manutenção está aumentando com o tempo?
Organizações inteligentes realmente usam orçamento para melhorar a qualidade do código. Os pagamentos de dívidas técnicas não são apenas exercícios de reflexão ou coisas da boca pra fora, mas planejados e executados.
Concentre-se na construção de uma cultura de engenharia em contínua melhoria, assim como no apoio e investimento para melhorar a compreensão de como a qualidade do código melhora a capacidade de construir produtos mais novos e mais agradáveis.
9. Você não vai precisar disso (You aren’t gonna need it – YAGNI)
O ponto acima, sobre seus ativos, vê coisas a acrescentar como parte de uma transformação e indica que, como com qualquer coisa adicional, incorrerá em um custo não planejado. Mas isso sempre tem que ser um custo adicional líquido? A resposta é ‘não’.
“Um antipadrão que continuamos vendo é o legado de paridade de funcionalidades na migração de legados, o desejo de manter a paridade de funcionalidades com os sistemas antigos. Vemos isto como uma grande oportunidade perdida. Frequentemente, os sistemas antigos incham com o tempo, com muitos recursos que não são usados pelos usuários e processos de negócios que evoluíram com o passar do tempo. Substituir estas funcionalidades é um desperdício.” – Thoughtworks Technology Radar — Paridade de funcionalidades de migração de legados
Há uma concepção errônea de que, ao renovar um patrimônio legado, o que importa é a paridade de funcionalidades. Na verdade, esta é a oportunidade de levar frescor ao que seus clientes e usuários precisam destas plataformas. Como foi chamado no manual de modernização do legado, vemos a paridade de funcionalidades como um antipadrão: ela deve ser evitada, e não transformada no ponto de partida para uma revisão do legado.
Ao invés disso, você precisa analisar o que é realmente necessário e tomar a decisão certa para seu investimento. Concentre-se naquilo que traz o maior valor para sua empresa e seus clientes. É aqui que a evidência e as decisões baseadas em dados são fundamentais:
Quais são as funcionalidades mais comumente utilizadas em seus sistemas existentes? Este uso indica quão importantes são as funcionalidades para seus usuários. Você tem os dados que comprovam isso?
É a Eficiência de Pareto, ou seja, o conjunto ideal de funcionalidades para os clientes finais equilibrado pelo custo dos recursos, ou você tem que enfrentar a cauda longa, ou seja, funcionalidades que existem para satisfazer clientes individuais e têm um custo proibitivo de manutenção?
O que custa mais para continuar? Você entende realmente uma funcionalidade ou valor de negócio em comparação com o custo de suporte e manutenção?
Quais funcionalidades que você sabe que foram importantes no passado, mas não serão no futuro?
O que você consegue ver acontecendo em seu espaço de mercado de maior valor que o atrai a abrir mão de funcionalidades de baixo/mais baixo valor estão em seus sistemas?
Se você tiver que escolher dar a si mesmo opções mais amplas para uma futura agilidade e flexibilidade comercial – por exemplo, para incorporar dados como mencionado acima –, do que você vai desistir ao não mudar do legado para o novo, para liberar os orçamentos?
Uma transformação nunca deveria se tratar de pegar tudo o que tínhamos antes e replicar exatamente numa tecnologia novinha em folha. Trata-se de agarrar agressivamente as oportunidades para torná-la a melhor possível – o que inclui as decisões guiadas por evidências sobre o que parar de fazer.
Isto nem sempre é simples. Além da tecnologia legada, pode haver história, sentimentos, times e divisões inteiras impactadas pela descontinuidade de algo que não é mais economicamente viável. No entanto, financiar a curto prazo uma transformação ou, pior, perder o futuro da organização por causa do passado é quase sempre ainda mais prejudicial.
Nossa série Rompendo com o legado – nove lições para líderes de negócios destaca a importância de um novo pensamento sobre liderança e cultura, compreensão e o escopo do trabalho a ser feito.
Estas lições estão destruindo os livros sobre gestão das últimas décadas – elaborar estratégias que combinem “prosperar” com “sustentabilidade” requer um processo de mudança contínua. Esta é uma nova mentalidade, esperada ansiosamente pelos clientes e cidadãos, à qual as organizações precisam responder com abordagens ágeis e adaptativas.
Sendo uma consultoria tecnológica global, nós também, da Thoughtworks, temos que nos adaptar à medida que nossos mercados e necessidades dos clientes mudam rapidamente. Procuramos permanecer flexíveis e aprender com os setores, linhas de serviços e mercados. Esta mudança muitas vezes não é sem dor, mas achamos que vale a pena o ganho em sermos responsivos e relevantes.
Acreditamos que esta série tenha sido útil – se você estiver em um papel de liderança e tiver qualquer desafio que faça sentido em nossos artigos com sua organização, não hesite em entrar em contato.
Alguns artigos relacionados que você também pode querer ler:
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.
