Você está preparado para dizer o que estas precisando?
Tudo começou com uma vaga de emprego para Balneário Camboriú….O Jean até achou que a vaga estava bombando, mais apenas era uma discussão sobre CRUD, e o além do CRUD.
A discussão completa esta em http://groups.google.com/group/flexdev/browse_thread/thread/49d0debcb366b97b
Bom deixei alguns comentários e tiveram outros excelentes que deram a esta postagem uma das melhores do FlexDev. Mais noto que muitos seguem a regra ao lado.
Bom, visitei uma empresa que ajudo no desenvolvimento, e questionaram que o usuário não sabe o que quer, e hoje me mandaram pelo GTalk o Link do Vedovelli, http://rialabs.com.br/blog/?p=12, sobre o mesmo assunto.
Sou obrigado a discordar dos dois. O usuário precisa apenas dar o seu problema, e nós analistas, temos que dar a solução para ele. Eu posso dizer que sou especialista em programação e transformar um problema em software. Agora quando fui registrar minha empresa me senti o USB¨ máximo. Não sou especialista em empresa, nunca tive uma e não sabia nada sobre imposto, mais lá o Edson Nack me atendeu e através do meu problema me deu uma solução.
Então, temos que ser igual ao Edson Nack. Receber um problema de um usuário e lhe dar a melhor solução. Isso enfoca que o usuário nunca sabe o que quer, ele apenas tem o problema.
Então, se for corrigir o que o Vedovelli escreveu, devo escrever:
Você está preparado para dizer o que estas precisando?
E a nós programadores pergunto:
Estou preparado para resolver o problema?
As pessoas precisam de sistema para resolver seus problemas e não para enfeite de natal. Lembre-se enfeite de natal custa R$1,99 e o seu sistema custa R$19.000,00. Sabes por que a diferença? O Enfeite de natal não soluciona problemas do usuário. Pense nisso, e verás clientes mais felizes.
¨ USB == Usuário Super Burro
A Parábola da escova de dente
Leiam antes de prosseguir, http://blog.aspercom.com.br/2008/07/21/hierarquias-sao-inteligentes-nas-pontas/
Vejam que esta história é muito indicada para este artigo. O problema foi apresentado mais a solução apresentada atrapalhou o desempenho da fabrica. Lembrem-se que nós analistas e desenvolvedores temos que chegar ao resultado obtido pelo ventilador. Esta é a regra geral faz a seleção natural dos profissionais. Então se pergunte todo dia, aonde posso colocar um ventilador?
Ir até o problema e analisa-lo, discutir com as pessoas envolvidas no problema e perguntar qual será a solução deste problema.
A Parábola do Velho Lenhador
Leiam antes de prosseguir, http://www.algosobre.com.br/carreira/a-parabola-do-velho-lenhador.html
Nós temos que ser igual ao velho lenhador, para pensar qual será a melhor maneira de fazer uma ação.
Sou muito adepto de reuniões diárias. Parece ser muito, mais em equipes com mais de dois programadores, esta é uma maneira que aumenta em muito o desempenho da programação. Estas paradas devem ser feitas 10 a 20 minutos antes de ir almoçar. Se os programadores trabalharem na mesma sala, apenas virem as cadeiras e façam logof dos computadores e tentem conversar sobre as regras que estão criando. A união da equipe aumenta em muito e os problemas passam a diminuir já que as soluções vem de vários lados.
Esta também é a melhor maneira de unificar o conhecimento da equipe, já que várias idéias novas sempre nascem nestas reuniões e soluções novas de problemas são discutidos por todos da equipe.
Você pode seguir todas as respostas a esta entrada através do RSS 2.0 feed. Você pode deixar um comentário, ou colocar um link em seu site.
Parebens Eduardo pelo post, ajudou em muito a ampliação da visão de um programador iniciante.
Abraços
Esse assunto é que nem religião e política: melhor deixa prá lá
muito bom o post o/
Eduardo, o negócio não é que o cliente não sabe o que quer. É que geralmente ele não tem um processo estabelecido na empresa ou não é bem definido. E geralmente quer que nós demos um jeito na “bagunça dele”.
E ai fica um pouco difícil porque se nem ele (incluindo funcionários) entende bem o processo, como vamos resolver o problema dele?
Solucionar um problema bem definido usando tecnologia é outra coisa.
[]’s
@Gustavo Ai que esta o detalhe que escrevi. Se ele não tem bem definido, cobre pela definição. Ele sempre estará disposto a pagar.
PS: normalmente um sistema serve muito mais para arrumar “bagunça dele” do que resolver um problema bem definido. Se ele tiver um problema bem definido, ele terá achado uma solução simples para ajeitar a bagunça. Planilhas do Excel, ou os vários softwares Free ou pago na Web.
“Não ouça 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 ele quer vai deixá-lo com a falsa impressão que o projeto foi um sucesso. Mas depois de um tempo ele vai ver que não é bem assim. Depois de um tempo o que ele querer vai mudar para o que ele precisava mas não sabia.
O problema de desenvolver com foco no que ele quer é que isso é baseado em desejo e como tal é rotineiramente distorcido pelas impressões. Desenvolver baseado no que o usuário quer o leva a assumir premissas e criar restrições erradas para o desenvolvimento do software. Isso vai complicar o seu desenvolvimento e provavelmente vai levar a resultados pouco satisfatórios. O problema é que o usuário vai culpar você por isso e não pelas informações imprecisas sobre o que ele lhe passou sobre o que ele queria.
Mas quando você consegue fazer O QUE ELE PRECISA pode até ser que exista algum atrito no inicio – porque ele não tem certeza que precisa daquilo. Mas conforme o tempo passa ele vai entender melhor porque as coisas estão tomando o rumo que estão tomando – ele aprende junto com você o real problema. Então ele 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. [...]