Pode parecer estranho, mas software também envelhece. Por isso, precisamos estar preparados para seu processo de modernização. Afinal, uma abordagem inadequada pode custar muito caro e até mesmo colocar tudo a perder.
Programs, like people, get old. We can’t prevent aging, but we can understand its causes, take steps to limits its effects . . . and prepare for the day when the software is no longer viable. (Parnas, 1994)
Fazemos aqui, uma compilação do que acreditamos serem os principais motivos para grandes empresas falharem na modernização de software legado.
Equívoco #1 – Dar ênfase demasiada para motivações técnicas
Mais do que bom software, acreditamos que a tecnologia deve propiciar bons negócios. Mesmo que adotar as “tecnologias mais revolucionárias da última semana” possa fazer sua empresa parecer moderna e descolada, se o principal objetivo não for atender um objetivo concreto do negócio, o projeto estará ameaçado.
Tecnologia é o meio, não o fim. Mesmo que um dos objetivos do projeto seja abandonar uma tecnologia obsoleta, se não for gerado nenhum valor novo para o negócio, será difícil conseguir prioridade e, principalmente, orçamento frente a outras iniciativas.
Equívoco #2 – Acoplar excessivamente o novo ao legado
Para realizar entregas parciais é comum fazer com que o software novo utilize recursos do antigo, as vezes consumindo APIs do legado, outras vezes, até mesmo, usando a mesma base de dados.
Acreditamos que devemos priorizar entregas constantes e em ciclos curtos, mas a integração do sistema novo com o legado deve ser bem definida, delimitada e pouco acoplada.
Projetos descuidados, correm o risco de fundir o sistema legado de maneira tão intrínseca ao antigo tornando-os, ao longo do tempo, uma espécie de aplicação híbrida, novo e legado, onde o novo é incapaz de substituir seu antecessor.
É importante que características do legado sejam desativadas tão logo equivalentes estejam prontas no sistema novo. Além disso, é sempre interessante lembrar que 20% das features de um sistema correspondem a 80% do uso. Começar por estas funcionalidades costuma reduzir a “dor” da migração
Equívoco #3 – Não conseguir o patrocínio explícito de um sponsor executivo
É comum que ocorram pressões para desmobilizar times de projetos de modernização com o argumento de que o legado já funciona, portanto “refazê-lo” seria um desperdício. Também haverá forças políticas contrárias de pessoas que, por atuarem no legado, se sentem ameaçadas com a proposta de sua substituição e trabalharão contra.
Percebemos que se não há um patrocinador executivo forte, que tem clara a estratégia de negócio que esse projeto carrega, dificilmente haverá condições de resistir a todas as pressões.
É importante que o patrocinador executivo reconheça seu papel de maneira explícita. Por isso, ele deverá ser acionado sempre que apoio for necessário.
Equívoco #4 – Tornar-se legado antes mesmo de ir para produção
Todo projeto nasce com a melhor das intenções, fazendo uso do que há de mais moderno disponível na tecnologia. Entretanto, por falta de capacidade ou direcionamento, é comum que, para avançar, times assumam grande volume de dívidas técnicas.
[tweet]Um sistema se torna legado quando nossa capacidade de pagar dívidas técnicas é menor que a necessidade de contrair novas[/tweet]. Se os gestores não conseguem acomodar a pressão por entrega de novas features sem esquecer das questões técnicas que permitirão ao projeto evoluir de maneira sustentável, podemos ter um legado muito antes do que imaginamos. Talvez, até mesmo, antes de qualquer parte do projeto entrar em produção.
Concluindo
Para fazer com que projetos de software sejam bem sucedidos, deve-se estabelecer, antes de tudo, a motivação de negócio que deverá ser atendida. Para isso, é necessário tornar explícito quem será o patrocinador do projeto. Deve-se começar, como sempre, pelo que há de mais relevante e ter controle intensivo sobre o volume de dívidas técnicas assumidas.
Os equívocos descritos aqui são mais fáceis de identificar do que de evitar. Mas o esforço vale a pena.
