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”.
Wellington, suas idéias são as sementes para a inovação — e você tem a atitude correta. Tornar o computador fluido programas é importante, mas está fazendo o trabalho de funcionalidade e tornando-o simpático. Há algumas línguas já pioneiro essas tendências – java é um bom exemplo, mas mucm mais ainda precisa ser descoberto.
Continue alimentando suas idéias com as possibilidades – é só errando que aprendemos, não é assim que Thomas Edison criou a lâmpada? As coisas não têm sido a mesma desde … É sempre a mais simples das idéias que tem o maior impacto.
Your ideas are the seeds for innovation — and you have the correct mindset. Making the computer programs fluid is important, but so is making the functionality work and making it friendly. There are some languages already pioneering these trends – java is a good example, but mucm more still needs to be discovered.
Keep feeding your ideas with possibilities — is only by making mistakes we learn, is this not how Thomas Edison created the light bulb? Things have not been the same since… Is always the simplest of ideas that has the biggest impact.