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.

Advertisements
This entry was posted in Divagações, Metodologias and tagged , , . Bookmark the permalink.

3 Responses to O Usuário SEMPRE Sabe o que Quer

  1. renata says:

    Sem sombra de dúvida o usuário sempre sabe o que quer. O problema real que se tem no desenvolvimento de software por demanda é a diferença de linguagem (e às vezes acho que de planeta também…) utilizado por desenvolvedores e usuários. A dificuldade está em o usuário conseguir deixar claro o que quer e o desenvolvedor ser capaz de entender isso.
    A solução? Quem faz levantamento de requisitos tem que saber o que perguntar ao usuário. Tem que conseguir entender não só o problema que o sistema vai resolver, mas – como mencionado no post – como o problema é contornado hoje e o contexto geral de como, onde, por quê e por quem o sistema será utilizado.

  2. Fernanda says:

    O sistema que o usuário deseja não pode ser mais complicado que o método que ele utiliza atualmente. Tem de ser fácil e intuitivo. O usuário não tem a visão lógica/técnica de sistema que o programador tem, então cada um se expressa e entende de uma forma, por isso tamanhos desentendimentos.
    “Uma vez programador, nunca mais usuário” como dizem, mas acho que a distinção de “o que” e “como” é a chave para um bom entendimento entre os dois. Gostei do artigo.

  3. Rosemary says:

    Gostei muito do artigo. Enfatiza bem a idéia de que devemos auxiliar o usuário a entender qual é o problema que ele tem: “o que” para aí sim, identificar a solução: “como”.

    O que ocorre muitas vezes é que ambas partes, tanto o usuário, quanto o desenvolvedor já vem com a solução pronta, discutem a solução sem antes verificar com mais detalhes qual é o problema que deve ser resolvido, que geralmente pode ser solucionado com algo bem mais simples, como o exemplo exposto pelo artigo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s