Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
"Boas" Lições Sobre Como Fracassar um Projeto RIA
Postado por Abel Avram , traduzido por Fernanda Stringassi de Oliveira em 11 Ago 2009
Em uma apresentação chamada Dez maneiras de garantir o fracasso de um projeto RIA, Anthony Franco, presidente da EffectiveUI, dá 10 conselhos para aqueles que querem que seus projetos RIA fracassem. Gerd Waloszek, SAP AG, escreveu "18 Regras de Ouro para Interfaces de Usuário Ruins".
Estes são os 10 anti-conselhos dados pelo Franco explicando porquê eles devem ser evitados e o que deve ser feito como alternativa:
- Se Você Quer Fracassar, Não Entenda o Usuário Final – 70% de todos projetos de TI fracassam por causa do aceite do usuário.
- Se Você Quer Fracassar, Confie nos Desenvolvedores para Fazer Boas Decisões de Design. Desenvolvedores são encorajados a fazer designs ruins ao acompanharem o progresso do trabalho usando o número de funcionalidades finalizadas. Quando um projeto está para perder a data final, os desenvolvedores focam em remover funcionalidades ao invés de pensar no usuário final.
- Se Você Quer Fracassar, Espere por um Design "Bala de Prata". Boas idéias são bem-vindas, mas uma ótima idéia de funcionalidade não deve substituir um bom e saudável Design de Interface de Usuário.
- Se Você Quer Fracassar, Construa por Todos. "Se uma empresa tenta construir um produto para todos, ele acabará sendo construído para ninguém".
- Se Você Quer Fracassar, Entregue & Esqueça. Depois de entregar, o produto precisa de mais iterações para ser refinado e completado.
- Se Você Quer Fracassar, Não defina sucesso. Não definir sucesso significa não saber para onde está se dirigindo.
- Se Você Quer Fracassar, Evite Conflitos. Conflito não é necessariamente ruim, porque "não há progresso sem conflito". A bandeira vermelha deve ser levantada quando cada um da sala concordar com a idéia.
- Se Você Quer Fracassar, Acredite que você não deve vender suas idéias Os envolvidos devem estar procurando vender a idéia dentro da organização, e não esperar que será aceita simplesmente por vir deles. Isto envolve estar preparado para responder questões como: o que é Retorno sobre Investimento, o que é sucesso para isto, porque agora, o que acontecerá se não fizermos isto?
- Se Você Quer Fracassar, Planeje para a Perfeição. Alguém não deve planejar tudo no começo e esperar que aconteça como planejado porque há chances de não acontecer.
- Se Você Quer Fracassar, Valorize o Processo sobre o Produto. Este conselho pode ser refraseado: "Se Você Quer Fracassar, Não se Arrisque." Nós podemos altamente valorizar o processo de desenvolvimento que estamos usando, mas "não significa entregar um produto ruim no tempo", e é mais fácil construir o produto desejado com uma abordagem iterativa.
A seguir estão as 18 regras de ouro do Waloszek juntamente com alguns exemplos negativo se que não devem ser seguidos:
- Mantenha os Usuários Ocupados Fazendo Trabalho Desnecessário - Deixar os usuários preencherem os campos com dados para somente depois dizer que eles não podem preencher dados ali (por exemplo, uma aplicação deixa você digitar dados em feriados ou finais de semana e dizer depois que você não pode trabalhar nestes dias).
- NÃO OBEDECER Padrões - Não colocar itens de menu nas categorias e locais aos quais eles tipicamente pertencem (por exemplo, colocar "Salvar" no menu "Editar").
- Faça ele ser lento - Há quase ilimitadas possibilidades de fazer software lento. Por exemplo, você pode incluir longas e duradouras validações ou idas e voltas depois de cada entrada de dados pelo usuário. Ou você pode forçar o usuário a passar por longas cadeias de caixas de diálogo.
- Use Abreviações Onde Possível, Particularmente Onde Existiria Espaço Suficiente Para o Termo Completo - Usar "dt." ao invés "data", "TolCh" ao invés de "Tolerância Chave", "ProxOb" ao invés de "Próximo Objeto", e muito mais...
- Eduque os Usuários na Linguagem Técnica - Sempre envie URLs como UTF-8 (requer reiniciar) (configurações avançadas do MS Internet Explorer)
- Esconda Opções Importantes e Frequentes - Funcionalidade usada nas visões de usuário - Esconder funções importantes em menus onde os usuário nunca esperariam por elas.
- Faça Sua Aplicação Funcionar Somente com Uso de Mouse – Não Oferecer Nenhuma Tecla de Atalho
- Faça o Uso da Sua Aplicação um Desafio Real - Não alerte os usuários se as ações podem ter consequências severas.
- Fique longe dos Usuários finais - Muitos usuários finais têm muitas opiniões, você tem uma. É de longe mais fácil e rápido de implementar.
- Difunda a Mensagem Dos Exemplos Ruins e Vivencie-a - Somente seguir as regras de ouro desta página, já é um ótimo começo.
- Tome Muito Cuidado em Definir valores padrão ruins: Contrários à Expectativa do usuário, Desastrosos, Irritantes, Inúteis – Está com você - definir valores padrão em formulários Web e então os usuários recebem mensagens de anúncios e ofertas não desejadas, têm seus e-mails distribuídos, etc.
- Destrua o Contexto de Trabalho depois de Cada Reação do Sistema - Desmarque elementos selecionados da tela depois de uma reação do sistema (por exemplo, ida e volta).
- Deixe de lado Funcionalidades que Fariam a Vida do Usuário Mais Fácil – Deixe Eles Fazerem Da Forma Mais Difícil (Pesada)- quando os usuários querem incluir itens em uma lista, permita que eles incluam itens somente no final da lista e deixe os então mover os itens para a posição correta. Isto é, não ofereça funcionalidades adicionais para inserir os itens nos lugares adequados. Ao incluir algum item remanescente, introduza erros que retornam o item ao final da lista depois do usuário já ter movido o item até metade do caminho.
- Não Deixe os Usuários Interromperem Processos Lentos e com Alto Processamento - Começar um processo de backup ou indexação enquanto o usuário não tem ciência dos mesmos. Fazer o processo difícil de ser cancelado, isto é, deixar ele ignorar os cliques de mouse e digitação de teclas do usuário.
- Faça ele Sem Lógica - Rotule um botão que irá somente preparar uma operação e então os usuários acreditarão que ele já executará a operação. Aqui um exemplo do mundo real: Em muitas aplicações de e-mail, o botão de Encaminhar não encaminha realmente o e-mail mas somente o prepara para o encaminhamento (porque, por exemplo, o destinatário ainda precisa ser informado).
- Inclua um Crash do Sistema de Tempos em Tempos ou Deixe a Aplicação Simplesmente Travar - Deixar editores ou campos de edição por intervalos imprevisíveis travados e então os usuários não terão o hábito de salvar seus trabalhos frequentemente, o que desnecessariamente desperdiça recursos valiosos do sistema.
- Bloqueie Entradas de Dados do Usuário Sempre que Possível - Carregamento da página é também um evento apropriado para bloquear entradas de dados pelo usuário. Usuários podem bater papo com seus colegas de quarto, ler o jornal, ou simplesmente ficar encarando a tela em branco durante aquele tempo.
- Bloqueie Entradas de Dados do Usuário Mesmo se Não É Necessário - Bloquear a entrada de dados pelo usuário com uma imagem no navegador enquanto a imagem é atualizada é um bom exemplo disto – não existe absolutamente razão nenhuma de porque os usuários não devem ser capazes de rolar a tela, selecionar imagens ou iniciar uma ação.
Existem outros "bons" conselhos para fracassar um projeto RIA, quais deles devem ser evitados a qualquer custo?
Nenhum comentário
Acompanhar Discussão Responder