Muitos desenvolvedores esquecem, mas os sistemas que eles desenvolvem são feitos para atenderem os usuários, por mais que pareça estranho para muitos, quem dá a última palavra para a aprovação de um novo sistema é o usuário.
Isso não quer dizer que o usuário saiba exatamente o que ele quer, mas ele é o cliente que deve ser atendido. De nada adianta um sistema maravilhoso, cheio de funcionalidades e aplicabilidade, se não atende às necessidades do usuário.
Os problemas começam no levantamento dos requisitos. A grande maioria dos analistas de requisitos acredita que os usuários sabem exatamente o que eles querem e, depois de poucas reuniões de levantamento, levam para os arquitetos e desenvolvedores as impressões e as necessidades que eles acreditam que o usuário tenha ou necessite.
O mais comum, deste momento em diante, são algumas deliberações sem muito sentido; se o que o analista de requisitos levantou já não é exatamente o que o usuário imagina que deseja, imagine o que acontece quando os arquitetos e desenvolvedores se apoderam dos requisitos trazidos pelos analistas e resolvem alterar para o que acham melhor funcionalidades e necessidades dos usuários.
O resultado desta história é sempre marcado por uma reunião bombástica que acontece entre o time de desenvolvimento e o usuário; os desenvolvedores querendo mostrar para o usuário que o que foi feito é melhor do que foi solicitado, e o usuário simplesmente não entendendo absolutamente nada do que esta sendo apresentado.
Situações como estas acontecem diariamente nas empresas. E o problema é sempre o mesmo: o pessoal de TI acredita que, por conhecer desenvolvimento e sistemas, sempre dará uma solução melhor do que o usuário necessita e o usuário, por sua vez, com a desculpa de nunca ter tempo para acompanhar as homologações necessárias, sempre se coloca na defensiva criticando tudo o que vê pela frente.
É claro que esta história sempre fica pior para o pessoal de desenvolvimento, afinal quem paga a conta é o usuário e quem tem que ser atendido é ele. Então, está na hora do pessoal de desenvolvimento, em prol da redução de custos e atendimento dos prazos, ser mais rigoroso com as suas metodologias de desenvolvimento, seguindo à risca a necessidade de validação dos usuários para os sistemas que estão sendo criados, mesmo que estes não sejam o sonho do desenvolvedor. Por outro lado, os usuários tem que entender que só é possível entregar no prazo, custo e com as funcionalidades desejadas se eles participarem das homologações de cada fase do desenvolvimento do novo sistema, afinal o pessoal de TI é especializado em tecnologia e não em adivinhação.
Alberto Marcelo Parada, formado em administração de empresas e análise de sistemas, com especializações em gestão de projetos pela FIAP. Já atuou em empresas como IBM, CPM-Braxis, Fidelity, Banespa, entre outras. Atualmente integra o quadro docente nos cursos de MBA da FIAP, além de ser diretor de projetos sustentáveis da Sucesu-SP.
