O poder econômico nas mãos de um desenvolvedor

Tenho visto na minha experiência profissional e nos diversos projetos em que já trabalhei um aspecto muito importante da profissão de desenvolvedor de software. O trabalho criativo e complexo de construção de um sistema e a entrega de um produto cria um bem passivo para qualquer organização. Este produto gera um custo de manutenção e, normalmente, este custo de manutenção não é contabilizado durante a fase de concepção do produto, é pensado apenas no retorno financeiro que aquele produto pode proporcionar, sem pensar no custo do total de propriedade, TCO em inglês.

O que o processo de construção de um produto busca, na maioria dos projetos que trabalhei, é um software funcionando. Mas será que um software funcionando pode gerar retorno econômico para um empresa? Simplesmente funcionar significa atingir seu objetivo? Quem já viu algum projeto onde o produto entregue nunca passa por mudanças?

Manter um software funcionando é o grande buraco na gestão do desenvolvimento de software, algo ainda distante da visão da empresa do ponto de vista econômico. Fazer é muito mais simples que manter, mudar é muito mais difícil do que simplesmente usar. É diante deste aspecto que vejo um grande poder nas mãos do profissional de desenvolvimento de software. Um código mal feito, uma rotina desenvolvida sem a visão do todo, um furo de performance, e principalmente a falta aplicação da Engenharia de Software podem resultar em um custo muito maior e não programado para um determinado produto. Um simples erro ou irresponsabilidade de um profissional durante a construção podem ocasionar um custo de manutenção tão grande que inviabilizariam, se pudessem ser contabilizados com antecedência, a construção de um produto.

A cultura das equipes de desenvolvimento que buscam “fazer o software funcionar” ao invés de “fazer software preparado pra mudar” precisa urgentemente ser revista e repensada, o profissional de desenvolvimento precisa conhecer as técnicas de abstração, precisa conhecer os padrões de projeto, precisa conhecer as ferramentas prontas e mais utilizadas no mercado para interface com o banco de dados, por exemplo, precisa conhecer as técnicas de Engenharia de Software, e precisa principalmente conhecer as metodologias de desenvolvimento que buscam a entrega do que agrega valor ao nosso usuário final, e não simplesmente um produto funcionando.

Não podemos mais utilizar metodologias que culpam as mudanças, que punem, às vezes até financeiramente, quem quer mudar o produto para agregar mais valor. O mercado é dinâmico, as empresas mudam com muito mais facilidade que antigamente, precisamos estar prontos pra isso, nossa metodologia deve estar pronta para mudanças e principalmente o nosso produto deve estar pronto para mudança. Isto é, na minha visão, atingir o resultado do desenvolvimento de um produto, e não simplesmente “funcionar”.