Tenho observado a relutância de muitos pela atualização tecnológica de software, e ao mesmo tempo, uma busca desenfreada por parte de outros por essa atualização constante. Componentes, ORM’s e bancos de dados são frequentadores constantes de discussões quando o assunto é atualização de software.

Não dá para estabelecer um padrão. Cada caso é único, mesmo em projetos muito parecidos ou com as mesmas características. Então, comecei a pensar em algumas questões que podem ajudar no momento de definir a melhor estratégia.

Quais seriam as motivações para a atualização?

Quando a questão é bug, a justificativa é sempre mais forte. Os profissionais com um pouco mais de experiência sabem bem o que é conviver com uma versão de software que te força utilizar certos tipos de recursos e contornos para resolver algum de problema ou limitação presente na versão utilizada.

Quando a motivação é somente por manter atualizado, geralmente fico com uma pulga atrás da orelha; contudo, um colega de trabalho tem uma justificativa que achei muito interessante: manter o software atualizado nos força a utilizar novos recursos, evita a utilização de recursos descontinuados e reduz o impacto futuro de outras atualizações. Mas cuidado com essa dança do dois pra frente e um pra trás, porque enquanto o sistema está sendo desenvolvido, fica realizando atualizações que forçam um retrabalho de adaptação.

Quais os custos?

Os custos variam muito em função do projeto e do software e são sempre significativos. Grande parte desses softwares é comercializada por licença de desenvolvedores, limites de distribuição ou quantidade de usuários finais. Essa multiplicação de valor pode deixar a brincadeira muito mais séria. Além disso, temos a mão-de-obra. Analistas e programadores que realizarão as alterações necessárias para comportar a atualização. Deslocar parte da equipe para uma tarefa de atualização de tecnologia pode custar caro.

Quem vai pagar a conta?

Ao bem da verdade, na grande maioria das vezes, o maior beneficiado pelas atualizações é a empresa desenvolvedora do software. Nada mais justo que ela pague a conta, salvo casos em que o cliente solicita modificações que forçam uma atualização.

Passei por uma situação com um software legado, em que a empresa substituiu o sistema operacional nas máquinas clientes e o acesso a banco de dados, que era feito através de ODBC, não podia mais ser utilizado. Solução? Atualizar os componentes de acesso a dados para uma versão que possibilitava o acesso nativo ao banco. Nesse caso, quem pagou a conta foi o cliente.

Mas e o impacto no projeto?

Esse, talvez seja o ponto mais complexo da questão, pois os impactos podem ser de origem financeira, em esforço de alteração do código-fonte, como já foram citados, e até no prazo do projeto.

Independente de qualquer coisa, um ponto determinante é a fase em que o projeto se encontra. Um exemplo: O projeto está com aproximadamente 70% concluído, sendo que, as tecnologias utilizadas não impactam no projeto com relação à bugs, mas também não possuem alguns recursos e os mesmos foram contornados com utilização de algumas técnicas. Certamente, o ideal seria atualizar as tecnologias incorporadas ao projeto após a sua conclusão, para, assim, reduzir o impacto.

Recomendações?

Com base em observações e experiências obtidas, recomendaria:

• Faça uma análise de escopo de alteração;
• Faça uma estimativa de esforço na alteração do projeto;
• Faça uma análise de riscos. Sugiro a utilização das técnicas do PMI;
• Faça uma análise dos custos;
• Não atualize uma tecnologia em um projeto antes de testar em sistemas pilotos;
• Não se esqueça de verificar junto aos clientes o impacto da atualização pretendida;
• Se a tecnologia envolver componentes, avalie fortemente a possibilidade de aquisição do código-fonte dos mesmos.

No mais, cuidado com as armadilhas pelo caminho e nunca despreze os detalhes. Boa sorte e até a próxima.