O fantasma da atualização
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, ou seja, enquanto o sistema está sendo desenvolvido, ficar 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 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 à bug´s, 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 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, nunca despreze os detalhes, boa sorte e até a próxima.
RSS dos Comentários
Siga-nos no Twitter