terça-feira, 22 de setembro de 2009

Projetos de TI e Estimação



“O problema é que o desenvolvimento de software é um importante esforço, mas não amadureceu como processo de engenharia, ainda é uma forma de arte”.
Craig Mundie
Executivo-chefe de pesquisa e estratégia da Microsoft
http://idgnow.uol.com.br/computacao_corporativa/2007/06/05/idgnoticia.2007-06-05.7937781119/


Normalmente, definem-se indicadores de desempenho sobre pessoas, artefatos (produtos) e atividades, procurando estimar tempo ou gasto financeiro. No caso de projetos de TI, entretanto, surge um agravante: processo, seja ele de desenvolvimento ou de gerência. Dependendo do processo, ocorre uma variação muito grande nos parâmetros pessoas-artefatos-atividades, tornando os indicadores de pouca valia (em parte, daí surgem os 400% de erro do Boehm...) Supondo-se uma maturidade do processo (no sentido CMM, por exemplo) os parâmetros passam a ter um comportamento mais estável (embora o parâmetro pessoa seja fortemente influenciado pelo paradigma de programação, que é outro elemento com marcante influência na definição de indicadores).

Mas aí um novo desafio surge. Os modelos de indicadores tradicionais são definidos acentuadamente em termos das atividades realizadas. Em projetos de TI, no entanto, como medir o andamento de uma atividade de análise? Quanto da análise já foi realizada? Essa pergunta faz sentido? A resposta é: não! Sem acompanhar a realização de uma atividade, como averiguar a performance da pessoa que a realiza? A possibilidade é observar o progresso do artefato... Mas o artefato-alvo de um projeto de TI chama-se: computação. Tal artefato é intangível e móvel (transforma-se com a velocidade das alterações dos requisitos). Assim, como acompanhar o progresso de um alvo intangível e móvel? Nem PMBOK consegue!

Obviamente, muitas pesquisas têm sido realizadas no sentido de se encontrar indicadores para projetos de TI: até agora nada. Apenas para ilustrar, Pontos de Função (IBM, 1979) pressupõem um paradigma de programação centrado em modelagem por decomposição funcional, mas tal paradigma entra em conflito com o paradigma de programação centrado em implementação por objetos, por exemplo, e os indicadores perdem seu sentido de existência. Mesmo com a "reciclagem" da proposta, a instabilidade dos requisitos dificulta o cálculo de indicadores úteis para estimações de projetos de TI.

Outra situação ocorre se houver a tentativa de se empregar algum processo ágil. Já chegamos em "Kanban para software": linha de produção? Ainda não conseguimos responder porque 70% dos projetos de TI fracassam (vide relatórios do Standish, que apenas observam se o projeto foi encerrado dentro do prazo e do orçamento e se os requisitos foram atendidos e controvérsias...)!!!

Resultado: existem muitos modelos de indicadores de desempenho para projetos de TI. Podem e devem ser utilizados para estimação, hoje?

Nenhum comentário:

Postar um comentário