Antes de mais, gostaria de referir que a minha formação é de Engenharia Informática, pelo que as minhas bases iniciais são fundamentalmente técnicas. Faço este preâmbulo, pois alguns dos temas que abordo neste artigo são um pouco controversos para quem tem uma visão apenas técnica de projetos. Ressalvo ainda que aquilo que aqui escrevo se deve também a erros que eu próprio cometi e que procuro atualmente evitar nas minhas funções profissionais e em quem me rodeia. Não é fácil, mas creio ser possível.
Assim, sempre que oiço "faz-se em .NET" ou "faz-se em Java" ou "isso é melhor em PHP!", questiono-me: "já sabem o que é para fazer? Já foram especificados os requisitos ou foram desenhados os processos da aplicação?". Se ainda não foi nada disto feito, como é que uma equipa de projeto já está preocupada com a tecnologia?
Este é um dos típicos problemas de quem com boa vontade e espirito de dedicação quer rapidamente "agarrar-se" ao teclado do computador a programar, esquecendo-se contudo de garantir que o que entendeu, das conversas tidas com o futuro utilizador da aplicação, está efetivamente correto e é aquilo que o utilizador pretende.
É aqui que está um dos problemas típicos do tradicional distanciamento entre as tecnologias e o Negócio, isto é, o processo de levantamento e definição de requisitos que muitas vezes é pouco explicitado e os próprios utilizadores não são, ou não querem, ou são pouco envolvidos neste processo.
Assim, a estrutura tradicional de realizar a definição de requisitos, com base em conversas e sem explicitar efetivamente os diversos entendimentos, tem ser ultrapassada. É preferível "perder" 5 horas ou 5 dias agora, do que perder 5 semanas ou 50 dias a corrigir mais tarde. São fundamentais os processos sistematizados e de estruturação de uma metodologia daquilo que se pretende desenvolver, assim como, que se garanta um entendimento claro de todos os intervenientes. Tarefas como o desenho de fluxos e processos, de apresentação de protótipos de interface gráfico ou de caso de uso e de teste, devem ser a regra e não a exceção. São guiões simples de usar e capazes de criar canais de comunicação entre a equipa de desenvolvimento e a equipa de utilizadores finais eficazes, para além de tornar todo o projeto muito mais eficiente.
Em jeito de conclusão, não interessa diretamente qual é a tecnologia da solução (esta escolha tem muito mais a ver com outros processos globais da organização), pois qualquer uma, hoje em dia, faz o que se pretende certamente. O que interessa numa primeira instancia é garantir que todos os intervenientes do projeto estão cientes do que é para fazer, e para isso a definição clara de requisitos e de canais de comunicação (sem ruídos) são imprescindíveis.
Comentários
No caso de um cliente final, é possível garantir que só avançam para projectos com um trabalho bem feito. Na prática, está tudo nas mãos dessa entidade e se as directivas forem as melhores é meio caminho andado para correr bem.
O problema é que, em termos de consultoras e projectos à medida, como bem sabes, muitas vezes o cliente avalia as propostas apenas com base em preço. E como é óbvio, uma proposta com um trabalho de análise funcional e respectivos acompanhamento e QA representa um maior investimento do que uma proposta que apresente planeamentos mais agressivos que não contemplem estas frases. Conclusão, para clientes que só avaliem o preço uma proposta será mais elevada do que outra. E aí, muitas vezes a decisão está tomada.
Por um lado os clientes querem melhores projectos mas por outro muitas vezes valorizam apenas o investimento e acabam por se colocar nas mãos de empresas e equipas menos capazes. E a conjuntura actual é paradigmática, porque se por um lado a melhor abordagem para um fornecedor de serviços seria negar projectos cujos clientes não estivessem dispostos a trabalhar bem, por outro há que sustentar a empresa.
Ainda assim, a minha opinião continua a ser a mesma, após algumas situações que tiveram fins menos felizes. Se é para avançar para projectos já sabendo que não vai dar melhor resultado, mais vale não avançar.