O Usuário SEMPRE Sabe o que Quer

Não, não é uma pergunta. O título deste post, embora pareça contraditório com o que a maioria das pessoas desenvolvedoras de sistema dizem, quer dizer exatamente o que ele quer dizer. Depois de muito tempo trabalhando com desenvolvimento de sistemas, e um ano trabalhando direto com métodos ágeis (no qual um usuário é livre para fazer mudanças) a frase que mais me perturba é quando alguém diz: “o usuário nunca sabe o que quer”, seguida de perto pelas “o usuário é folgado” ou “o usuário não usa o sistema que desenvolvemos pra ele”.

Primeiro ponto a ser feito, é que ninguém se pergunta “POR QUE o usuário não usa o sistema”, ou “POR QUE ele é folgado”. O que faria uma pessoa usar uma planilha de excel, com todas as dificuldades e inseguranças que ela oferece, ao invés de um sistema? Preguiça de clicar em trocentos botões? O sistema é lento? O sistema é “muito chato”, tipo, milhares de validações, etc? Tudo isso, é o usuário lhe dizendo que o sistema não é do jeito que ele quer – e se o sistema foi desenvolvido PARA ele, por que um programador culpa o usuário, se a falha foi de si mesmo ao ter desenvolvido algo que o usuário não queria?

E quanto à frase “o usuário não sabe o que quer”? Bom, façamos um seguinte compacto: a diferença entre saber o que quer e saber como quer. Quando você faz um levantamento de requisitos, normalmente a pessoa lhe diz: “eu queria uma tela de cadastros, e depois uma tela de consulta…”. Esse é o perigo: um usuário que lhe diz isso não está descrevendo o que ele quer, e sim como ele quer. E o problema, é que o usuário normalmente não sabe “como” ele quer, e por que deveria? afinal, é o trabalho do desenvolvedor de sistemas saber o como, e ao usuário cabe apenas o o que.

Na situação hipotética acima, quando um usuário lhe disser: “então, eu quero uma tela de cadastros de pessoas”, você deve fazer a seguinte dinâmica:
Você: “e por que você quer essa tela?”
Usuário: “para controlar quem entra e quem sai do prédio”
Você: “e como vocês controlam hoje?”
Usuário: “bom, como somente os pacientes do hospital ou os médicos estão autorizados a entrar e sair do prédio, a gente emite um relatório aqui e olhamos se a pessoa que está entrando no prédio está autorizada. Aí, marcamos nesse papel a hora de entrada, e a hora de saída.”
Você: “Uhn… e se eu integrasse com esse sistema de vocês, e vocês só precisassem clicar no nome da pessoa que está entrando ou saindo do prédio, e automaticamente o sistema marcaria o horário de entrada ou saída?”
Usuário (espantado): “Nossa!!! Dá pra fazer isso???”

Nessa conversa acima, tem duas coisas importantes: primeiro, o sistema a ser desenvolvido vai ficar, na verdade, mais SIMPLES, porque uma das telas não terá que ser feita. Segundo, o demandante do sistema ficará mais feliz, porque o sistema será mais integrado. Agora, esse é um exemplo claro de conversa com usuários, e eu garanto que já tive muitas dessas: são poucos os usuários que realmente sabem como querem algo. Mas, até o dia de hoje, eu nunca vi ninguém que não fazia a menor idéia de porque estava me pedindo um sistema, e isto é uma lição que devemos tirar.

E lembrar sempre: esforçar-se ao máximo para criar um software que é uma verdadeira obra de arte, um sistema do qual todos olharão para ele e dirão: nossa, isso sim é um sistema. E lembrar que essa verdadeira obra de arte, na verdade, é uma ferramenta para a pessoa que demandou-o, logo, se o seu sistema não faz o que o usuário pediu, para o usuário usá-lo será como martelar um prego com uma furadeira. Não importa se a furadeira é mais bonita, é melhor, é elétrica, tem quatro velocidades e o que quer que ela faça, é mais fácil martelar o prego com um martelo, por mais primitivo que ele seja.