Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Rompendo com o legado – nove lições para líderes de negócios (Parte 3)

 

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.

 

Homem de costas olhando para um quadro com anotações

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.

tela do computador com códigos

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.

Mantenha-se atualizado com nossos insights mais recentes