Engenharia de software, gurus e evangelizadores.

Estranha a nossa engenharia de software que tem gurus.

Sempre me chamou a atenção em eventos de tecnologia da informação o fato de que novas tecnologias são defendidas por gurus e evangelizadores.

Se um engenheiro civil desenvolve uma nova técnica para construir pontes, ele precisa apresentá-la para os seus pares com dados empíricos, estatísticas e pesquisas bem embasadas que comprovem a superioridade da nova técnica sobre as que estão em uso. Desta forma, ele pode convencer outros engenheiros a empregá-la. Não adianta que ele seja persuasivo, fale bem ou dê excelentes palestras. Os outros engenheiros não vão arriscar o uso de algo novo baseado nisso.

Na engenharia de software, no entanto, temos o título formal - e algumas empresas tem mesmo esses cargos em seus quadros - de guru, ou evangelizador, como alguém responsável por disseminar uma nova tecnologia. É comum irmos a palestras e um guru nos explicar porque o twitter ou o Facebook, por exemplo, vão revolucionar a forma de comunicação entre pessoas e sistemas dentro das corporações e porque eles devem ser incorporados de imediato ao dia a dia das empresas. Raramente, no entanto, nos é apresentado qualquer dado ou fato que comprove que esta mudança ocorrerá ou revolucionará para melhor os processos e negócios das corporações. Não tenho nada contra twitter e Facebook e a revolução que eles vêm causando fora das corporações. O meu ponto é: se queremos que a engenharia de software seja uma engenharia, precisamos suportar as nossa técnicas e tecnologias com dados empíricos.

Os gurus e evangelizadores são profundos conhecedores das novas tecnologias, metodologias e técnicas que apresentam, mas a metáfora voltada pra fé, e não fatos, acaba por depor contra a engenharia de software como uma verdadeira engenharia.

Sei da dificuldade de se obter dados empíricos e estatísticos sobre desenvolvimento de software, mas um bom começo no dia a dia do engenheiro de software seria usar as estatísticas do próprio profissional envolvido. Um gerente de projetos, por exemplo, pode se apresentar ao início de uma empreitada detalhando o seu portfólio: quantos projetos já tocou, quantos relacionados ao que ele está começando, qual sua taxa de sucesso e insucesso e o quê, com base em dados empíricos, ele percebeu que pode ser feito em um projeto para levá-lo ao sucesso ou reduzir ao máximo a possibilidade de problemas.

Se agirmos com este espírito, os nossos clientes se sentirão mais seguros e, um dia, a nossa disciplina pode deixar de ser vista com tanta desconfiança pelas corporações. Ou nunca aconteceu de você ser olhado de lado, no início de um projeto, por um cliente desconfiado que já tem uma lista de projetos de TI traumáticos no seu passado?