sexta-feira, 15 de junho de 2012

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?

terça-feira, 5 de junho de 2012

A tecnologia é a culpada por falhas em projetos de tecnologia da informação?



Eu já fui responsável e já participei de diversos projetos de tecnologia da informação. Já fui responsável por integrações de sistemas via Internet, implantações de pacotes de mercado, construção de soluções de negócios desenvolvidas do zero e implantação de ERP. Uma discussão constante em projetos de informática é o quanto o uso de uma nova tecnologia, seja nova no mercado ou nova para o grupo que a está implementando, é a culpada por atrasos, aumento de custo ou cancelamento dos projetos.

Bom, resolvi analisar os projetos que já fui responsável, e alguns que participei, pra tentar perceber se há esta correlação entre usar novas tecnologias e o grau de insucesso dos projetos. Listei os projetos e apontei em quantos deles usei tecnologias novas de mercado, assim como em quantos deles usei tecnologias novas para o time de projetos. Usei como critério de sucesso se o projeto terminou próximo aos prazos e custos previstos e implementou o escopo previsto, ou se um aumento de prazo e custo estava atrelado a um aumento de escopo. Considerei insucesso, por sua vez, casos de aumento de prazo ou custo sem aumento de escopo (estouro de prazo e custos previstos), ou de cancelamento do projeto.

Daí consegui enxergar com clareza que, na minha amostragem, não há uma correlação direta entre o quanto a tecnologia é nova (para o time do projeto ou para o mercado como um todo) e o insucesso do projeto. Pelos critérios que estabeleci, encontrei aproximadamente 28% de projetos de insucesso que fui responsável ou participei - independente dos motivos - e em nenhum deles há uma tecnologia nova de mercado, assim como em apenas um deles há uma tecnologia nova para o time técnico. Olhando, por outro lado, os bem sucedidos, há as mais diversas combinações entre tecnologias novas de mercado e novas para o time de projetos.

Testei, então, um segundo fator que sempre considerei ter uma correlação direta com os projetos de insucesso: o quanto o time de projetos trabalhava bem junto (aqui considerado o "grande time", formado pelo time técnico somado ao time de clientes, usuários e usuários chave), ou seja: havia um bom relacionamento entre as pessoas e confiança entre as partes. Julguei os projetos um a um para classificá-los conforme me lembrava dos times e aqui fiquei surpreso: a correlação é absoluta. Onde o time funcionou bem, o projeto caiu nos meus critérios de bem sucedido. Onde o time não funcionou bem, o projeto caiu nos meus critérios de insucesso.

Essa correlação não deve ser uma surpresa para pessoas acostumadas com projetos de tecnologia, que, certamente, já a perceberam intuitivamente, mas o que me chamou atenção foi que, ao menos nos projetos que já toquei, a correlação é absoluta. Sempre que houve falha em ter um time bem formado, no sentido de que as pessoas trabalhem bem juntas, o projeto terminou com escopo incompleto, prazos e custos estourados, ou cancelado.

Sabemos que as tecnologias novas requerem uma curva de aprendizado e toda uma atenção deve ser dada a essa necessidade, mas a formação da equipe no começo de um projeto me parece ser fundamental para o sucesso no final. Os projetos de TI são, via de regra, bastante complexos e tendem a gerar conflitos pela grande quantidade de pessoas envolvidas, assim como a necessidade constante de decisões. A confiança mútua entre os membros da equipe e o bom relacionamento acabam, a meu ver, mitigando estes problemas potencias.

Um excelente livro sobre o assunto é o Peopleware, do DeMarco, que trata todas as facetas da formação de uma equipe além de analisar a importância que isto tem no final bem sucedido de um projeto de tecnologia da informação.