sexta-feira, 17 de agosto de 2012

Definição dos Requisitos: é no início que se começa

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.