Não faça o que os usuários querem! Faça o que eles precisam!
“Não ouça os compradores, eles não sabem o que querem” – Steve Jobs.
Algo parecido acontece com os usuários em minha opinião.
“Saber o que quer” é diferente de “saber o que precisa”. O usuário sabe o que quer, mas você NÃO DEVE fazer o que ele quer, você deve fazer o que ele precisa!
O que usuário quer num primeiro momento vai deixá-lo com a falsa impressão que o projeto está indo bem. Mas depois de um tempo ele verá que não é bem assim. Depois de um tempo ele vai querer mudar para o que ele precisava mas não sabia.
O problema de desenvolver com foco no que o usuário quer é que isso é baseado em desejo e como tal é rotineiramente distorcido pelas impressões. Desenvolver baseado no desejo dos usuários o leva a assumir premissas e criar restrições erradas para o desenvolvimento do Software. Isso complicará o seu projeto e provavelmente levará a resultados pouco satisfatórios. O problema é que o usuário vai culpar você por isso e nem vai lembrar das informações imprecisas que ele lhe passou sobre o que ele desejava.
Sim, o usuário não vai lhe dizer o que ele precisa porque ele não sabe! Pior, por sua natureza, entender o que o usuário realmente precisa é mais “arte” do que ciência. Você precisa saber lidar com pessoas. Você precisa saber que o usuário é um ser humano como outro qualquer e que está muito confuso sobre o seu problema. O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens. E ele faz isso porque o nosso cérebro funciona assim: por associações. É por isso que vira e mexe ele olha outro software que não tem nada a ver com o seu problema e diz: eu preciso disso! Então você começa a desenvolver e aprende a duras penas que não era nada daquilo… e você muda um pouco aqui, muda um pouco ali e quando vê já está com um Software Frankenstein nas mãos.
O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens.
É neste ponto que você deve deve ter a “astúcia” de abstrair os desejos do usuário, considerar as informações relevantes sobre o que ele está lhe falando e propor soluções que, pelo seu conhecimento, devem agregar mais valor do que aquilo que o usuário pensava antes. E você terá que saber argumentar com ele sobre esta “nova” solução. Porém, compre mesmo esta briga! Não desista tão facilmente de convencê-lo a “fazer do seu jeito”. Demonstre confiança no que você esta falando. Baseie-se em estudos, fatos, exemplos. Conquiste a confiança dele antes de qualquer coisa. Não existe receita de bolo para isso e eu acredito que é por isso que estes templates de Casos de Uso ou qualquer outra coisa do tipo falham. Não me refiro ao artefato em si, mas o modo como ele é concebido: geralmente um processo burocrático, formal, nada humano e extremamente chato!
Finalmente, quando você consegue fazer O QUE O USUÁRIO PRECISA pode até ser que exista algum atrito no inicio – porque ele ainda não tem certeza que precisa daquilo. Mas conforme o tempo passa ele entenderá melhor porque as coisas estão tomando o rumo que estão tomando – ele aprende junto com você o real problema. E eis que o usuário passa a querer o que ele precisa e é aí que está a chave do sucesso.
Nota: Este post é uma “extensão” do comentário que fiz neste outro post.
Grande post Beck.
É bem assim mesmo que funciona a coisa.
Abraços,
Silva Developer
Isso traz muitos bons resultados mas eu considero impossível de ser feito. Por mais que vc se dedique, argumente, procure embasar suas afirmações, o fator humano sempre estará lá. No Brasil, o fator humano vem acompanhado por algo muito indigesto: o orgulho. ‘Estou pagando, vc faz do jeito que eu mando’. Esse tipo de atitude nunca vem explicita, mas ela tá lá. Se for em empresa grande então, melhor desistir.
É: às vezes me dá vontade de virar pipoqueiro.
Grande post, Beck!
@ Ved
Sobre este negócio do “orgulho” eu tenho uma historinha interessante também. Diz a lenda que um escultor famoso fez uma estátua a pedido de um Rei. Ao ver a estátua o Rei disse: “Adorei! Só não gostei muito do nariz.” O escultor então voltou para casa, deixou a estátua no armário durante 3 semanas e depois disso mostrou para o Rei novamente sem nenhuma alteração. O Rei olhou e disse: “Agora sim está perfeito!”.
Parece uma coisa psicológica mesmo. O cliente está pagando e ele acha que sabe do que está falando. Então ele tem que colocar a cereja no bolo. Mas sabe o que eu tento fazer quando ele me pede umas coisas que eu acho que mais atrapalham do que agregam valor? Eu chego com uma nova funcionalidade tão boa, mas tão boa que ele não vai nem lembrar “do nariz da estátua”. Eu tiro a atenção dele para aquela coisa que ele pensava que era importante pois eu sei que de fato não era! Não é fácil! Você precisa talvez do dobro de dedicação para fazer coisas que realmente vão “quebrar este preconceito”. E claro, nem sempre funciona! Mas quando dá certo é muito mais gratificante.
Beck, vc é o rei da paciencia, cara! Isso é uma falha minha que preciso corrigir! hehehe
[...] Não faça o que os usuários querem! Faça o que eles precisam! | BeckLog: Beck Novaes’ Web Log (tags: designinteracao) [...]
“Estou pagando, vc faz do jeito que eu mando.” é frase filho da mãe para o desenvolvedor. Assim como o Ved, muitas vezes estresso com o cliente. Afinal, usuário/cliente é ‘bixo do cão’, como diria um amigo.
Mas o que falastes sobre apresentar uma nova funcionalidade é fato. Quando você falou isso veio um flashback de como isso é verdade e acontece muito durante todo o processo de desenvolvimento.
A partir de agora tentarei utilizar de forma mais consciente esse método. ;P
Belo post, cara!
Grande Beck,
Belo post! É isso mesmo, concordo com você. Essa frase “estou pagando, vc faz do jeito que eu mando” me dá calafrios hehehe. Só me falta colocar isso em prática
Um abraço
Legal este post.
So queria falar de uma historinha que de um antigo amigo meu sempre contava tipo a que o beck novaes conta no 3. E essa é verdadeira heh.
Esse amigo meu tomava conta da mesa de som da igreja e tinha um violonista que sempre queria ajustar a saida do violao dele. Ai o violonista gritava:
- Aumenta o som um poquinho…
Esse amigo meu fingia q aumentava e dizia:
- Ta blz?!
o violonista respondia
- Nao, abaixa so um pouquinho…
depois de fingir q abaixou o som perguntava:
- E agora?
E o violonista
- Ta perfeito!!
Sempre dou risada quando lembro dessa historia
Abraços…
Esses últimos anos eu tenho trabalhado como analista de negócios de TI e aplico essas técnicas nas três pontas: usuários, programadores e gerentes. Cada um quer o sistema do jeito que é melhor para ele, mas no final quem tem a responsabilidade de manter o sistema funcionando é o analista.
1) O usuário quer um sistema fácil de usar ao ponto dele não ter que pensar no que o sistema faz;
2) O programador quer ou aplicar todo e qualquer conhecimento ‘novo’ que adquiriu (normalmente os novatos); ou usar apenas o que sabe, ficando resistente a qualquer solução que lhe pareça muito ousada (normalmente os mais experientes);
3) O gerente quer tudo o quanto antes e o quanto menos, sem se importar com o como nem o porquê (caixa-preta).
É o analista quem deve dosar esses ânimos e conduzir o sistema do qual ele é responsável de acordo com as boas práticas e condutas:
1) Ficando atento aos requisitos e fazendo os usuários tomarem consciência do que ele precisa e do que o sistema pode fazer por ele;
2) Avaliar a qualidade e adequação das soluções propostas pelos programadores, afinal o sistema é o código-fonte;
3) Tornar tangível para os gerentes o esforço necessário para a criação de software: entendimento do problema (análise), escolha da solução (design), codificação e teste. E alertá-los dos riscos de segurança e estabilidade de um código obscuro.
Abraços
Grande Beck,
Devemos agir dessa forma, porém, se o cliente ameãça deixar vc a ver navios e procurar outra desenvolvedor, a coisa complica. Mas com jeito dá para convencê-los.
Parabéns pelo post!