"NÃO DEIXAM FAZER" Esta parte nunca tive problemas. Tenho muito bem esquematizado a história a contar para que o chefe deixe eu conversar com quem realmente precisará do sistema.
O sistema no final ajuda a criar um clima melhor dentro da empresa, e chefe adora mais ainda e não reclama quando paga. O Segredo: fazer com que o usuários seja on rei do sistema. Dizer para ele que eu farei o que eles precisara e ajuda-lo a chegar em uma conclusão. O Funcionário fica muito feliz! Vá almoçar com os funcionários e tome uma cerveja no final do dia. Normalmente eles não deixam eu pagar a minha parte(Não insisto muito). é divertido. “Antes de mais nada, acho que querer ser milionário não é um bom objetivo na vida. Meu único conselho é: ache aquilo que você realmente ama fazer. Exerça atividade pela qual você tem paixão. É dessa forma que temos as melhores chances de sucesso. Se você faz algo de que não gosta, dificilmente será bom. Não há sentido em ter uma profissão somente pelo dinheiro.” Veja n°25 2002 *Eduardo Kraus* Desenvolvedor eduardokr...@gmail.com http://blog.mxml.com.br http://twitter.com/EduardoKraus 2009/7/31 Gabriela Trindade Perry <gabrielape...@hotmail.com> > > É... eu sou obrigada a usar o People Soft. É um dos piores que > conheço. Nem quero saber se é da Oracle, do Wal-Mart ou da Nestle... É > uma droga. > Agora, tudo isso que a gente está discutindo é muito bonito e tals... > Mas quais os custos de implementar tudo isso? > Vejam resumidamente os passos para implementar usabilidade num > software como o People: > > 1. Análise de tarefa - um mês de observação e entrevistas, para saber > como o trabalho é feito. Isso se a gerência topar, porque normalmente > eles NÃO DEIXAM FAZER! Porque quando tu fala que vai entrevsitar e > observar eles ficam com medo que os funcionários vão falar mal da > empresa... É soda... mas a gente acaba fazendo de um jeito ou de > outro. Já tive que fazer com o gerente me dizendo como era o > trabalho... > Sabe qual a consequencia de nao fazer isso? Quando o sistema entra em > produção (em uso), o povo descobre que alguma feature não está bem > ajustada. Eu gostaria de poder mandar o gerente pastar quando isso > acontece. > 2. User stories - cenários de uso, como quer que chamem. Duas ou três > linhas sobre as principais funcionalidades do sistema. Sem aprofundar. > É horizontal, não vertical. Bem tosco. Levo dois dias. > 3. Layout das telas no papel. Meio por cima, para ter uma idéia das > funcionalidades principais. Leva cerca de uma semana. > > As etapas 2 e 3 não podem tomar todo o tempo. Precisa ter tempo pra > pensar, pra arejar a cabeça. Eu, pelo menos, não consigo ficar 2 horas > desenhando ou pensando nas funcionalidades de um sistema... > > 4. Layout das telas. De TODAS as telas. Isso eu faço, com muito > orgulho. Passo duas a três semanas no fireworks, desenhando telinha. > Vejam que meus sitemas são smepre pequenos/médios. Nunca fiz nada como > o PeopleSoft. E vou dizer pra vocês, é muito chato fazer isso. Mas > durante esse processo, normalmente noto inconsistências no que > planejei. É aqui que economizo horas de programação - e muitas. Se não > der pra fazer a primeira etapa, que é super importante, precisa fazer > isso. Mas não estou falando de wireframe. Isso eu fiz na etapa 3. É > layout mesmo. Sem skin. Isso fica para mais tarde, por ultimo. > > 5. Durante esse processo, sempre tem telas em que fico em dúvida de > como deve ser o funcionamento. Nesse caso, eu especifico que vao para > teste, que é a próxima etapa. > > 6. Testes toscos de usabilidade. Sabem como eu faço? Com imãs de > geladeira. Imprimo os controles e as telas que desenhei, recorto e > colo nos inãs e dou para umas pessoas (super criteriosa, haha) > testarem. Quando é pesquisa acadêmica, a gente reserva uns trocos (R > $10,00) por sessão. Leva meia hora cada teste. > > 7. Daqui pra frente é com o pessoal da implementação. Eu marco em > cima, e muitas vezes meto a mão na massa. Foi assim que aprendi a > programar. > > Agora pergunta quantas vezes eu consegui fazer isso, 100%? NUNCA!!!! > Falta tempo, falta grana, falta colaboração. E também, mea culpa, > faltou saber gerenciar isso tudo. Já aconteceu de eu querer implantar > esse ciclo e levar bonito. Não é fácil. Isso que o Bekc falou de User- > centered é bonito no papel... Fazer isso é bucha. Gerenciar > participação do usuário não é mole. A gente tem que ficar negociando > com eles, com o cliente, com os chefes... E acontece que passam dois > meses e o negócio não avançava. Mas eu continuo tentando, hehe. Um dia > eu consigo :0P > > Minha intençao então foi que, quem estiver afins de se aventurar > nessas de Usabilidade, que faça isso com cuidado e com calma. Hoje, eu > acho que seria legal se eu tivesse planejado fazer só algumas dessas > etapas por projeto, para dominar o processo de cada uma delas. Depois > que a equipe tiver entendido como faz e os benefícios de cada uma, daí > parte pra adicionar outra. Eu, como já falei, tomei um laço quando fui > me meter a fazer tudo num projeto só. Foi num projeto de game, e a > coordenadora do projeto não pdoe nem ouvir falar no meu nome :0( > Então fica a lição: falar é uma coisa... fazer são outros quinhentos. > Mas tem valido a pena :0) > > > --~--~---------~--~----~------------~-------~--~----~ Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com Para sair da lista, envie um email em branco para flexdev-unsubscr...@googlegroups.com Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
