Princípios da usabilidade de jogos aplicados a Ambientes de Gestão de Projetos
Há vários meses vim adaptando esse post para tentar torná-lo algo prático e útil. A idéia geral é identificar princípios de usabilidade que, se implementados nas Ferramentas de Gerenciamento de Projetos, facilitarão a vida dos GPs (Gerentes de Projeto). O público-alvo desse post são empresas desenvolvedoras de software interessadas em construir aplicações mais amigáveis aos usuários (user friendly) saindo do paradigma tradicional de menus e telas.
Para identificar os princípios conversei com 15 gerentes de projeto, analisei o ferramental utilizado em seu trabalho e minhas descobertas não foram animadoras. Todos os Gerentes de Projetos entrevistados utilizavam mais de um software para executar o trabalho, sem integração entre as informações e também relataram sentir insatisfação com o panorama.
Por razões diversas, as empresas continuam utilizando diferentes plataformas de software para auxiliar a gestão de projetos. As vezes por exigência de um cliente, falta de capital ou interesse, mas a grande verdade é que não há ferramentas com boa usabilidade no mercado corporativo, sobretudo para GP.
Embora tenham surgido ferramentas para o gerenciamento de projetos (e.g. EPM, Primavera, Clarity etc) bem mais sofisticadas que o MS-Project, cuja aderência às práticas do PMBOK é relativamente baixa, o cenário em relação a usabilidade ainda é bem amador. São telas e mais telas para cadastrar requisitos, riscos, pessoas etc, sem nenhuma inteligência relevante, apenas dados. As integrações com o Outlook e telas para apontamento de horas ainda são o que há de melhor.
No pior cenário, utilizam-se várias ferramentas, misturando web com desktop e muito “Pacote Office”. No melhor cenário, tem-se ferramentas web onde são necessários vários cliques para preencher uma planilha, invés de uma interface similar ao Excel. Quanto tempo mais será necessário para que as empresas observem as perdas financeiras relacionadas ao uso de ferramentas ruins? Quantas horas o GP gasta “copiando e colando” e resolvendo problemas que deveriam ser de TI?
Mesmo que o projeto não utilize todas as áreas de conhecimento do PMBOK, algum tipo de retrabalho costuma ser comum. Na pesquisa constatei que:
- Menos de 5% trabalham com ferramentas integradas (EPM, Primavera, SAP)
- 100% usa mais de uma ferramenta para gerenciar os projetos
- 95% copia e cola dados entre ferramentas
- TODOS usam o pacote Office em algum momento do processo
- Quase 100% usa o MS-Project como ferramenta de controle de cronograma, os que não usam, não tem licença.
- A maioria sente-se insatisfeito com a integração entre as ferramentas
Por isso resolvi propor uma variação das heurísticas da usabilidade de Nielsen, utilizando um linguajar comum aos video-games. Escolhi utilizar essa roupagem porque é comum às pessoas da minha geração (já na faixa dos 30 e poucos) e pode fomentar o início de uma reflexão sobre o tema usabilidade. Abaixo apresento os princípios, com exemplos, figuras e mostrando como aplicá-lo ao contexto de Gestão de Projetos:
- Status – Jogos utilizam diferentes formas para indicar a quantidade disponível de determinado parâmetro. No exemplo abaixo, o jogo Street Fighter mostra a vitalidade de cada jogador. Outros jogos como Super Mario e Age of Empires mostram ícones e suas respectivas quantidades.
Street Fighter
No contexto de GP: Toda aplicação de gestão deve possuir dados sobre a situação atual dos projetos, são os Dashboards. Eles podem indicar a “saúde” geral dos projetos com apenas um gráfico e permitir que o detalhamento dos dados seja acessado com poucos cliques. O exemplo de dashboard abaixo foi criado pelo designer Bruno Cristalli.
Neste dashboard, o tamanho dos círculos representa o orçamento do projeto (ONT). A borda azul é o Valor Agregado e a laranja é o Valor Planejado. Esta é apenas uma forma de mostrar graficamente a situação do portfólio, existem muitos modelos de Dashboards e Relatórios de Status. - Ecrã – Em jogos raramente é necessário trocar de tela, apenas para alterar configurações ou visualizar dados detalhados de pontuação. Observe a riqueza de informações no ecrã do World of Warcraft no print abaixo. As barras inferiores e laterais mostram comandos selecionados pela preferência do usuário. A quantidade de barras também é configurável.
No contexto de GP: O mesmo princípio pode ser aplicado criando um centro de tela que permita edição de documentos e que possua barras laterais. Exemplos de funcionalidades que seriam interessantes: Inserir um risco, uma despesa, datas reais no cronograma etc. - Contextualização – Nos jogos as funções ficam disponíveis somente quando podem ser usadas. Da mesma forma as ferramentas de software devem habilitar/desabilitar botões e links conforme o contexto. Por exemplo, se o GP está na fase de Planejamento, os ícones relacionados ao Termo de Abertura poderiam ficar inativos; da mesma forma, os ícones de encerramento não ficariam disponíveis nos menus – exceto se configurados dessa forma.O importante da contextualização é apresentar ao usuário somente opções válidas.
- Sequenciamento (Leveling) – Nos jogos tudo tem uma sequência, após a fase 1 vem a 2 e assim por diante. No exemplo abaixo é possível identificar de forma simples quais são as próximas fases do jogo até o seu final.
No contexto de GP: Se o macro-processo for mapeado na ferramenta será possível tratar a documentação do projeto em workflow.
– Aprovações de planos e documentos,
– Atualizações de parâmetros (como riscos, atividades, mudanças de requisitos) sendo feitas de forma distribuída (por várias pessoas)
– Comunicação de status (riscos, orçamento, liberação de recursos) sendo feita automaticamente.
Outra vantagem do sequenciamento é o estabelecimento de “portões” (gates) de verificação do projeto, para que ele não leve problemas às próximas fases. - Limites – Mapas e comandos são previamente definidos nos jogos, o usuário pode se movimentar até um certo limite, sem risco de “cair do mapa” ou dar comandos errados.
No contexto de GP: É possível criar um software capaz de auxiliar o GP a manter-se no caminho correto, obedecendo “limites”. Por exemplo, de acordo com as políticas da organização, o software poderia: avisar que há atividades a vencer , mostrar os riscos da fase atual, sugerir a “baixa” em uma despesa etc. Desse modo, a grande maioria dos erros de auditorias seriam evitados, mantendo o foco nas entregas. - Tolerância a falhas– Os jogos possuem o conceito de “checkpoint”, que significa gravar um “momento” do jogo para que o usuário possa retornar a ele caso precise. Isso também previne o impacto de falhas no jogo, como a perda de conexão com a Internet.
No contexto de GP: A aplicação deve guardar versões periódicas do estado do projeto, como um controle de versões integrado. Permitindo que o GP consiga acessar o estado do projeto (completo ou parcial) em uma data específica. Deste modo poderia-se recuperar o estado anterior do projeto. - Ausência de Manual – Jogos não tem manual, no máximo um tutorial rápido com informações na tela. Da mesma forma, as ferramentas devem ser projetadas para terem um caminho lógico a ser seguido, com ícones dedutíveis e linguagem comum ao usuário. Parece impossível, mas hoje todos os celulares aplicam esse princípio.
“O homem deve dominar a máquina, e não o contrário” (Steve Jobs).
Eli Rodrigues
