Durante minha pós-graduação, quando iniciava minha carreira no mercado de software, tive a oportunidade de ter aula de gerência de projetos, com um professor renomado e famoso. Neste curso tive meu primeiro contato com as metodologias de gerência de projetos de software. Fui apresentado ao modelo waterfall iterativo. Basicamente é um waterfall clássico, que permite iterações a partir da fase de desenvolvimento. A fase de análise continua lá, intacta.

O discurso era bem azeitado, fazia todo sentido e bem simples. Tirando o blá, blá, blá, a lógica é mais ou menos a seguinte:  

Problema:
n% dos projetos de software atrasam, estouram orçamento e/ou não atendem as necessidades dos clientes. (Sendo n variando entre 20% e 40%, dependendo da dramaticidade do palestrante)

Premissas:
A maior parte dos problemas acontece devido a mudanças realizadas ao longo do projeto ou a falta de entendimento das necessidades dos clientes.

O custo de uma alteração cresce exponencialmente a cada fase do projeto. Ou seja, é muito mais custoso consertar o software após sua construção do que nas fases de análise e projeto.

Solução:
Por tudo isto, uma etapa inicial e extensiva de análise e especificação de requisitos é fundamental para o sucesso do projeto. Fases subseqüentes, de design, codificação e testes, não podem começar sem que todos os requisitos funcionais e não funcionais do projeto tenham sido completamente documentados.

O discurso faz sentido, não faz? Para mim fez, ainda mais que os outros professores corroboravam, colegas e gerentes também assinavam embaixo. Não é à toa que eu passei a praticar e defender estas práticas. Sinceramente não me arrependo, a pressão dos clientes, associada com prazos definidos top-down, praticamente nos obrigavam a começar a desenvolver sem ter muita idéia do que os usuários queriam.

Desde então participei de muitos projetos, longos, curtos, complexos, fáceis, com diversas tecnologias. Infelizmente devo admitir que a minha estatística foi ainda pior do que pregavam, acho que pelos menos 60% dos projetos que participei tiveram algum dos problemas citados. Já vivi quase tudo, projetos que tiveram uma longa fase de análise, que ainda assim atrasaram no final, projetos que não tiveram a devida análise e também atrasam ou fracassaram. Agora o pior de tudo foram os projetos que sofreram de Analysis paralysis. Eu participei de um projeto que morreu ainda na fase de análise, sem uma linha de código-fonte escrita, bem triste.

Mas aquele discurso que eu “comprei” já vinha sendo defendido há bastante tempo, há mais de dez anos. No entanto o meu histórico, assim como os de outros profissionais, continua a mostrar os mesmos problemas. Talvez o remédio não seja tão eficiente quanto se prega. Vamos revê-lo, depois de alguns anos de experiência.

O problema continua valendo:
n% dos projetos de software atrasam, estouram orçamento e/ou não atendem as necessidades dos clientes.

As premissas, também:
A maior dos problemas acontece devido a mudanças realizadas ao longo do projeto ou a falta de entendimento das necessidades dos clientes.

O custo de uma alteração cresce exponencialmente a cada fase do projeto.

Agora a solução proposta é que não é muito consistente. Quero dizer, para que ela fosse válida seriam necessárias outras premissas, que foram subentendidas ou ignoradas. Algumas perguntas podem nos ajudar:

Por que são necessárias alterações ao longo do projeto?

No mundo moderno as necessidades são voláteis. Em alguns setores, mais dinâmicos, um projeto que dure mais de seis meses pode ter mais de um gestor ao longo de sua vida.

Às vezes, os usuários e clientes não sabem exatamente o que querem. Existe uma necessidade básica: automatizar uma atividade ou processo, mas nem sempre o processo manual pode ser facilmente traduzido em software. Isto quando existe um processo manual bem definido.

Ainda existem as diversas situações nas quais nós realmente não entendemos a necessidade dos nossos clientes, daí chegamos à segunda pergunta.

Por que não conseguimos entender completamente as necessidades dos nossos clientes?

Em uma excelente entrevista, David S Platt, autor de Why software sucks, apresenta vários motivos de porque softwares não atendem os usuários.

Um deles é que softwares são desenvolvidos por Geeks, e nós simplesmente não conseguimos nos colocar na pele de um usuário comum.

Outro motivo é muitas vezes tentamos adaptar o comportamento do usuário ao comportamento da máquina e não vice-versa.

Podemos também pensar que em alguns casos nossos clientes são péssimos comunicadores e não conseguem apresentar claramente suas idéias.

Enfim, podemos passar o dia aqui lembrando motivos pelos quais requisitos mudam ao longo do projeto. A questão é, existem vários motivos pelos quais um projeto de software pode sair dos trilhos e em muitos casos a solução proposta lá em cima não só não resolve como ainda agrava o problema.

Como posso dizer isto? Pense bem, por algum motivo nós não conseguimos entender corretamente a necessidade do cliente. Não por falta de tempo, mas por outros motivos que mencionamos. Portanto a fase de análise ocorreu, nós achamos que sabemos tudo e partimos para as fases subseqüentes.

Ai começa o problema porque o modelo não prevê uma forma simples de ajustar estes requisitos. É bem possível que estas diferenças, entre o desejado e entendido, só sejam descobertas na fase de homologação, justamente quando o custo de uma mudança é mais caro. Mesmo que isto ocorra antes será um problema, porque o processo todo é “anti-mudança”, elas são tratadas como exceção. Existe todo um processo para analisar estas mudanças e seus impactos no projeto. Na maioria das vezes somente esta análise já atrasa o projeto.

Por maior que seja minha vontade, não quero apresentar aqui as metodologias ágeis como a maravilhosa solução para o problema apresentado. Vou me limitar em apresentar o problema e deixar claro que em muitos casos, por maior e melhor que seja a fase de análise de um projeto, não resolvemos o problema fundamental que buscamos resolver.