Na maioria dos whitepapers criados para vender uma idéia, serviço ou produto de TI, não faltam estatísticas indicando que uma proporção espantosa de projetos termina em fracasso. Dados de pesquisas patrocinadas pelo Gartner, Carnegie Mellon, Meta Group e Standish Group International, entre outros, sustentam que de 25% a 40% dos gastos com projetos de TI são desperdiçados em função de retrabalho, e que quase dois terços desses projetos são abortados ou alcançam resultados pífios.
Diante de indicadores tão negativos, o que se pode fazer para aumentar as chances de sucesso? Os whitepapers que alertam para o problema também oferecem a promessa de melhores resultados com a implantação de novas práticas e tecnologias. No entanto, as estatísticas continuam ruins, ano após ano, mesmo entre os clientes dessas soluções tão promissoras.
A explicação, na minha opinião (baseada principalmente na observação direta do planejamento e execução de dezenas de projetos de TI de grande, médio e pequeno porte nos últimos anos), é simples, embora de difícil solução: a ausência de uma participação mais constante e ativa das pessoas diretamente impactadas pelo projeto durante todo o seu ciclo de vida.
Compare com a situação na empresa em que trabalha (ou para a qual presta consultoria), e veja se a sua experiência é diferente: em quase a totalidade dos projetos de desenvolvimento de software dos quais participo, o nível de envolvimento dos patrocinadores e usuários finais do produto é mínima, ou pelo menos bastante irregular ao longo do ciclo de vida do projeto
Raramente esses grupos – que não só correspondem às partes mais interessadas no resultado final do projeto, mas também representam as referências mais importantes para a definição do rumo certo – se mantêm envolvidos de forma constante e efetiva do começo ao fim do projeto. Em muitos casos, o nível de envolvimento é alto na fase de planejamento, cai para quase inexistente nas etapas seguintes, e retorna apenas na fase final de UAT (teste de aceitação pelo usuário), quando é tarde demais para se efetuar qualquer mudança significativa no produto sem prejuízos sérios para a qualidade, o prazo ou o custo do projeto.
Projetos de software, mesmo os aparentemente simples, são, por natureza, complexos e sujeitos a idas e vindas causadas por fatos inesperados, como a descoberta da indisponibilidade de um tipo de dado vital para um relatório a ser produzido pelo aplicativo, ou a constatação de que um aspecto crucial do problema a ser resolvido pelo sistema não foi levado em conta pelos desenvolvedores. Sem a presença atuante dos principais interessados no resultado final, é muito provável que a dificuldade seja varrida para baixo do tapete por um gerente de projeto ou fornecedor mais preocupado com a entrega do produto no prazo do que com o grau de adequação do software às reais necessidades do negócio, alimentando assim as estatísticas de projetos fracassados.
É possível minimizar o impacto da ausência desses personagens-chave no sucesso dos projetos? Obviamente que sim, ou apenas os raros projetos em que os patrocinadores e usuários finais permanecem disponíveis para prestar esclarecimentos e tomar decisões a cada obstáculo encontrado alcançariam bons resultados. Para superar o problema é preciso primeiro reconhecer que ele existe, e em seguida procurar soluções criativas que assegurem o máximo envolvimento, em momentos decisivos, das pessoas que vão usar o produto ou beneficiar-se de sua existência.
