8.1.A Ferramenta
Após a realização das entrevistas e dos dados produzidos por estas e com a determinação de que a gamificação poderia ser um poderoso contribuinte para construir pontes de entendimento, motivar envolvimento e incluir todos os stakeholders tornou-se necessário operacionalizar o conceito.
Considerou-se, então, desenvolver uma ferramenta sob a forma de uma aplicação que fosse familiar aos colaboradores e caraterizada pela usabilidade. Procedeu-se, por isso, ao estabelecimento de limites e cuidados que deveriam caraterizar a implementação.
Assim, a aplicação foi desenvolvida em Microsoft Access. O software já existia na organização e está disponível para todos os colaboradores. É, também, um software relativamente intuitivo e fácil de usar pelo que não se vislumbravam dificuldades nessa componente.
Figura 10- Modelo Entidade Relação da aplicação GameOn
Seguidamente procedeu-se à seleção do universo de utilizadores. Nesta abordagem, só foi permitida a utilização da ferramenta a colaboradores internos da organização.
72 Selecionou-se, de seguida, dois projetos cujo levantamento de requisitos decorreria durante o calendário adequado às datas da investigação.
Selecionaram-se dois projetos para testar a ferramenta e o conceito operacionalizado por esta. Um dos projetos referia ao sistema de informação nacional da atividade inspetiva (SINAI) e decorreu da obrigatoriedade da transposição da diretiva europeia que determina a necessidade de dispor de estatística relativa a acidentes de trabalho com formato comum. O segundo projeto referia ao sistema de gestão documental da organização, o Documentum e referia ao desenvolvimento do fluxo de aquisição de bens e serviços nesse sistema.
Procedeu-se também à nomeação da ferramenta aplicacional com o nome de GameOn .por se considerar que era exemplificativo e chamativo.
8.2.A comunicação com os utilizadores
Assim, foram enviadas aos utilizadores dos dois sistemas de informação duas mensagens (conforme Anexo D e E), via correio eletrónico, indicando que no servidor, na área comum da intranet organizacional estava disponível uma aplicação informática para apoiar o levantamento de requisitos para estes dois projetos. A bem da transparência e do rigor foi indicado que a ferramenta integrava a componente de investigação de uma dissertação de mestrado. Ainda assim, todos os requisitos recolhidos e interações registadas seriam recolhidos e avaliados de forma a integrarem o projeto. Foi, também, reforçado que o objetivo era que os utilizadores que são os verdadeiros clientes dos sistemas de informação se envolvam e contribuam para os melhorar. E que esta constituiria uma oportunidade para fazerem ouvir as suas opiniões.
Inclusivamente, existiam parâmetros na ferramenta que tinham sido recolhidos na análise de resultados das entrevistas realizadas anteriormente com colegas. Foi indicado que, por exemplo, os níveis de prioridades dos requisitos tinham sido definidos pelos entrevistados.
Resumidamente, indicou-se que a ferramenta em que seria feito o levantamento de requisitos era similar a um jogo e que tal como num jogo, os jogadores que desenvolverem determinadas ações são premiados com pontos. Assim, existiam tabelas com pontos e existia, inclusivamente, pontuação bónus quando o contributo fornecido for especialmente valioso e diferenciador. A estrutura de pontuação utilizada foi
73 baseada na conceção de (Ribeiro, et al., 2014) em que a criação do requisito era a ação mais valiosa, seguida da interação no requisito e por fim a atribuição de um bónus.
Por último foi disponibilizado na área comum da intranet da organização um manual aplicacional (conforme Anexo F) para orientar os jogadores na utilização da aplicação e com as indicações clara dos papéis e regras disponíveis para os jogadores. Foi, também, indicado que quaisquer dúvidas que surgissem poderiam ser esclarecidas mediante contacto telefónico com os investigadores tendo sido indicado esse contato.
8.3.Regras de Funcionamento
Foi elaborado um manual aplicacional extremamente detalhado indicando quais os limites da atuação de cada um dos papéis envolvidos: utilizador, analista de sistema e gestor de projeto. Indicava igualmente as regras de funcionamento, as regras de atribuição das pontuações e do bónus. Toda a informação relativa à operação da ferramenta foi complementada com print screens que guiavam o utilizador na operação da aplicação, permitindo assim que a criatividade fosse libertada na criação de requisitos e nas interações dos requisitos.
Indicou-se, ainda, que nesta fase a ferramenta estaria somente disponível para os colaboradores da organização, sendo essa uma das condições de registo dos utilizadores para utilizarem a ferramenta.
74 Após a disponibilização inicial da ferramenta, os utilizadores reportaram algumas questões e erros que indicavam que existia a necessidade de proceder a correções no funcionamento da aplicação. Todos os erros e dificuldades endereçados foram corrigidos e a ferramenta foi disponibilizada novamente. Durante a operação da ferramenta surgiram algumas dúvidas. Algumas relacionadas com a operação da ferramenta e outras relacionadas com o software de base. Existiram, também, alguns protestos relacionados com a lentidão no acesso à aplicação. Porém, esta lentidão decorre de questões relacionadas com a infraestrutura tecnológica que estão a ser endereçadas com recurso ao financiamento comunitário.
Após o encerramento da fase de levantamento de requisitos o analista de sistemas alocado àquele projeto produz, em template próprio (conforme Anexo G), os requisitos e interações elencados pelos utilizadores e entrega-os ao gestor do projeto.
Seguidamente, o gestor do projeto leva à consideração da direção os requisitos levantados e será a direção da organização que indicará quais os requisitos que integrarão o projeto.
A questão de colocar à consideração superior um conjunto de requisitos que os utilizadores elencaram pode afigurar-se como contraditório. Se damos liberdade aos utilizadores para elencar requisitos então porque são estes validados pela direção da organização? Como indicado anteriormente, o setor público além de normativos legais rígidos e de constrangimentos operacionais é caraterizado organizacionalmente por uma estrutura hierárquica forte e rígida. Assim, qualquer proposta de desenho de processo que vise o sucesso terá que se adaptar à estrutura organizacional.
A ferramenta esteve disponível durante 10 dias úteis e a os resultados da utilização serão analisados no capítulo próprio.
75