9 de maio de 2010

Caia na real - ensaio sobre o escopo do projeto

Vamos nos colocar no papel de clientes. Estou prestes a fechar um contrato para desenvolvimento de um produto e quero garantir o escopo. Minha obsessão pelo escopo é diretamente proporcional à expectativa da entrega e alcance da meta. Meu nome está em jogo, e caso um usuário lá da Índia sentir falta de alguma funcionalidade, levarei a culpa.

Do outro lado, eu como fornecedor não questiono o tamanho do escopo, pois este se transforma em horas, que posteriormente materializa-se em dinheiro. O que não consigo ver, como fornecedor, é o quanto de esforço da minha equipe é desperdiçado com questões menores.

Analisando rapidamente o gráfico abaixo é possível notar que quase a metade do que está no escopo nunca, isso mesmo, nunca será utilizado. Na outra ponta temos somente 14% do que foi implementado é vital para os objetivos do sistema.

Média de uso de funcionalidades de sistemas
Fonte: Standish Group (2002)

Temos que acordar! Desconstruir esse paradigma do relacionamento cliente/fornecedor. Duas questões que estão bastante na moda e que realmente tem grande importância em qualquer projeto inteligente são o ROI (return on investment) e o alinhamento estratégico.

Todos os requisitos para a construção de um produto devem trazer algum retorno do investimento, ou seja, cada hora de desenvolvimento do projeto é custo para o cliente, correto? Alinhado com o momento de crise, por que adicionar escopo que não trará retorno considerável? Para que aumentar o escopo com a justificativa de se resguardar? Vale a pena aumentar o valor final do projeto?

E se eu, como cliente, garantisse que o escopo está alinhado com o planejamento estratégico da empresa? Esse não seria um grande argumento para engavetar projetos que não foram previstos no planejamento? O aumento do escopo de um projeto está casado com o plano da instituição? Se sim, ótimo. Mas na maioria dos casos não está.

Nesse momento devemos considerar os resultados dos projetos. Segundo o Standish Group somente 32% dos projetos são entregues com sucesso. O percentual de fracasso de projetos chega a 24%, enquanto 44% dos projetos são desafiados, ou seja, tem custo, tempo ou escopo fora do planejado.

Qual a explicação para os números apontados no gráfico acima? Absurdos 64% das funcionalidades de um sistema são raramente ou nunca utilizadas. Tem algo muito errado. Concorda?

A mudança deve partir dos dois lados. O cliente deve solicitar apenas o que interessa, enquanto o fornecedor deve cumprir a tripla restrição. Sonho? Talvez não.

O objetivo desse post não é apresentar uma solução ideal, mas trazer uma visão otimista para esse cenário.

A redução do escopo ao nível do essencial traria um benefício ao cliente, onde ele teria o produto em mãos com tempo e custo reduzidos.

O fornecedor teria um giro maior entre os projetos. Projetos com anos de duração seriam exclusividade da Petrobrás. O dinheiro entra enquanto o portfólio cresce e a empresa alcança mais presença e notoriedade.

Ideias revolucionárias como as do pessoal da 37signals devem ser disseminadas, adaptadas e recriadas. Os autores do livro Rework e do que podemos chamar de manifesto ousado para desenvolvimento de sistemas - Caindo na Real, assumem que fazem menos que os concorrentes e incorporam literalmente a ideia do "menos é mais".

Estude o novo. Abra a cabeça. Troque hipoteticamente de papel (cliente/fornecedor) com frequência. Caia na real.

Referências:
FRIED, J. HANSSON, H. Rework - Change the way you work forever. Vermilion, 2010.
37signals. Caindo na real. Disponível na Internet em http://gettingreal.37signals.com/GR_por.php. Acessado em 2010.

Nenhum comentário:

Postar um comentário