Definição e acompanhamento do desenvolvimento de uma plataforma interativa de apoio às práticas de gestão de projetos nas pequenas e médias empresas

Janeiro de 2021 Cláudia Alves Dinis Definição e Acompanhamento do Desenvolvimento de uma Plataforma Interativa de Apoio às Práticas de Gestão de Projetos nas Pequenas e Médias Empresas Janeiro de 2021 Cláudia Alves Dinis Definição e Acompanhamento do Desenvolvimento de uma Plataforma Interativa de Apoio às Práticas de Gestão de Projetos nas Pequenas e Médias Empresas Dissertação de Mestrado Mestrado em Gestão de Projetos de Engenharia Trabalho efetuado sob a orientação de Professor Doutor Pedro Ribeiro Professora Doutora Anabela Tereso ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii AGRADECIMENTOS Gostaria de agradecer a todos aqueles que me apoiaram e ajudaram ao longo de toda a jornada, que culminou na execução desta dissertação, e para a qual o apoio foi imprescindível. Agradeço ao meu orientador, Professor Doutor Pedro Ribeiro pela disponibilidade, pela partilha de conhecimentos e apoio durante a orientação desta dissertação. Agradeço à minha coorientadora, Professora Doutora Anabela Pereira Tereso pela dedicação, disponibilidade e paciência durante a orientação desta dissertação. À equipa de desenvolvimento do projeto o meu obrigada pelo rigor, pela atenção, pelo cuidado e pela dedicação. Aos meus colegas e curso e aos professores do MGPE que contribuíram para a conclusão deste mestrado. À Universidade do Minho por me ter acolhido nesta jornada de desenvolvimento pessoal. Agradeço aos meus amigos Thais, Gustavo e João por toda a paciência, apoio e motivação. Pela partilha de muitos bons momentos. À minha família, sobretudo pais e irmã, sempre! iv DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. v RESUMO Definição e Acompanhamento do Desenvolvimento de uma Plataforma Interativa de Apoio às Práticas de Gestão de Projetos nas Pequenas e Médias Empresas O paradigma da gestão de projetos está a mudar e cada vez mais faz parte da realidade das pequenas e médias empresas. As metodologias ágeis fazem parte dessa mudança. Elas vieram em oposição aos padrões tradicionais e a sua disseminação está a resultar numa adaptação dos modelos tradicionais das empresas. O entrelaçar das abordagens dá origem a modelos híbridos que permitem equilibrar flexibilidade e previsibilidade. Apesar da unicidade do modelo de gestão de projetos a implementar, adequado às necessidades específicas, ao ambiente de negócio e tipo de projeto, a partilha de conhecimento de uma gestão de projetos adaptada a este tipo de empresas é benéfica, uma vez que, na maioria dos casos, as PME não têm estrutura para suportar modelos pesados e inflexíveis. A presente dissertação descreve o processo de definição e acompanhamento o desenvolvimento de uma plataforma interativa de apoio à gestão de projetos nas pequenas e médias empresas. A plataforma foi definida pela investigadora desta dissertação e o projeto foi desenvolvido em ambiente académico, por uma equipa de alunos do Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação responsável pela gestão e desenvolvimento do projeto, no âmbito da Unidade Currícular Projetos e Tecnologias de Sistemas de Informação. Para a gestão do projeto recorreu-se a uma metodologia híbrida, caracterizada no âmbito deste trabalho. A metodologia tradicional (modelo cascata) foi aplicada nas fases de iniciação, planeamento e conclusão e a metodologia ágil (modelo scrum ) na fase de desenvolvimento do projeto. Com esta investigação pretendeu-se a criação de uma plataforma e também a análise de desempenho da equipa e do modelo de gestão de projetos utilizado. Para o desenvolvimento desta investigação, e tendo em consideração as duas vertentes distintas, foram escolhidas duas metodologias, a Design Science Research e o Estudo de Caso. Da aplicação da metodologia Design Science Research resultou a produção de um artefacto. Da aplicação da metodologia Estudo de Caso resultou uma contribuição para o conhecimento relativamente ao contexto estudado. A plataforma HELP PME PROJECTS de apoio à gestão de projetos nas PME, o desempenho positivo da equipa e do modelo utilizado para a gestão deste projeto, são os principais resultados obtidos. PALAVRAS-CHAVE Desenvolvimento de Software , Gestão de Projetos, Modelos Híbridos, Pequenas e Médias Empresas vi ABSTRACT Definition and Monitoring of the Development of an Interactive Platform to Support Project Management Practices in Small and Medium Enterprises The paradigm of project management is changing and is increasingly part of the reality of small and medium-sized enterprises. Agile methodologies are part of this change. They came in opposition to traditional standards and their spread is resulting in an adaptation of traditional business models. The interweaving of the approaches gives rise to hybrid models that allow a balance between flexibility and predictability. Despite the uniqueness of the project management model to be implemented, appropriate to the specific needs, the business environment and type of project, the sharing of knowledge of project management adapted to this type of companies is beneficial, since, in most cases, SMEs have no structure to support heavy and inflexible models. This dissertation describes the process of defining and monitoring the development of an interactive platform to support project management in small and medium-sized companies. The platform was defined by the researcher of this dissertation and the project was developed in an academic environment, by a team of students from the Integrated Master’s in Engineering and Management of Information Systems, responsible for the management and development of the project due the course named Information Systems and Technologies Project. For the management of the project, a hybrid methodology characterized here was used. Traditional methodologies (waterfall model) were applied in the initiation, planning and conclusion phases and agile methodologies (scrum model) in the project development phase. With this research, the intention was to create a platform and also to analyze the team's performance and the project management model used. For the development of this research, and considering the two distinct aspects, two methodologies were chosen, the Design Science Research and the Case Study. The application of the Design Science Research methodology resulted in the production of an artifact. The application of the Case Study methodology resulted in a contribution to in knowledge regarding the studied context. The HELP PME PROJECTS platform to support project management in SMEs, the positive performance of the team and of the hybrid model used to manage this project, are the main results obtained. KEYWORDS Hybrid Models, Project Management, Small and Medium Enterprises, Software Development vii ÍNDICE Agradecimentos .................................................................................................................................. iii Resumo............................................................................................................................................... v Abstract.............................................................................................................................................. vi Índice ................................................................................................................................................ vii Índice de Tabelas ............................................................................................................................... xi Índice de Figuras .............................................................................................................................. xiii Lista de Abreviaturas, Siglas e Acrónimos .......................................................................................... xv 1. Introdução .................................................................................................................................. 1 Enquadramento .................................................................................................................. 1 Objetivos ............................................................................................................................. 3 Abordagem Metodológica .................................................................................................... 4 Design Science Research ............................................................................................. 4 Estudo de caso ............................................................................................................ 7 Metodologia adotada ................................................................................................... 9 Estratégia de pesquisa da literatura ........................................................................... 10 Estrutura do documento .................................................................................................... 14 2. Revisão da Literatura ................................................................................................................ 15 Pequenas e Médias Empresas ........................................................................................... 15 Identificação das PME ............................................................................................... 15 PME em Portugal ....................................................................................................... 19 Problemas específicos das PME ................................................................................. 19 Plataformas Digitais .......................................................................................................... 21 As plataformas digitais no ensino ............................................................................... 21 As plataformas digitais no âmbito profissional ............................................................ 22 Gestão de Projetos ............................................................................................................ 23 Projeto, programa e portefólio .................................................................................... 23 Gestão de projetos, programas e portefólios ............................................................... 24 viii O gestor de projetos, de programas e de portefólios ................................................... 25 A gestão de projetos nas PME .................................................................................... 26 Guias de apoio à gestão de projetos ........................................................................... 28 Requisitos e Pacotes de Requisitos .................................................................................... 29 Classificação dos requisitos ....................................................................................... 30 Análise de requisitos e definição do design ................................................................. 31 Gestão do ciclo de vida dos requisitos ........................................................................ 33 Qualidade em Projetos e na Gestão de Projetos ................................................................. 36 A qualidade em projetos ............................................................................................ 36 Gestão da qualidade em projetos ............................................................................... 37 Gestão da qualidade em scrum .................................................................................. 38 Stakeholders ..................................................................................................................... 40 Funções e responsabilidades dos stakeholders ........................................................... 40 Gestão dos stakeholders do projeto ............................................................................ 41 Risco ................................................................................................................................ 43 O risco nos projetos ................................................................................................... 44 Gestão do risco.......................................................................................................... 44 Gestão do risco em scrum ......................................................................................... 45 Abordagens para o Desenvolvimento de Software .............................................................. 46 Processo de software ................................................................................................. 46 Modelos tradicionais .................................................................................................. 46 Modelos ágeis (scrum) ............................................................................................... 48 Modelos híbridos ....................................................................................................... 54 3. Definição da Plataforma ............................................................................................................ 56 Stakeholders ..................................................................................................................... 56 Requisitos ......................................................................................................................... 58 Identificação e análise dos requisitos ......................................................................... 58 Gestão do ciclo de vida dos requisitos ........................................................................ 63 Priorização dos requisitos .......................................................................................... 65 xv LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS APOGEP – Associação Portuguesa de Gestão de Projetos CE – Comissão Europeia CT - Comissão Técnica DSR – Design Science Research GP – Gestão de Projetos ICB – Individual Competence Baseline IPQ – Instituto Português da Qualidade ISO - International Organization for Standard IVA – Imposto sobre o Valor Acrescentado MIEGSI – Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação ONS - Organismo de Normalização Setorial PDCA – Plan-Do-Check-Act PMBOK – Project Management Body of Knowledge PME – Pequenas e Médias Empresas PMI – Project Management Institute PTSI – Projetos e Tecnologias de Sistemas de Informação SI – Sistemas de Informação TI – Tecnologias de Informação TIC – Tecnologias de Informação e Comunicação TSI – Tecnologias e Sistemas de Informação UC – Unidade Curricular UE – União Europeia WBS – Work Breakdown Structure 1 1. INTRODUÇÃO Neste capítulo inicial encontram-se especificadas as motivações que levaram ao desenvolvimento desta dissertação. As motivações correspondem ao enquadramento e descrição global da problemática estudada. Após a definição destas, procedeu-se à definição dos objetivos, detalhe da abordagem metodológica utilizada e por fim à descrição da estrutura do documento. Enquadramento Em 2009 o Standish Group International definia sucesso como projetos entregues dentro do prazo, dentro do orçamento, com as características/funções requeridas; sucesso parcial como os projetos atrasados, acima do orçamento e/ou com menos características e funções do que as requeridas; por fim definia fracasso como os projetos cancelados antes de concluídos ou nunca usados. Porém, em 2015, efetuaram algumas alterações, definindo agora sucesso tendo por base seis características individuais: dentro do orçamento, dentro do prazo, dentro das metas, de acordo com os objetivos, com valor e que satisfaça o cliente. Deste modo, pela nova definição, um projeto de sucesso é um projeto que foi concluído dentro do prazo, dentro do orçamento e que proporciona satisfação para o cliente e para os utilizadores, independentemente do âmbito inicial, não sendo necessário cumprir os seis atributos simultaneamente. Apesar da evolução do conceito de Gestão de Projetos, do uso e aplicação de novos processos e práticas ao longo das décadas, as estatísticas mostram que as taxas de sucesso dos mesmos não têm aumentos significativos. Estes relatórios mostram que apenas 28% em 2000, 32% em 2008 e 29% em 2015 dos projetos incluídos nas suas pesquisas foram um sucesso; 49% em 2000, 44% em 2008 e 52% em 2015 foram um sucesso parcial e 23% em 2000, 24% em 2008 e 19% em 2015 foram um fracasso (dados até 2008 com antiga definição, dados de 2015 com nova definição) (The Standish Group International, 2009, 2015). É então evidente a necessidade de melhoria na aplicação das práticas de gestão de projetos, para que estas se façam refletir nas taxas de sucesso. O tecido empresarial europeu é maioritariamente composto por Pequenas e Médias Empresas (PME), “nove em cada dez empresas são PME e as PME geram dois em cada três postos de trabalho” (Comissão Europeia, 2015). Em Portugal, no ano de 2008, existiam 349 756 PME, correspondente a 99,7% das sociedades do sector não financeiro, sendo que, em 2017, 96,3% das empresas tinham menos de 10 pessoas ao serviço (INE, 2010, 2019). Consequentemente, a contribuição das PME para a economia em termos de emprego, inovação e crescimento é fundamental (Turner, Ledwith, & Kelly, 2010). 2 A gestão de projetos tem-se tornado cada vez mais uma realidade das PME e apresenta um impacto significativo e positivo na produtividade destas (Pollack & Adler, 2014). As práticas são menos formais, mais orientadas às pessoas e mais focadas no cliente (Turner & Ledwith, 2016). Na sua maioria utilizam uma versão “lite” da gestão de projetos, e as médias empresas recorrem a processos mais formalizados do que as micro e pequenas empresas (Turner et al., 2010). No entanto, a falta de reconhecimento da necessidade de diferentes práticas de gestão de projetos para as PME é visível, e guias como o PMBOK são considerados burocráticos demais para empresas e projetos menores (G. Fernandes, Ward, & Araújo, 2014; Turner & Ledwith, 2016). Assim a sobrecarga do negócio, o custo de desenvolvimento e o carácter burocrático na adoção da gestão de projetos apresentam-se como as principais barreiras (G. Fernandes et al., 2014). De forma geral, as PME com experiência adaptam, de forma inteligente, as práticas de gestão de projetos às suas necessidades, porém, para as demais, estes guias podem ser assustadores, levando ao desânimo para a adoção da gestão de projetos (Turner & Ledwith, 2016). Tendo em consideração esta questão e a mudança constante do mercado, as PME, com vista a competir com as grandes organizações na execução de projetos que garantam a satisfação do cliente, necessitam de colaborar entre si (Peças et al., 2012). A colaboração através das tecnologias da informação (TI) pode ser favorável nesta questão. Várias pesquisas sobre as oportunidades e ameaças do uso das TI na gestão de projetos mostram que estas são favoráveis para as áreas de comunicação, cooperação, comprometimento, gestão do conhecimento, desenvolvimento dos funcionários e também na produtividade e promoção do projeto (Hysa & Spalek, 2019). As empresas usam as TI para comunicarem internamente, mas também com outras empresas, como vendedores, fornecedores ou parceiros. As redes sociais, são TI que dentro e fora das empresas aumentam o valor da colaboração, reduzindo os custos de pesquisa e coordenação, de ligar as partes que têm conhecimentos e interesses relacionados (como citado em Remidez & Jones, 2012). No contexto da colaboração entre profissionais e empresas existem vários exemplos , nomeadamente sobre gestão de projetos, que comprovam a procura de conhecimento desta área e colaboração entre empresas. Devido ao grande sucesso do blog “Gestão por Processos e Gestão por Projetos”, atualmente desativado, de Flávio Sierve, que no mês de maio de 2014 contava com 3 224 visualizações, surgiu o portal colaborativo “Gestão por Processos e Projetos”. Este foca não só a gestão por processos mas também a gestão por projetos, sendo versátil a todas as áreas de atuação das empresas. O portal pretende auxiliar, via web, os projetos do dia-a-dia e permitir a troca de experiências e de melhores práticas aos utilizadores (Sierve, 2014). O “Portal PME – Portal da empresa” é uma 3 plataforma digital para a promoção dos negócios das empresas, ajudando nomeadamente na abertura de novas empresas, pelo que é um ponto de encontro de empreendedores (PME, 2020). Outro tipo de plataformas comuns são as de financiamento coletivo, que procuram apoiar projetos inovadores através de doações, como é o caso da “Kickstarter“ (Kickstarter, 2020). Esta investigação vem no seguimento destas premissas. Para disseminar as boas práticas de gestão de projetos e fomentar a ajuda entre empresas e profissionais da área, procedeu-se à definição e desenvolvimento de uma plataforma interativa de apoio à gestão de projetos nas PME. A definição da plataforma ficou ao encargo da investigadora desta dissertação e o desenvolvimento foi da responsabilidade de uma equipa de alunos do Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação (MIEGSI). Para a gestão do desenvolvimento da plataforma, a equipa recorreu a um modelo híbrido, ajustado às necessidades do projeto, e, portanto, o acompanhamento da gestão do projeto mostrou-se relevante. Assim, para além da definição e desenvolvimento da plataforma, realizouse o acompanhamento da equipa de desenvolvimento, a avaliação do seu desempenho e a avaliação do modelo de gestão de projetos utilizado para este projeto. Objetivos Objetivo Geral: A presente investigação tem como principal objetivo “definir uma plataforma de apoio à gestão de projetos nas PME e acompanhar o seu desenvolvimento e gestão através de uma metodologia híbrida, concebida para este projeto.” Ou seja, para além de definir os requisitos da plataforma e adotar uma posição de product owner, pretendeu-se analisar também a gestão de projetos realizada por uma equipa de alunos universitários. A plataforma tem como base algumas plataformas semelhantes e o protótipo foi criado por um grupo de alunos do MIEGSI da Universidade do Minho. Objetivos específicos: a) Revisão de literatura sobre conceitos relevantes; b) Definir os requisitos da plataforma protótipo a desenvolver; c) Acompanhar o desenvolvimento da plataforma protótipo junto dos alunos de MIEGSI; d) Analisar o desempenho do modelo híbrido utilizado para o desenvolvimento da plataforma; e) Analisar o desempenho da equipa na gestão do projeto de desenvolvimento da plataforma. 4 Abordagem Metodológica As metodologias de investigação escolhidas para o desenvolvimento desta dissertação foram a Design Science Research (DSR) e o Estudo de Caso. A DSR aplicada à definição e desenvolvimento da plataforma e o estudo de caso aplicado ao acompanhamento da equipa. A metodologia DSR é uma metodologia de investigação que se apresenta como um ciclo entre as diferentes fases, proporcionando flexibilidade nos fluxos. Baseia-se na criação de um novo cenário para o mundo real (Santos, 2018). Por sua vez, o Estudo de Caso investiga um contexto do qual se desenvolve um conhecimento detalhado e intensivo. Num determinado contexto existe um número de variáveis restrito, pelo que a capacidade de o explorar, recolher dados e entender é limitada (Saunders, Lewis, & Thornhill, 2009). Design Science Research A DSR utiliza-se na engenharia e nas ciências do artificial. Procura resolver problemas e apresenta-se como um processo através do qual é desenvolvida uma sequência de ações que permitem mudar a situação presente em direção a uma situação desejada (Simon, 1996). A mudança na DSR A mudança é proporcionada através da avaliação da eficiência e eficácia de um artefacto na resolução de um problema (Santos, 2018). Artefacto é algo construído, não é natural (Simon, 1996). É uma contribuição de conhecimento que varia de acordo com a maturidade do domínio do problema e com a maturidade do domínio das soluções (Figura 1). Modelos, frameworks , arquiteturas, métodos, instanciações, teorias de design ou princípios de design são considerados artefactos (Shahin et al., 2012). Figura 1: Tipos de contribuição de conhecimento da DSR Adaptado de Gregor e Hevner (2013) Maturidade do domínio do problema Adaptação Invenção Melhoria Design de Rotina Baixa Alta Alta Baixa Maturidade do domínio das Soluções 5 O desenvolvimento na DSR O processo de desenvolvimento na metodologia DSR é colaborativo e divide-se em cinco etapas, Figura 2 (Shahin et al., 2012). • Perceção do problema - de modo a ampliar o conhecimento da área a investigar e a expor o problema de pesquisa realiza-se a revisão da literatura recorrendo a um leque de fontes diversificadas (Shahin et al., 2012). Artefactos desenvolvidos para problemas semelhantes podem ser objeto de estudo (Santos, 2018). • Sugestão - a primeira tentativa de design para colmatar o problema exposto na etapa anterior é realizada nesta fase do ciclo. É uma fase criativa, onde são projetadas funcionalidades tendo por base uma configuração nova de elementos existentes ou elementos novos e existentes. Se não surgir nenhuma solução para o problema, a proposta deve ser abandonada (Shahin et al., 2012). As soluções propostas devem ser satisfatórias, na medida em que o avanço alcançado com o artefacto seja visível e consensual para todos os envolvidos (Simon, 1996). • Desenvolvimento - nesta fase é desenvolvido e implementado o protótipo (Shahin et al., 2012). Para além do artefacto em si, devem ser criadas as condições necessárias para a sua avaliação (Santos, 2018). • Avaliação - após o desenvolvimento, segue-se a avaliação do artefacto. A avaliação deve ter por base os critérios definidos na fase de perceção do problema (Shahin et al., 2012). Procura-se a validação científica, o rigor na conceção e condução da pesquisa, a validação pragmática, a 1. Perceção do problema 2. Sugestão 4. Avaliação 3. Desenvolvimento 5. Conclusão Figura 2: Ciclo de etapas de pesquisa do DSR Adaptado de Vaishnavi et al. (2012) 6 eficácia e eficiência das soluções (Santos, 2018). Caso as expectativas não sejam atendidas, deve ser explicitada a razão (Shahin et al., 2012). • Conclusão - as fases que antecedem a conclusão realizam-se de forma cíclica, assim, antes da fase final, podem decorrer vários ciclos, até que a avaliação do artefacto seja positiva e este seja validado. Após a validação do artefacto, através da consolidação dos resultados obtidos na avaliação, são retiradas as conclusões relativas ao conhecimento alcançado com a pesquisa. As conclusões poderão constituir um conhecimento firme, onde o artefacto é fiável e pode ser aplicado repetidamente ou poderá apresentar anomalias comportamentais, que poderão servir de base para pesquisas futuras (Shahin et al., 2012). A DSR em sistemas de informação Quando se aplica a DSR à investigação em sistemas de informação - SI, existe um conjunto de diretrizes a considerar (Hevner, March, Park, & Ram, 2004): • Design as an Artefact: o resultado da metodologia DSR deve ser um artefacto passível de ser aplicado num determinado contexto; • Problem Relevance: deve ser realizada a exposição da relevância do problema de investigação para o negócio, e as soluções deverão dirigir-se a esses problemas; • Design Evaluation: o artefacto concebido deve ser sujeito a avaliação de modo a identificar a sua utilidade e qualidade; • Research Contributions: o contributo do artefacto deve ser claro, verificável e irrefutável; • Research Rigor: a construção e a avaliação do artefacto devem ter por base métodos rigorosos; • Design as a Search Process: o processo DSR é iterativo, procura encontrar o artefacto mais eficaz e recorre a todos os meios possíveis para atingir os objetivos; • Communication of Research: os resultados devem ser apresentados a audiências com orientação para as tecnologias e a audiências com orientação para a gestão. A flexibilidade e a boa definição dos resultados esperados e do fluxo do processo são os motivos que levaram à escolha desta metodologia. Tendo em consideração o contexto desta dissertação, a contribuição de conhecimento esperada apresenta uma maturidade de domínio do problema baixa, uma vez que a gestão de projetos nas PME se trata de um tema com pouca literatura relacionada. Por sua vez, a maturidade do domínio da solução é alta visto que existem muitas soluções semelhantes. Assim, espera-se que o artefacto desta dissertação seja do tipo de contribuição adaptação (ver Figura 1). 7 Estudo de caso O Estudo de Caso pesquisa o “como” e o “porquê” de um acontecimento contemporâneo, ou seja, “caso”, sobre o qual não existe controlo dos eventos comportamentais. É uma estratégia de pesquisa onde a investigação de uma situação é limitada pelo seu contexto do mundo real, cujo limites entre o fenómeno e o contexto não são bem definidos (Yin, 2018). O desenvolvimento do Estudo de Caso O Estudo de Caso é um processo interativo, que se divide em 6 fases, Figura 3 (Yin, 2018): • Planear – a fase de planeamento consiste em identificar uma situação relevante e decidir realizar o estudo de caso em detrimento da utilização de outros métodos; • Idealizar – nesta fase define-se a ligação lógica entre os dados a recolher e as questões iniciais do estudo. Isto é, idealizar consiste em definir a estratégia de pesquisa, o(s) caso(s) a ser estudado(s), e em desenvolver as preposições e questões que serão o guia orientador do estudo de caso; • Preparar – preparar consiste em aprimorar as competências do investigador, melhorar o conhecimento relativamente ao estudo de caso específico e desenvolver um protocolo real de recolha de dados; • Coletar – corresponde à fase de recolher os dados através das técnicas escolhidas, relacioná-los entre si e criar uma base de dados; 2.Idealizar 1.Planear 6.Partilhar 4.Coletar 3.Preparar 5.Analisar Figura 3: Fases do Estudo de Caso Adaptado de Yin (2018) 8 • Analisar – esta fase consiste em examinar, categorizar, tabular, testar ou outra forma de analisar dados. A análise deve ser de qualidade, contemplar interpretação dos dados e deve ainda ter em consideração interpretações alternativas; • Partilhar – esta é a última fase e consiste em partilhar os resultados e conclusões do estudo de caso no formato adequado e para a audiência pretendida. Técnicas de recolha de dados A recolha de dados é uma fase muito importante do Estudo de Caso, e, portanto, uma recolha variada dos dados tem um impacto na qualidade dos dados recolhidos. Na recolha de dados podem ser tidas em consideração seis técnicas: análise documental; análise de arquivos; entrevistas; observação direta; observação-participação; e artefactos físicos (Yin, 2018). Simplificadamente temos as técnicas de observação, análise documental, entrevistas e questionários (Saunders et al., 2009). • Observação - a técnica de observação tem impacto positivo na riqueza dos dados da pesquisa, principalmente quando as questões/objetivos de pesquisa se relacionam com a forma como os indivíduos realizam determinada tarefa. Esta técnica tem duas vertentes, a observação participante que se relaciona com a descoberta dos significados associados às ações, e a observação estruturada que se relaciona com a frequência de ocorrência de determinada ação ou à razão que levou a que esta não ocorresse, pode corresponder a apenas uma parte da abordagem de recolha de dados selecionada (Saunders et al., 2009). • Análise documental – a análise documental pode realizar-se a partir de análise primária ou secundária. A análise primária diz respeito à análise de dados que foram recolhidos especificamente para esse propósito, e a análise secundária diz respeito à análise de dados que já foram recolhidos previamente para um outro propósito (Saunders et al., 2009). • Entrevistas – as entrevistas têm como objetivo recolher dados válidos, confiáveis e relevantes para a questão/objetivo da pesquisa. No entanto, entrevistas também podem ser considerados questionários (Saunders et al., 2009). • Questionários – à definição de questionário correspondem as questões realizadas pessoalmente ou por telefone e também a coleta de dados em que cada pessoa responde ao mesmo conjunto de perguntas, seguindo um ordem pré-determinada (Saunders et al., 2009). Nesta investigação, o “caso” será a gestão do projeto de desenvolvimento da plataforma realizada pela equipa de alunos do MIEGSI. As técnicas de recolha de dados selecionadas foram a observação estruturada numa perspetiva de product owner , a análise dos documentos do projeto 9 realizados pela equipa ( project charter; relatório de progresso; relatório de estado; relatório de execução; atas de reunião; relatório final; e documentos do produto) e um questionário aplicado à equipa. Metodologia adotada A definição e desenvolvimento de uma plataforma e o acompanhamento da equipa na gestão do projeto são duas vertentes distintas desta investigação e, portanto, a escolha de utilização das duas metodologias (DSR e do Estudo de Caso) procura adequar-se a cada uma delas. Neste sentido, de modo a compreender a aplicação destas, apresenta-se um resumo da sua aplicação durante o desenvolvimento da dissertação, tendo sempre em consideração o bom seguimento das metodologias, isto é, tendo sempre em consideração as etapas de cada uma delas. A introdução e a revisão da literatura deram lugar à primeira etapa da DSR (perceção do problema) e à primeira, segunda e terceira etapas do Estudo de Caso (planear, idealizar e preparar). Aqui consideraram-se conceitos relevantes para esta dissertação, nomeadamente, conceitos de PME, plataformas digitais, de gestão de projetos, requisitos, qualidade, stakeholders , riscos e desenvolvimento de software . Foi possível identificar as motivações da investigação bem como definir a finalidade e objetivos da mesma e também identificar a oportunidade de acompanhamento de uma equipa na gestão de um projeto de desenvolvimento de uma plataforma através da aplicação de um modelo híbrido (“caso”). Assim, para a DSR resultou a formalização da questão de investigação, e dos objetivos estruturantes (subcapítulo 1.2 – Objetivos) e a descrição da revisão da literatura (capítulo 2 – Revisão da Literatura). Para o Estudo de Caso resultou a identificação da situação e a formalização do “caso” (subcapítulo 1.2 – Objetivos), a definição da estratégia de pesquisa (subcapítulo 1.3 – Abordagem Metodológica) e o aprimoramento das habilidades de pesquisador (capítulo 2 – Revisão da Literatura). Concluída a primeira etapa da metodologia DSR iniciou-se a fase de sugestão. Para auxiliar nesta etapa foram analisadas algumas plataformas de domínio semelhante. A definição da plataforma HELP PME PROJECTS é apresentada no capítulo 3 (capítulo 3 – Definição da Plataforma). A etapa seguinte da DSR corresponde à descrição do desenvolvimento do artefacto, que contou com a colaboração de uma equipa da área de TSI – Tecnologias e Sistemas de Informação (subcapítulo 4.3 – Desenvolvimento do projeto). Para cumprir o Estudo de Caso, e tendo em consideração o “caso”, procedeu-se á recolha de dados para análise das práticas de gestão de projetos realizada pela equipa, correspondendo à quarta etapa desta metodologia (coletar) (subcapítulo 4.1 – A Equipa; subcapítulo 4.2 – Planeamento do Projeto: descrição do trabalho realizado pela equipa). 16 Figura 4: Etapas para identificação das PME (Comissão Europeia, 2015) 1ª. Sou uma empresa? Uma empresa é “qualquer entidade que, independente da sua forma jurídica, exerce uma atividade económica” (Comissão Europeia, 2015, p. 9). Por atividade económica entende-se a troca, num mercado específico, de produtos/serviços associada a uma recompensa, que é o preço. Desde que exerçam atividade económica, considera-se uma empresa os trabalhadores por conta própria, as empresas familiares, as parcerias e ainda as associações ou quaisquer outras entidades (Comissão Europeia, 2015). 2ª. Que critérios devem ser verificados? Quais os limiares? O número de efetivos, o volume de negócios anual e o balanço total anual são os critérios a considerar aquando da definição de uma empresa. Assim, para ser considerada uma PME a empresa tem de cumprir o número de efetivos, mas apenas terá de satisfazer um dos restantes critérios. Esta flexibilidade deve-se às diferenças advindas dos diferentes setores. Os dados a utilizar são relativos ao último exercício contabilístico anual encerrado (Comissão Europeia, 2015). Para além da distinção das PME das demais existe ainda a distinção interna, em médias, pequenas e microempresas (Comissão Europeia, 2015). A Tabela 2 ilustra as categorias, e os respetivos limiares. Tabela 2: Limiares de distinção entre Médias, Pequenas e Microempresas (Comissão Europeia, 2015) Categoria da empresa Nº de Efetivos: unidade de trabalho ano (UTA) Volume de Negócios Anual (milhões de euros) Balanço Total Anual (milhões de euros) Média < 250 ≤ 50 ≤ 43 Pequena < 50 ≤ 10 ≤ 10 Micro <10 ≤ 2 ≤ 2 1ª Sou uma empresa? 2ª Que critérios devem ser verificados? Quais os limiares? 3ª O que esses critérios abrangem? 4ª Como calcular os dados? ou 0 17 Tendo em consideração a volatilidade dos mercados, a CE definiu que, de forma geral, uma empresa só perderá o estatuto adquirido anteriormente de PME caso exceda algum dos limiares dos critérios durante o exercício de dois anos consecutivos. Isto não se aplica em casos de mudança de propriedade, fusão ou aquisição (Comissão Europeia, 2015). 3ª. O que esses critérios abrangem? Nesta etapa pretende-se descrever cada um dos critérios avaliados na identificação das PME, são eles os efetivos, o volume de negócios anual e o balanço total anual (Comissão Europeia, 2015). Efetivos O critério do número de efetivos é obrigatório aquando da classificação de uma empresa como PME, e ainda é determinante para definir qual a categoria de PME em que se insere (Comissão Europeia, 2015). Engloba os trabalhadores a tempo inteiro, tempo parcial, temporário e sazonal. Engloba também as categorias de (Comissão Europeia, 2015): • Assalariados (definição de acordo com as legislações laborais de cada país); • Indivíduos que trabalham para a empresa; Indivíduos destacados na empresa; Indivíduos equiparados a assalariados; • Proprietários-gestores; • Sócios que exerçam uma atividade regular na empresa e beneficiem das vantagens financeiras. São excluídos (Comissão Europeia, 2015): • Indivíduos que se encontrem na condição de aprendizes ou estudantes em formação profissional e contratados com contrato de aprendizagem ou de formação profissional; • Assalariados que se encontrem em licença de maternidade ou parental. Volume de negócios anual O cálculo do volume de negócios é realizado a partir das receitas de uma empresa durante o ano em questão. As receitas resultam da venda de produtos e/ou da prestação de serviços, após deduzidas as reduções sobre as vendas. Aqui estão excluídos o imposto sobre o valor acrescentado (IVA) e os impostos indiretos (Comissão Europeia, 2015). Balanço total anual O balanço total anual é calculado através do valor dos principais ativos da empresa (Comissão Europeia, 2015). 18 4ª. Como calcular os dados? Para ajudar a definir os dados a considerar é importante distinguir claramente a situação económica de uma empresa, uma vez que poderá ser necessário incluir os dados das empresas que detêm participações aquando do cálculo dos financeiros. Na Tabela 3 estão descritas as três categorias que correspondem às relações que as empresas mantêm com outras (Comissão Europeia, 2015). Tabela 3: Categorias de definição das PME (Comissão Europeia, 2015) Categorias Participações no capital ou direito de voto de outras empresas na minha empresa Participações no capital ou direito de voto da minha empresa noutras empresas Autónoma < 25% (cada) < 25% (cada) Parceira 25 - 50% 25 - 50% Associada > 50% > 50% Autónoma No que concerne às empresas autónomas, existem exceções, alguns investidores, especificados pela CE, podem deter entre 25% a 50% do capital ou direito de voto de uma empresa, não podendo estar associado nem a título individual ou em conjunto. Os dados a ser considerados neste tipo de empresas são apenas os seus próprios (Comissão Europeia, 2015). Parceira Quando se trata de empresas parceiras, estas devem considerar, proporcionalmente, os seus dados e os dados da empresa sua parceira. Caso a empresa parceira seja associada a outra empresa, os dados dessa empresa parceira também devem ser considerados. Tal não acontece se apenas tiver outro(s) parceiro(s) (Comissão Europeia, 2015). Os tipos de investidores que têm estatuto público mencionados pela CE como exceção para as empresas autónomas também aqui o são, pois apenas estas seguem as regras normais das empresas parceiras. Todas as empresas que sejam detidas ou controladas por um ou mais organismos públicos têm limite de 25% de participação, caso ultrapasse, não é considerada PME (Comissão Europeia, 2015). Associada Relativamente às empresas associadas, no tratamento dos dados, considera-se a totalidade dos dados da empresa associada ou contas consolidadas. Os dados das empresas parceiras da empresa e/ou 19 que lhe é associada também deverão ser abrangidos. O mesmo acontece no caso das empresas associadas às suas empresas associadas (Comissão Europeia, 2015). PME em Portugal As PME em Portugal, assim como na União Europeia, representam a grande maioria do tecido empresarial. Em 2018, aproximadamente 99,9 % das empresas eram PME. A categoria predominante em Portugal são as microempresas, representando aproximadamente 96,2% das PME e empregando cerca de 56,7% do total de indivíduos das PME (Tabela 4). No entanto são elas que apresentam o volume de negócios mais baixo, cerca de 31,2% do volume total das PME (PORDATA, 2020). Tabela 4: Caracterização das PME em Portugal, em 2018, por categoria da empresa (PORDATA, 2020) Categoria da Empresa Representação Pessoal ao Serviço Volume de Negócios Média 0,5% 19,1% 36,3% Pequena 3,3% 24,2% 32,5% Micro 96,2% 56,7% 31,2% Em 2018 existia um total de 1 295 229 empresas, das quais 67,4% eram empresas individuais (PORDATA, 2020). Das empresas não financeiras (1 278 164 empresas), que representavam 98,7% do total de empresas em Portugal, 96,2% situavam-se no escalão do número de pessoal ao serviço mais baixo (menos de 10 indivíduos), sendo que apenas 0,1% das empresas se situam no escalão mais alto (250 ou mais indivíduos) (PORDATA, 2020). Os setores de atividade que mais se pronunciam são: comércio por grosso e a retalho (16,8%); agricultura, produção animal, caça, silvicultura e pesca (10%); alojamento, restauração e similares (8,7%); e atividades de saúde humana e apoio social (7,6%). Em média, em Portugal, em 2018, as empresas eram constituídas por 3,2 indivíduos. No entanto, o número médio de indivíduos por empresa, em cada um destes setores de maior destaque estão, na sua maioria abaixo da média (PORDATA, 2020). Problemas específicos das PME As PME sofrem devido a alguns problemas de mercado e estruturais que não ocorrem noutro tipo de empresas, e por isso são mais frágeis, requerendo uma maior atenção e assistência relativamente às restantes. Um dos problemas são as deficiências do mercado. As deficiências ocorrem ao nível das 20 áreas das finanças, investigação, inovação ou regulamentação ambiental. As dificuldades que estas empresas enfrentam relativamente ao acesso a financiamento ou ao investimento para investigação e inovação podem tornar muito difícil ou até impossível a competição no mercado livre. A falta de recursos humanos e materiais também se mostra relevante nas questões de cumprimento de regulamentação, nomeadamente normas ambientais (Beaver, 2007; Comissão Europeia, 2015). Os obstáculos estruturais, tais como a falta de competências e conhecimentos de técnica, de gestão, de oportunidades de expansão internacional e a rigidez dos mercados de trabalho, representam uma preocupação (Comissão Europeia, 2015). Pois, apesar do elevado número de novas PME por ano, a sobrevivência das mesmas é preocupante, sendo os três primeiros anos os mais críticos, com uma taxa superior a 50% de PME que apresentam falência (McCain, 2018). Apesar dos esforços de simplificação já realizados pela UE, o Instituto Português da Qualidade (2020) deu a conhecer um conjunto de legislações que representam as dificuldades e custos que são apontadas por estas empresas como os de maior impacto e preocupação: • REACH (Regulamento relativo ao registo, avaliação, autorização e restrição dos produtos químicos); • IVA; • Pacote legislativo relativo à segurança geral de produtos e à vigilância do mercado; • Reconhecimento das qualificações profissionais; • Diretiva-Quadro Resíduos (lista de resíduos e resíduos perigosos); • Legislação relacionada com o mercado de trabalho; • Proteção de dados; • Tempo de trabalho; • Legislação sobre tacógrafos (registo de velocidade, períodos de condução e de repouso); • Procedimentos para a adjudicação de contratos públicos (contratos de obras públicas, fornecimentos e serviços); • Código Aduaneiro Modernizado. Prazos de pagamento muito longos nas transações comerciais, problemas de liquidez devido ao atraso nos mesmos e dificuldade de obtenção de economias de escala também foram apontados como dificuldades (Fonseca, 2011; IPQ, 2020). A falta de importância dada às atividades de planeamento estratégico, bem como a falta de estratégia de longo prazo dificulta a capacidade de acompanhar as mudanças do mercado (Fonseca, 21 2011; McCain, 2018). A esta falha, junta-se ainda a baixa taxa de utilização de ferramentas tecnológicas de apoio à gestão, que são uma mais-valia para todo o tipo de empresas e o foco na alocação eficiente dos recursos que aumenta a vulnerabilidade e dificuldade de resposta a influências externas (Beaver, 2007; Fonseca, 2011). Apesar das dificuldades, as PME também apresentam vantagens, nomeadamente ligadas à sua estrutura mais leve, havendo necessidade de exploração das mesmas (Fonseca, 2011). Plataformas Digitais Atualmente, as Tecnologias de Informação e Comunicação - TIC são integrantes do quotidiano da sociedade. Vivemos na “Sociedade da Informação” e esta “… exige uma contínua consolidação e atualização dos conhecimentos dos cidadãos. O conceito de educação ao longo da vida deve ser encarado como uma construção contínua da pessoa humana, dos seus saberes, aptidões e da sua capacidade de discernir e agir” (MSI, 1997, p. 39). “A expressão ‘Sociedade da Informação’ refere-se a um modo de desenvolvimento social e económico em que a aquisição, armazenamento, processamento, valorização, transmissão, distribuição e disseminação de informação, conducente à criação de conhecimento e à satisfação das necessidades dos cidadãos e das empresas, desempenham um papel central na atividade económica, na criação de riqueza, na definição da qualidade de vida dos cidadãos e das suas práticas culturais. A sociedade da informação corresponde, por conseguinte, a uma sociedade cujo funcionamento recorre crescentemente a redes digitais de informação” (MSI, 1997, p. 5). Esta secção debruça-se sobre as plataformas digitais no ensino e no âmbito profissional. As plataformas digitais no ensino Os estudantes de hoje, pertencentes à geração milénio (nascidos entre 1982 e 2004), “nasceram com um chip ”, isto é, estes dominam a tecnologia, confiam nos mecanismos de busca, interessam-se por multimédia, têm um curto período de atenção e fazem multitarefas (como citado em Abe & Jordan, 2013). Assim, o ensino é um dos beneficiados do acesso digital à informação, pois permite sincronizar entretenimento com aprendizagem, lazer com desenvolvimento de capacidades mentais, lazer com melhoria de reflexos e abre portas para a imaginação (MSI, 1997). Durante a última década, os media e a tecnologia tornaram-se prevalecentes no dia-a-dia das escolas e das instituições académicas (Chawinga, 2017). Têm vindo a ser reconhecidos como ferramentas de apoio à educação, que suplementam a colaboração entre estudantes, as interações sobre 22 assuntos da aula e a comunicação aluno-professor (Tait & Eds, 2012). Em 2007, segundo o Higher Education Research Institute, 94% dos estudantes universitários do primeiro ano utilizam redes sociais, sendo estas utilizadas para manter contacto com os familiares e amigos e também para partilhar opiniões pessoais (Chawinga, 2017). Uma vez que o uso das redes socias por parte dos alunos já é uma realidade, é então necessária a adaptação das mesmas para as salas de aula (Chawinga, 2017). Estas podem representar uma ferramenta útil para aprimorar a aprendizagem dos alunos, uma vez que os incentiva a interagir e pode levar ao aumento do envolvimento e interesse nos conteúdos (Abe & Jordan, 2013). A aprendizagem a partir da construção de comunidades virtuais permite a interação, a partilha de objetivos, de interesses e por consequente fomenta a aprendizagem individual dos indivíduos membros, proporcionando um aumento da autonomia do aluno e tornando-o o principal responsável pela sua aprendizagem. Estes sistemas podem ser programas de simulação, chats, fóruns de discussão, entre outros (Miranda et al., 2001). Os fóruns permitem o enriquecimento científico, a partilha de opiniões, de conhecimento e fortalecem a interação aluno – professor. Estas mais-valias são escaladas na medida em que através do arquivo das discussões é possível relembrar os temas debatidos (Miranda et al., 2001). Alunos e professores reconhecem os fóruns como úteis e adequados à interação fora da sala de aula (Cunha & Paiva, 2003). O Twitter apresenta-se como uma das ferramentas mais utilizadas nesta relação do digital e ensino. É considerado um microblogging , que possibilita a comunicação através de mensagens curtas, com no máximo 140 caracteres (Tang & Hew, 2017). Esta é uma plataforma considerada positiva para colaboração pergunta-resposta, pois para além de facilitar a discussão na sala de aula, apresenta-se como uma mais-valia, como ferramenta de reflexão instruindo os alunos a publicar/ler em blogs, continuando a discussão crítica dos tópicos da sala de aula (Abe & Jordan, 2013; Tang & Hew, 2017). As plataformas digitais no âmbito profissional Os media auxiliam no que concerne à facilitação de informações, encurtando o tempo. Porém é necessário manter o equilíbrio entre a presença pessoal e profissional nas plataformas (Zimba et al., 2019). Na comunicação entre a equipa os métodos tradicionais, tais como comunicação pessoalmente e telefonemas, continuam a ser os preferidos. No entanto os profissionais que se servem de plataformas digitais para se comunicar reconhecem as suas vantagens (Cardon & Marshall, 2015). 23 Na área da saúde os media têm um papel importante para os profissionais chegarem a outros colegas, utentes e também na melhoria das práticas clínicas (Zimba et al., 2019). Apesar de existirem diversas plataformas e uma vasta gama de informações, é necessária prudência relativamente à desinformação, promoção antiética e disseminação de comportamento não profissional em plataformas em expansão global. Assim, filtrar informações confiáveis e comprovadas por especialistas e por utilizadores qualificados é fundamental (Zimba et al., 2019). As plataformas digitais auxiliam na eliminação de barreiras culturais e regionais à informação, e os indivíduos gostam de ajudar os outros, sem que haja algum tipo de relação entre os elementos intervenientes, pois na maioria dos casos, nas plataformas digitais procura-se o benefício de curto prazo (Kwahk & Park, 2016). Os laços de interação social e a reciprocidade levam a um aumento da partilha de conhecimento nas plataformas digitais, e impactam significativamente o desempenho no trabalho. Existem várias plataformas de sucesso de suporte à gestão de projetos. A sua análise e exploração é essencial para a realização desta dissertação, nomeadamente na definição dos requisitos. Assim, no capítulo 3 – Definição da Plataforma, procedeu-se análise de plataformas semelhantes. Gestão de Projetos O estudo da Gestão de Projetos é tido como recente, porém, apesar da escassa documentação das metodologias e/ou técnicas utilizadas antes dos anos 50, os grandes projetos como a Pirâmide de Gizé e a Muralha da China mostram que esta remonta aos tempos antigos. Com os avanços da ciência cada vez mais se aceita gestão de projetos como profissão (Seymour & Hussein, 2014). Nesta secção é possível encontrar as definições de Projeto, Programa e Portefólio; Gestão de Projetos, Programas e Portefólios; é apresentado o papel do Gestor de Projetos, Programas e Portefólios. Aqui é também abordado o tema da Gestão de Projetos nas PME e introduzidos alguns Guias de Apoio à Gestão de Projetos existentes. Projeto, programa e portefólio Um projeto é um esforço temporário realizado com o objetivo de criar um produto, serviço ou resultado, é único, organizado e multidisciplinar (IPMA, 2015; PMI, 2017a). É temporário, pois tem um início e um fim definidos, sendo que o fim pode ser definido não só através de uma data, mas também através do alcance dos objetivos do projeto, da impossibilidade de cumprimento dos objetivos, ausência de recursos, entre outros. O facto de os projetos serem temporários não obriga a que as entregas sejam realizadas até ao encerramento do projeto (PMI, 2017a). 24 Os projetos não se restringem a um nível da organização, envolvem, tipicamente, toda a organização, desde assistentes até gestores de projeto seniores (IPMA, 2015; PMI, 2017a). Podem envolver um único indivíduo ou um grupo, uma única organização ou múltiplas unidades organizacionais de múltiplas organizações (PMI, 2017a). Um projeto é iniciado como resposta a fatores que condicionam as organizações, pelo que os líderes respondem a estes com o objetivo de manter a organização viável. Estes fatores estão divididos em quatro categorias fundamentais (PMI, 2017a): • Cumprimento de requisitos reguladores, legais ou sociais; • Atendimento de pedidos ou necessidades das partes interessadas; • Implementação ou alteração estratégica do negócio ou tecnologia; • Criação, melhoramento e correção de produtos, processos ou serviços. Com o projeto pretende-se passar do estado atual (antes do projeto) para o estado futuro (resultado esperado da mudança impulsionada pelo projeto), espera-se que seja impulsionador das mudanças na organização (PMI, 2017a). Assim, espera-se que um projeto alcance um objetivo, ou seja, que consiga realizar os entregáveis acordados, em conformidade com os requisitos e restrições previamente definidos (IPMA, 2015; PMI, 2017a). Um projeto é bem-sucedido quando a organização passa do estado atual para o estado futuro e os objetivos específicos são atingidos (PMI, 2017a). Um programa define-se como um conjunto de projetos, programas subsidiários e atividades relacionadas do programa que, geridos em conjunto, possibilitam a obtenção de benefícios que não seriam possíveis se fossem geridos individualmente (PMI, 2017a). Com um programa pretende-se alcançar um objetivo estratégico (IPMA, 2015) Um portefólio define-se como um conjunto de projetos, programas, portefólios subsidiários e operações geridas em conjunto, de modo a alcançar objetivos estratégicos (IPMA, 2015; PMI, 2017a). Gestão de projetos, programas e portefólios A gestão de projetos define-se como a aplicação de conhecimentos, habilidades, métodos, ferramentas, competências e técnicas com o objetivo de cumprir os requisitos de um projeto (IPMA, 2015; PMI, 2017a). Esta é realizada através da aplicação e integração apropriada dos processos de gestão de projetos selecionados, focando-se nas interdependências que existem dentro de um projeto para determinar a abordagem ideal para o gerir (PMI, 2017a). 25 Os projetos são essenciais para a criação de valor e benefícios nas organizações, pelo que a gestão e execução eficiente e eficaz se apresenta como o benefício principal da gestão de projetos. Nos dias que correm, devido ao ambiente de negócios dinâmico e de rápida mudança, a gestão de projetos é realizada com orçamentos e prazos cada vez mais apertados e recursos escassos, pois só desta forma as empresas se conseguem manter competitivas. Uma gestão de projetos eficiente e eficaz permite às organizações vincularem os resultados do projeto com os objetivos do negócio, serem mais competitivos nos mercados, sustentarem-se e também melhorar a adaptação às mudanças no ambiente de negócios (PMI, 2017a). A gestão de programas é definida como a aplicação de conhecimentos, habilidades e princípios de modo a atingir os objetivos e a obter os benefícios e controlo que não estariam disponíveis se os componentes fossem geridos individualmente. Assim, a gestão de programas foca-se nas interdependências entre projetos e entre projetos e o nível do programa, com o objetivo de definir a abordagem ideal para os gerir (PMI, 2017a). A gestão de portefólios define-se como a gestão centralizada de um ou mais portefólios para alcançar objetivos estratégicos, devendo esta ser consistente e alinhada com a estratégia organizacional. Os componentes do portefólio (programas, projetos e operações) podem não ser interdependentes ou estar diretamente relacionados (PMI, 2017a). A gestão de projetos e programas tem como foco principal fazer programas e projetos da forma “certa”, já a gestão de portefólios tem como foco fazer os projetos e programas “certos” (PMI, 2017a). O gestor de projetos, de programas e de portefólios O gestor de projetos é responsável por liderar a equipa definida para alcançar os objetivos do projeto. É responsável por configurar a abordagem do projeto, o ciclo de vida e os processos de gestão de projetos, de modo a cumprir os requisitos do projeto e do produto (PMI, 2017a). O gestor de programas é autorizado pela organização para liderar a(s) equipa(s) responsável por atingir os objetivos do programa. Este mantém a responsabilidade pela liderança, conduta e desempenho do programa, e por selecionar a equipa do programa capaz de atingir os objetivos do programa e entregar antecipadamente benefícios do mesmo (PMI, 2017c). O gestor de portefólios estabelece e implementa a gestão do portefólio. Este é responsável por assegurar a comunicação e coordenação entre os componentes do portefólio (PMI, 2017b). 32 atributos dos requisitos. O objetivo é analisar, sintetizar e filtrar os requisitos especificados. Dá origem a um conjunto de requisitos em texto, matriz e diagrama (IIBA, 2015). • Verificar requisitos - aqui procura-se garantir que o conjunto de requisitos foi desenvolvido com um nível de detalhe tal, que possa ser utilizado por um stakeholder em particular. Através desta tarefa garante-se que os requisitos foram definidos corretamente, que atendem as necessidades e que cumprem as normas de qualidade (IIBA, 2015). • Validar requisitos - procura garantir que um conjunto de requisitos incorpora valor de negócio e que vão ao encontro dos objetivos e metas da organização. Procura-se entender qual é o estado futuro desejado pelos stakeholders , e expor, em caso de existência, as expectativas diferentes e conflituantes. Com este processo ir-se-á obter um conjunto de requisitos validados (IIBA, 2015). • Definir a arquitetura dos requisitos - nesta tarefa são estruturados todos os requisitos para que estejam alinhados com o objetivo geral da proposta de mudança no negócio, e que sejam coesos como um todo. Em conjunto devem atender inteiramente o objetivo e devem funcionar de forma harmoniosa. Daqui obtêm-se as relações entre os requisitos e ainda informação contextual (IIBA, 2015). • Definir opções de design - Identifica, explora e descreve possibilidades distintas que atendam às necessidades. O objetivo é definir a abordagem à solução mais adequada, identificar as oportunidades para potenciar o negócio e ligar os requisitos aos componentes da solução (IIBA, 2015). • Analisar valor potencial e recomendar solução - avalia o valor de negócio associado à potencial solução e compara as diferentes opções, realizando trade-offs, de modo a identificar e recomendar soluções que entregam o maior valor. Esta tarefa é realizada várias vezes ao longo do ciclo da mudança. A melhor solução pode ser clara ou não. A melhor opção poderá mesmo ser, não fazer nada (IIBA, 2015). Outras considerações No que diz respeito ao desenvolvimento de software , nesta fase é recolhida, junto do cliente e utilizadores, informação sobre o sistema, tais como a aplicação, os serviços, o desempenho e restrições (Sommerville, 2011). A recolha e documentação dos requisitos de software incorpora-se na engenharia dos requisitos. A engenharia dos requisitos consiste no conjunto de técnicas de recolha, documentação e análise de requisitos. Uma boa especificação dos requisitos é essencial. Não se trata de um custo supérfluo, mas sim de um investimento necessário e com retorno. Uma má especificação leva a custos muito superiores pelo que a participação dos utilizadores é essencial (Paula Filho, 2000). 33 Neste contexto a identificação e análise de requisitos é realizada através de quatro atividades, Figura 6 (Sommerville, 2011): • Descoberta dos Requisitos: consiste na identificação dos requisitos através da interação com os stakeholders . Pretende-se recolher informações sobre o sistema a desenvolver. Pode-se realizar através de entrevistas, cenários e/ou protótipos. Os requisitos advêm do domínio da aplicação, sistemas que interagem e dos stakeholders; • Classificação e Organização dos Requisitos: os requisitos relacionados são agrupados e organizados em grupos coerentes; • Priorização e Negociação de Requisitos: aqui pretende-se analisar os conflitos de requisitos e proceder à sua resolução, através de negociação, para que seja realizada a priorização dos mesmos; • Especificação dos Requisitos: procede-se à documentação dos requisitos. Figura 6: Elicitação dos requisitos (Sommerville, 2011) Após esta fase procede-se à Validação dos Requisitos, que consiste em procurar problemas e erros que possam causar custos altos posteriormente. É verificada a validade, a consistência, a completude, o realismo, a prototipagem, é analisada a verificabilidade, realizadas revisões de requisitos e são criados casos teste (Sommerville, 2011). Gestão do ciclo de vida dos requisitos Os requisitos devem ser geridos ao longo do projeto, de forma contínua. O propósito é garantir que o negócio, os stakeholders e as soluções estejam alinhados entre si e que as soluções sejam 34 implementadas, Figura 7. Porém a gestão não acaba quando a solução é implementada, durante a vida de uma solução, alguns requisitos continuam a providenciar valor (IIBA, 2015). • Rastrear requisito - rastrear um requisito prende-se com a capacidade de relacionar os requisitos entre si, identificando e documentando a linhagem de cada um, incluindo a sua rastreabilidade a montante (origem) e a jusante (alocação). Esta prática procura garantir a conformidade entre os requisitos e apoia na gestão do âmbito, mudança, risco, tempo, custo e comunicação. Permite analisar o impacto, inconsistências e lacunas nos requisitos; encontrar insights sobre o âmbito e sobre a complexidade de uma mudança (IIBA, 2015). • Manter requisitos - manter requisitos é assegurar que os requisitos são precisos e atuais ao longo do ciclo de vida, é gerir o conhecimento sobre os requisitos após a sua implementação, pois dessa forma estes poderão ser reutilizados noutras soluções. Os requisitos são definidos uma vez e estarão disponíveis a longo prazo para utilização da organização. Um requisito que não aprovado ou não implementado pode ser mantido para uma possível iniciativa futura (IIBA, 2015). • Priorizar requisitos - a priorização consiste no ato de classificar os requisitos de acordo com a sua importância para os stakeholders. Para tal é analisado o valor, a urgência e os riscos dos requisitos individualmente para garantir que a análise e/ou entrega do trabalho é realizada no momento certo. Esta pode referir-se ao valor relativo do requisito ou à sequência em que vão ser 1. Rastrear Requisito 2. Manter Requisitos 3. Priorizar Requisitos 4. Avaliar as Mudanças nos Requisitos 5. Aprovar os Requisitos Gestão do Ciclo de Vida dos Requisitos Figura 7: Tarefas da gestão do ciclo de vida dos requisitos (IIBA, 2015) 35 implementados. A priorização é um processo contínuo, e pode alterar-se de acordo com o contexto (IIBA, 2015). • Avaliar as mudanças nos requisitos - a avaliação consiste na recomendação para aprovar, modificar ou negar uma proposta de alteração dos requisitos. É avaliado o efeito potencial da mudança no valor da solução e para tal é necessário verificar se a mudança: se alinha com a estratégia geral; afeta o valor entregue; altera o tempo de entrega ou os recursos necessários; e se altera riscos, oportunidades ou restrições (IIBA, 2015). • Aprovar os requisitos - para aprovar requisitos, trabalha-se com os stakeholders no processo de governança, com o objetivo de se chegar a um acordo e à aprovação dos requisitos e projetos. O objetivo da aprovação dos requisitos é obter um acordo para iniciar ou prosseguir (IIBA, 2015). Outras considerações Nos sistemas de software, os requisitos são incompletos e estão em constante mudança, pois a perceção dos stakeholders altera-se ao longo do desenvolvimento do sistema. Após instalação e uso do mesmo, o surgimento de novos requisitos, novas necessidades e novas prioridades é inevitável. Assim, ao longo do tempo, os requisitos são alterados e a gestão dos requisitos consiste no controlo dessas alterações, Figura 8 (Sommerville, 2011). Figura 8: Evolução dos requisitos ao longo do tempo (Sommerville, 2011) Durante o planeamento da gestão dos requisitos, os requisitos são identificados para que possam ser comparados e sujeitos a avaliações de rastreabilidade. Após este processo, procede-se à gestão das mudanças onde é avaliado o impacto das mudanças. Para a gestão das mudanças deve-se ter em mente três fases essenciais: a análise do problema e especificação da mudança; a análise da mudança; e os custos e posteriormente a implementação da mudança (Sommerville, 2011). Cada um dos requisitos mantem relações com outros requisitos e/ou com o sistema. Estas relações são documentadas e deve ser definida uma política de atualização do registo, de modo a facilitar o processamento da informação. 36 As ferramentas de apoio são uma mais-valia, pois auxiliam no armazenamento de requisitos, na gestão da mudança e na gestão da rastreabilidade. Estas podem ser uma base de dados simples ou um sistema especializado para gestão de requisitos. Pequenos projetos podem recorrer a ferramentas simples (Sommerville, 2011). Controlar as mudanças, gerir as configurações, rastrear os requisitos e gerir a qualidade dos requisitos é uma outra forma de gestão dos requisitos. Aqui avaliam-se as possíveis alterações, o seu impacto e definem-se critérios de viabilidade a aplicar às mudanças para que a integridade do software não seja afetada. Os requisitos são acompanhados até ao fim e deve-se garantir que são corretos, completos, verificáveis e consistentes (Salles, 2012). Qualidade em Projetos e na Gestão de Projetos “ Quality can be viewed as exception, as perfection, as fitness for purpose, as value for money and as transformative”, traduzindo, qualidade por ser vista como uma exceção, como uma perfeição, como adequação ao objetivo, como valor monetário ou como capacidade de transformação (Harvey & Green, 1993, p. 1). Esta secção aborda a qualidade na gestão de projetos, a gestão da qualidade em projetos e a gestão da qualidade em ambiente scrum. A qualidade em projetos Em projetos, a qualidade de um resultado ou desempenho, define-se como o grau de atendimento dos requisitos de um conjunto de características inerentes definidas pelos stakeholders (PMI, 2017a). Em scrum, qualidade define-se como a capacidade que os produtos ou entregas concluídas têm em atender os critérios de aceitação e de alcançar o valor de negócio esperado pelo cliente (SBOK, 2017). Prevenção e inspeção são duas palavras muito comuns em qualidade. A prevenção consiste em eliminar os erros do processo, a inspeção consiste em eliminar os erros no cliente, pelo que prevenção é preferida à inspeção. Os custos de prevenção, na maioria dos casos, são inferiores aos custos de correção, pois a inspeção pode levar a retrabalho, aumento dos custos, insatisfação dos clientes, redução dos lucros e/ou erros (PMI, 2017a). Os custos da qualidade abrangem todos os custos incorridos durante a vida útil do produto e dividem-se em dois tipos, custos de falha internos e custos de falha externos. Os custos de falha internos 37 são encontrados pela equipa do projeto e os custos de falha externos são encontrados pelo cliente (PMI, 2017a). Num produto de software, um defeito é um requisito não atendido. Um software de má qualidade apresenta muitos requisitos não atendidos. Má qualidade pode ser execução errada sob determinadas condições, “bugs”, desempenho insuficiente ou dificuldade de utilização (Paula Filho, 2000). Gestão da qualidade em projetos A gestão da qualidade de um projeto trata da qualidade da gestão do projeto e da qualidade das entregas do projeto, independentemente da sua natureza. As medidas de qualidade diferem de acordo com os projetos, pois estão diretamente relacionadas com os produtos produzidos. As diferentes formas de gestão da qualidade são (PMI, 2017a): • Normal: o cliente encontra os defeitos, pode causar problemas de garantia, reputação e custos de retrabalho; • Detetar e Corrigir: os defeitos são detetados e corrigidos antes de serem realizados os envios das entregas. Esta tarefa incorpora-se no processo de controlo da qualidade; • Garantia da Qualidade: análise e correção dos defeitos no processo e não apenas defeitos no produto; • Incorporar a qualidade: este processo consiste na incorporação da qualidade aquando do planeamento e design do projeto e produto; • Organização comprometida com a qualidade: a cultura organizacional deve ser de qualidade nos processos e produtos. A “garantia da qualidade” e o “controlo da qualidade” são termos da indústria de manufatura. Em desenvolvimento de software apenas se utiliza o termo “garantia da qualidade”, tendo este duas vertentes: a garantia da qualidade como reforço da qualidade, através da definição de procedimentos, processos e padrões; e a garantia da qualidade como gestão de configurações, atividades de verificação e validação, após entrega do produto desenvolvido (Sommerville, 2011). A qualidade inicia-se nos requisitos e âmbito de um projeto. Deve-se ter em conta se o projeto atende as necessidades, se estão reunidas as condições para atender as necessidades identificadas e a forma de avaliação da qualidade (SBOK, 2017; Sommerville, 2011). Para melhorar a qualidade, minimizar as variações e obter resultados e produtos que vão ao encontro dos requisitos definidos pelos stakeholders, uma cultura de qualidade e comprometimento de todos para com o alcance de alta qualidade é essencial (SBOK, 2017). No entanto também é necessário 38 ter em consideração a satisfação do cliente, a melhoria contínua, a responsabilidade da administração e a parceria com os fornecedores (PMI, 2017a). • Satisfação do cliente - é importante compreender, avaliar, definir e gerir os requisitos de forma a garantir que as expectativas dos clientes são atendidas. Para tal é necessário conformidade com os requisitos e adequação ao uso, isto é, o projeto deve produzir aquilo para o qual foi criado, deve satisfazer necessidades reais (PMI, 2017a). • Melhoria contínua - planear-fazer-verificar-agir, o ciclo PDCA, é a base da melhoria da qualidade (PMI, 2017a). • Responsabilidade da administração - a administração tem um grande impacto no sucesso de um projeto. Deve garantir a responsabilidade com a qualidade, mas também responsabilidade de fornecimento dos recursos adequados com capacidades adequadas (PMI, 2017a). • Parceria mutuamente benéfica com fornecedores - a relação entre uma organização e os seus fornecedores é de interdependência. As relações baseadas em parceria e cooperação é mais benéfica quando comparada com a gestão tradicional de fornecedores (PMI, 2017a). Gestão da qualidade em scrum Com vista à melhoria da qualidade em scrum, são realizadas, aquando da entrega de incrementos nos sprints , retrospetivas para verificar a eficácia dos processos de qualidade e, em caso de identificação de problemas, procura-se a causa raiz e são sugeridas e testadas novas abordagens para melhoria da qualidade (PMI, 2017a; SBOK, 2017). Padrões e processos são importantes, mas existem outros aspetos intangíveis, como a elegância e a legibilidade (Sommerville, 2011). A partir dos requisitos, o product owner desenvolve critérios de aceitação. Uma boa definição dos critérios de aceitação é fundamental para a entrega das funcionalidades eficaz e dentro do prazo, garantindo assim o sucesso do projeto (SBOK, 2017). Em software não se aplicam as tolerâncias, pois os requisitos são incompletos e abstratos, stakeholders excluídos podem determinar um sistema de baixa qualidade e algumas especificações são ambíguas, pelo que a avaliação é realizada tendo em conta algumas características do sistema, respondendo às seguintes perguntas: As normas foram seguidas? O software foi testado corretamente? O software é confiável? O software tem um desempenho aceitável? O software está bem estruturado? (Sommerville, 2011). A gestão da qualidade em scrum divide-se em 3 fases, Figura 9 (SBOK, 2017): 39 Figura 9: Gestão da qualidade em scrum (SBOK, 2017) • Planeamento da qualidade - o desenvolvimento, em primeiro lugar, da funcionalidade de maior prioridade para o cliente é um dos princípios orientadores do scrum . Ao trabalho classificado como de menor prioridade, omisso ou incompleto dá-se o nome de dívida técnica, mas não deve ser transferida para outro sprint , pois a entrega do incremento deve cumprir os critérios de aceitação. Uma das máximas é a integração contínua e o ritmo sustentável. Aumenta a precisão das previsões, a satisfação dos colaboradores e do cliente (SBOK, 2017). • Controlo e garantia da qualidade - o controlo consiste na execução do plano de qualidade e das atividades de qualidades descritas no mesmo, incluindo a análise e identificação contínua de potenciais melhorias, através da discussão das lições aprendidas. Ao longo do desenvolvimento do projeto, o product owner avalia e controla as atividades de garantia da qualidade, de modo a verificar se os padrões estabelecidos são cumpridos pela equipa e os defeitos são corrigidos no sprint seguinte (SBOK, 2017). • Ciclo PDCA - o ciclo PDCA, Figura 10, em português, Planear-Fazer-Verificar-Agir, foi desenvolvido por Deming. Deming acreditava que a gestão das linhas orientadoras define a qualidade. Um produto irá sair com uma qualidade superior se houver motivação dos colaboradores e se a administração proporcionar um ambiente propício, ambiente este onde cada colaborador possa contribuir, de forma significativa, para a melhoria da qualidade (SBOK, 2017). Gestão da Qualidade em Scrum Planeamento da Qualidade Controlo e Garantia da Qualidade Ciclo PDCA •Criar backlog priorizado •Criar user story •Criar entregas •Conduzir a Reunião Diária •Validar sprint •Retrospetiva do sprint •Apresentação dos entregáveis •Retrospetiva do projeto Planear Executar Agir Verificar Figura 10: Ciclo PDCA Adaptado de SBOK (2017) 40 É sempre necessário ter em consideração que cada projeto é único e, portanto, o gestor de projetos deverá optar pelas práticas que melhor se adequam a um projeto em particular. As políticas, procedimentos, ferramentas, técnicas e modelos de qualidade existentes na organização devem ser tidos em conta, assim como as normas de qualidade específicas de cada indústria (PMI, 2017a). Stakeholders Stakeholder(s) é o termo utilizado para definir um indivíduo, um grupo de indivíduos, ou uma organização que pode afetar, ser afetado ou sentir-se afetado por um acontecimento num projeto. O acontecimento pode ser uma decisão, uma atividade ou um resultado de um projeto, programa ou portefólio (PMI, 2017a). Nesta secção é possível encontrar as funções e responsabilidades dos stakeholders e o processo de gestão dos stakeholders do projeto. Funções e responsabilidades dos stakeholders Todos os stakeholders podem contribuir para os requisitos, pressupostos ou restrições, pelo que a cada tarefa do projeto estará associada uma lista de stakeholders (IIBA, 2015). Quando se trata de uma equipa a trabalhar em scrum, estes podem interagir com a equipa e influenciar o projeto ao longo do seu desenvolvimento (SBOK, 2017). Existem várias classificações para os stakeholders, tendo em consideração diferentes características, como por exemplo: a sua relevância, poder, legitimidade e urgência (Mitchell et al., 1997). Ou as suas funções genéricas, sendo que um indivíduo pode representar mais do que uma função. Genericamente, são definidas as funções e respetivas responsabilidades apresentadas na Tabela 5 (IIBA, 2015). Tabela 5: Funções e responsabilidades genéricas dos stakeholders (IIBA, 2015) Funções Responsabilidades Analista do Negócio Indivíduo responsável por realizar a análise do negócio. Cliente Indivíduo(s) que utiliza ou pode utilizar o produto/serviço; possibilidade de imposição de direitos contratuais/morais. Expert da área Indivíduo que detém um conhecimento profundo relativamente a um tópico relevante do projeto. Consumidor Final Indivíduo(s) que interage com a solução diretamente Expert de Implementação Indivíduo que detém um conhecimento especializado da implementação de um ou mais componentes da solução. Operacional de suporte Indivíduo responsável pela gestão e manutenção diária de um sistema ou produto. 41 Funções Responsabilidades Gestor do Projeto Indivíduo responsável por gerir o trabalho necessário para o alcance dos objetivos do projeto, procurando sempre manter o equilíbrio do âmbito, orçamento, cronograma, recursos, qualidade e risco. Regulador Indivíduo que é responsável pela definição e aplicação de normas. As normas podem ser de legislação, de gestão organizacional, entre outras. Sponsor Indivíduo(s) que é responsável por autorizar a execução do trabalho. Competelhe iniciar o esforço para definir uma necessidade de negócio e para desenvolver uma solução que a satisfaça. Fornecedor Indivíduo(s) responsável por fornecer produtos/serviços, podendo ter direitos e obrigações contratuais/morais. Operacional de testes Indivíduo(s) que é responsável por verificar se a solução atende os requisitos definidos. Procura garantir que a solução segue as normas de qualidade definidas. O impacto e a capacidade de influenciar o trabalho ou os resultados de alguns stakeholders é limitado, enquanto outros podem ter um nível de influência significativo. Daí surge então a necessidade de uma boa gestão e uma boa estrutura de gestão dos mesmos. A capacidade de identificação, priorização e comprometimento correto dos stakeholders pode ser a chave para o sucesso do projeto. Então, devido à sua importância, este processo deve ser realizado o mais cedo possível após a aprovação do termo de abertura do projeto (PMI, 2017a). Gestão dos stakeholders do projeto A gestão dos stakeholders do projeto inclui o processo de identificação dos mesmos, analisar as suas expectativas o seu impacto no projeto e desenvolver estratégias de gestão apropriadas para envolver os stakeholders nas decisões e execução do projeto. Os processos auxiliam as equipas nestas tarefas (PMI, 2017a). É necessário ter sempre em consideração que cada projeto é único, pelo que os processos devem ser adaptados. Algumas das considerações são (PMI, 2017a): • A diversidade dos stakeholders: quantidade de stakeholders e a sua diversidade cultural; • A complexidade das relações dos stakeholders: como os stakeholders se relacionam e a complexidade das redes de informação e desinformação; • A tecnologia de informação: qual a melhor forma de comunicação. O processo de gestão dos stakeholders divide-se em 4 partes, Figura 11, sendo elas iterativas, ou seja, devem ser revistas e repetidas periodicamente, nomeadamente quando existe alguma mudança no projeto, mesmo que esta seja mínima, como a mudança de fase do ciclo de vida (PMI, 2017a). 48 O início de cada fase depende da conclusão da anterior, ou seja, as fases não se sobrepõem. Cada uma das fases dá origem a um ou mais documentos, que devem ser aprovados. Assim, as iterações entre fases são, por norma, sinónimo de custos acrescidos e retrabalho (Sommerville, 2011). Devido à sua inflexibilidade é difícil atender às alterações de requisitos dos clientes. Quando é encontrado um novo requisito ou um problema, a sua solução é ignorada ou adiada, levando a que, por vezes, o sistema não seja adequado para os utilizadores. Esta prática torna o modelo indicado apenas para projetos com requisitos bem definidos, bem compreendidos e com baixa probabilidade de alteração durante o desenvolvimento do produto (Sommerville, 2011). Modelos ágeis (scrum) As metodologias ágeis vêm em oposição às metodologias tradicionais consideradas pesadas. A publicação do artigo “ The New Product Development Game” em 1986, deu origem ao termo “scrum”. Esta metodologia deriva da transformação que surgiu nas organizações Norte Americanas e Japonesas da área de desenvolvimento de produtos. O artigo reporta a transição dos métodos sequenciais para as abordagens holísticas, ou seja, a migração para processos flexíveis com equipas autónomas e multidisciplinares (Takeuchi & Nonaka, 1986). Abordagem scrum As abordagens holísticas assemelham-se ao comportamento de uma equipa de rugby , onde a equipa é uma unidade integrada, onde todos os membros têm as regras bem definidas e a equipa se foca toda num único objetivo (Romano & Silva, 2015; SBOK, 2017). Assim, o scrum surge como uma forma mais rápida, eficaz e confiável para o desenvolvimento de software , apresentando-se como idêntico aos sistemas evolutivos, autocorretivos e adaptativos (Sutherland, 2014). Definição do scrum O scrum é uma framework onde as pessoas podem tratar problemas adaptativos complexos, enquanto entregam produtos, com o maior valor possível, de forma produtiva e criativa. Este é leve, fácil de entender mas difícil de dominar (Schwaber & Sutherland, 2017). Surge da análise da forma de trabalho das pessoas, da análise das melhores práticas de várias empresas do mundo e da análise das melhores equipas dessas empresas (Sutherland, 2014). A incerteza e a criatividade são duas integrantes do scrum , pelo que as equipas devem estar sempre preparadas para a mudança (Romano & Silva, 2015; Sutherland, 2014). O scrum promove a aprendizagem das equipas, estas devem avaliar o resultado do trabalho realizado até ao momento, e a 49 forma como este foi criado, para que através da análise da sua própria forma de trabalho, as equipas melhorem as suas ferramentas de auto-organização, aprimoramento da velocidade e qualidade do trabalho (Sutherland, 2014). O scrum segue algumas diretrizes fundamentais, sendo estas obrigatórias em todos os projetos. Os seis princípios fundamentais são (SBOK, 2017): controlo de processos empíricos; auto-organização; colaboração; priorização baseada em valor; “ time-boxing ”; desenvolvimento iterativo. Para além dos princípios, o scrum assenta em três teorias empíricas muito fortes, três pilares, que são a transparência, a inspeção e a adaptação (Schwaber & Sutherland, 2017). A transparência garante que os aspetos essenciais e relevantes do processo são visíveis para todos os responsáveis pelos resultados (Schwaber & Sutherland, 2017). Desta forma é criada uma cultura de trabalho aberta (SBOK, 2017). A inspeção é essencial. Os artefactos devem ser inspecionados pelos integrantes do projeto de modo a medir o progresso e detetar possíveis variâncias indesejadas. A periodicidade é definida de acordo com o ritmo do projeto, e não deve interferir no trabalho (Schwaber & Sutherland, 2017). A adaptação ocorre quando a equipa e os stakeholders adaptam o processo através de melhorias no trabalho devido à aprendizagem retirada da transparência e inspeção (SBOK, 2017). Com esta procura-se minimizar as variações (Schwaber & Sutherland, 2017). A inspeção e a adaptação são realizadas durante os eventos formais. Para que estes três pilares sejam respeitados e para que haja confiança entre os elementos das equipas, existem cinco valores fundamentais: compromisso; coragem; foco; abertura; e respeito. Sendo que o sucesso do scrum depende da aprendizagem e vivência desses valores (Schwaber & Sutherland, 2017). A equipa scrum A equipa scrum é constituída pelo Product Owner, pela Equipa de Desenvolvimento e pelo Scrum Master (Schwaber & Sutherland, 2017). O Product Owner é o elemento responsável por maximizar o valor do produto e do trabalho realizado pela equipa de desenvolvimento. É o único responsável pela gestão do backlog do produto. Apesar de ser uma pessoa singular, poderá representar um comitê; e para que este seja bem-sucedido, toda a organização deve respeitar as suas decisões (Schwaber & Sutherland, 2017). Representa a voz do cliente (SBOK, 2017). A Equipa de Desenvolvimento consiste no conjunto de profissionais responsáveis por realizar o trabalho e entregar o potencial incremento a cada sprint (Schwaber & Sutherland, 2017) . É responsável pela interpretação dos requisitos especificados e pelas entregas (SBOK, 2017). Ideologicamente não 50 existe um número exato de elementos constituintes desta equipa, porém, equipas com menos de três elementos resultam em ganhos menores de produtividade e com mais de nove requerem muita coordenação, pelo que se deve garantir que a equipa permaneça ágil e eficiente (Schwaber & Sutherland, 2017). O Scrum Master é responsável por promover e apoiar o scrum, deve ajudar todos a compreender a teoria, as práticas, as regras e os valores do scrum . Lidera as reuniões, mede empiricamente o progresso, e garante reuniões curtas e focadas. Preocupa-se com a redução do risco, resposta rápida e acompanhamento contínuo do backlog e das entregas (Romano & Silva, 2015). É ainda responsável por proporcionar um ambiente propício ao sucesso do projeto (SBOK, 2017). Este deve assegurar que o scrum é compreendido e que este é, de facto, posto em prática (Schwaber & Sutherland, 2017). Os eventos scrum Eventos pré-determinados são característicos do scrum , pois estes criam regularidade e minimizam a necessidade de reuniões de urgência. Os eventos são aqueles que asseguram a transparência e inspeção, pelo que a não inclusão de qualquer um dos seguintes eventos pode resultar na redução da transparência e é uma perda de oportunidade de inspeção e adaptação (Schwaber & Sutherland, 2017). Sprint O sprint define-se como o intervalo de tempo pré-determinado para a execução de cada iteração (Schwaber & Sutherland, 2017). Ou seja, durante este intervalo a equipa trabalha com o objetivo de transformar os requisitos em funcionalidades dos produtos passíveis de se entregar (SBOK, 2017). O intervalo de tempo tem até, no máximo, um mês de duração, começando um novo sprint imediatamente a seguir ao anterior (Schwaber & Sutherland, 2017). Ainda que se possa reduzir a funcionalidade entregue, a data de entrega não é alterável (Romano & Silva, 2015). O sprint integra: o planeamento do sprint; a reunião diária scrum; o trabalho de desenvolvimento; a reunião de revisão do sprint; e a reunião de retrospetiva do sprint (Schwaber & Sutherland, 2017). Se o objetivo do sprint se tiver tornado obsoleto, pode ser abandonado antes da conclusão do mesmo. No entanto apenas o product owner tem autoridade para tal (Schwaber & Sutherland, 2017). Reunião de planeamento do sprint - sprint planning A reunião de planeamento do sprint é realizada antes do sprint, onde se planeia o trabalho que irá ser realizado. O planeamento dá origem ao plano e é realizado colaborativamente por toda a equipa scrum (SBOK, 2017; Schwaber & Sutherland, 2017). Nesta reunião, a equipa define o objetivo do sprint, 51 a funcionalidade que será desenvolvida, qual o valor entregue e de que forma irá criar essa funcionalidade. O objetivo ajuda na coesão da equipa (Schwaber & Sutherland, 2017). Reunião diária scrum - daily scrum A reunião diária scrum tem a duração máxima de 15 minutos e reúne a equipa de desenvolvimento todos os dias, durante um sprint (Schwaber & Sutherland, 2017). A equipa de desenvolvimento tira proveito desta reunião para analisar o progresso ao longo do sprint , aumentando assim a probabilidade de atingir o objetivo do sprint e para planear o trabalho a ser realizado nas próximas 24 horas (Schwaber & Sutherland, 2017). O que eu fiz ontem que ajudou a equipa a atingir o objetivo do sprint? O que é que eu vou fazer hoje para ajudar a equipa a atingir o objetivo do sprint? Existe algo que impeça a equipa de atingir os objetivos do sprint? São perguntas exemplo que devem ser respondidas (Schwaber & Sutherland, 2017). Esta prática traz contribuições remotas, e faz com que os colaboradores se sintam parte da equipa, visíveis e necessários (Romano & Silva, 2015) Reunião de revisão do sprint - sprint review A reunião de revisão é realizada no fim de cada sprint para analisar o incremento entregue e, em caso de necessidade, adaptar o backlog do produto. Nesta estão presentes todos os elementos da equipa e os stakeholders (Schwaber & Sutherland, 2017) . É uma reunião informal onde a equipa apresenta ao product owner os resultados obtidos no sprint atual, para este rever e comparar o incremento com os critérios de aceitação previamente acordados (SBOK, 2017). Desta reunião resulta o backlog do produto revisto para o próximo sprint (Schwaber & Sutherland, 2017) . Reunião de retrospetiva do sprint - sprint retrospective A reunião de retrospetiva do sprint realiza-se após a reunião de revisão do sprint e antes da reunião de planeamento do próximo sprint (Schwaber & Sutherland, 2017). Esta reunião apresenta-se como uma oportunidade para a equipa scrum inspecionar a relação da equipa, os processos e as ferramentas, identificando e ordenando os principais aspetos positivos e possíveis melhorias e, após esta análise, criarem um plano de melhoria (Schwaber & Sutherland, 2017). Artefactos do scrum Os artefactos do scrum têm como objetivo maximizar a transparência das informações principais, com o intuito de um entendimento igual por todos. Estes artefactos são: o backlog do produto, o backlog do sprint e o incremento (Schwaber & Sutherland, 2017). 52 Backlog do produto O backlog do produto é a única fonte de requisitos, apresenta todas as informações necessárias sobre o produto de forma ordenada. Contém as características, as funções e os requisitos, e também as melhorias e correções que constituem as alterações a serem realizadas no produto. As melhorias e correções decorrem do desenvolvimento do produto, de acordo com o ambiente em que se insere, da criação de valor e do feedback do mercado. Assim, o backlog é dinâmico e constantemente alterado (Schwaber & Sutherland, 2017). Este artefacto é da responsabilidade do product owner mas a equipa de desenvolvimento também colabora no refinamento do backlog (Schwaber & Sutherland, 2017). Backlog do sprint Este artefacto representa o conjunto de itens selecionados do backlog do produto para um sprint específico, constituído por um plano de entrega do incremento e um plano para atingir a meta do sprint. É uma previsão do que será entregue e qual o trabalho necessário para o alcançar, é uma representação em tempo real do trabalho a ser realizado durante o sprint , e da responsabilidade da equipa de desenvolvimento (Schwaber & Sutherland, 2017). Com vista à melhoria contínua, o backlog do sprint, deve incluir, no mínimo, uma melhoria no processo. Surge durante o sprint , pois à medida que o trabalho é executado e o produto desenvolvido, o trabalho restante é estimado e atualizado (Schwaber & Sutherland, 2017). Incremento O incremento resulta da soma de todos os itens do backlog do produto concluídos num sprint e o valor dos incrementos de todos os sprints realizados até à data. É um passo dado em direção a uma visão ou um objetivo (Schwaber & Sutherland, 2017). O ciclo, Figura 13, é iniciado por uma reunião com os stakeholders , da qual se obtém a visão do projeto. De seguida é desenvolvida, pelo product owner , uma lista de requisitos e realizada a sua priorização, obtendo o backlog priorizado do produto. Os sprints são a fase seguinte do fluxo. Iniciam-se com uma reunião de planeamento do sprint . Após esta, começa o desenvolvimento prático, acompanhado por reuniões diárias, sendo os entregáveis apresentados nas reuniões de planeamento do sprint. Um sprint é dado como terminado após a reunião de retrospetiva do sprint (SBOK, 2017). 53 Figura 13: Fluxo do scrum para o sprint (SBOK, 2017) Em suma, o scrum “é uma metodologia de adaptação, iteratividade, rapidez, flexibilidade e eficiência, projetada para fornecer um valor significativo, de forma rápida, durante todo o projeto. O scrum garante a transparência na comunicação e cria um ambiente de responsabilidade coletiva e progresso contínuo” (SBOK, 2017, p. 2). Utiliza equipas multifuncionais e autónomas que organizam e dividem o trabalho de forma a realizarem ciclos curtos e concentrados (sprints) (SBOK, 2017). Priorização baseada em valor A priorização dos requisitos permite localizar temporalmente a ordem de realização das tarefas. No scrum esta é realizada pelo product owner aquando da realização do backlog priorizado do produto (lista de requisitos priorizados, necessários para o desenvolvimento do projeto) (SBOK, 2017). A priorização baseada em valor é considerada como um princípio fundamental de impulsionamento da estrutura do scrum , uma vez que auxilia os projetos devido à sua adaptabilidade e desenvolvimento iterativo. Estas características vão ao encontro do objetivo do scrum de entrega de valor máximo possível ao fim de cada uma das fases do projeto (SBOK, 2017). O product owner de forma a listar os requisitos que trazem um valor de negócio maior, deverá recolher os requisitos junto do cliente e analisá-los com ele e com o patrocinador. Assim, o product owner, após o entendimento dos requisitos e dos valores que o cliente solicita, deve organizar os itens do backlog do produto de acordo com a importância relativa. Os requisitos de valor mais alto são identificados e deslocados para o cimo do backlog priorizado do produto (SBOK, 2017). O risco e a incerteza devem ser tomados em conta aquando da priorização, pois daí podem ocorrer consequências negativas. Esta análise deve ser realizada em conjunto pelo product owner com 54 a equipa scrum . Assim como o risco e incerteza, é necessário ter em consideração as eventuais dependências de implementação (SBOK, 2017). A definição do valor de negócio pode ser projetada através de uma estimativa subjetiva, através da rentabilidade ou através de resultados e análises de mercado. As análises de mercado poderão ser realizadas através de várias ferramentas, tais como: entrevistas com clientes, pesquisas, modelos financeiros e técnicas de análise (SBOK, 2017). Em suma, aquando da priorização dos requisitos, devem ser tidos em conta três fatores: valor; risco ou incerteza; e dependências, Figura 14 (SBOK, 2017). Figura 14: Priorização baseada em valor (SBOK,2017) Risco define-se como um evento, ou conjunto de eventos incertos que apresentam probabilidade de ter impacto (positivo ou negativo) nos objetivos de um projeto, podendo então auxiliar o sucesso do projeto ou desencadear o fracasso do mesmo. Quando o impacto no projeto é positivo designa-se como oportunidade, quando é negativo designa-se como ameaça (SBOK, 2017). A gestão dos riscos deve ser proactiva, é um processo iterativo, que se inicia em simultâneo com o projeto e acompanha-o ao longo de todo o ciclo de vida. Esta deve seguir uma norma, os riscos devem ser identificados e avaliados, posteriormente é definido e acionado um plano de ação apropriado (SBOK, 2017). Modelos híbridos Numa pesquisa realizada com 800 participantes evidenciou-se que a adoção do modelo ágil está associada à intenção de melhoria da eficiência e eficácia no mercado e inovações tecnológicas. No entanto, apesar das instituições se considerarem como utilizadores de modelos ágeis, estas recorrem também a práticas tradicionais (planeamento, controlo de riscos e de processos) e, em conjunto, o mix de práticas (modelos híbridos) utilizado leva aos resultados pretendidos (Conforto et al., 2015). Híbrido define-se como “o que tem elementos diferentes na sua composição”. Na gestão de projetos, modelo híbrido pode definir-se como “...a combinação de princípios, práticas, técnicas e 55 ferramentas de diferentes abordagens em um processo sistemático que visa adequar a gestão ao contexto do negócio e tipo específico de projeto. Tem como objetivo maximizar o desempenho do projeto e produto, proporcionar um equilíbrio entre previsibilidade e flexibilidade, reduzir os riscos e aumentar a inovação, para entregar melhores resultados de negócio e valor agregado ao cliente” (Conforto et al., 2015, p. 12). Os modelos híbridos procuram enfrentar os cenários dinâmicos do quotidiano (Silva & Melo, 2016). Não existe um conjunto de práticas “silver bullet”. O modelo híbrido deve ser construído especificamente para cada projeto, equipa e instituição, de modo obter um modelo robusto, eficiente, que permita atingir os objetivos do projeto (Conforto et al., 2015). Estes modelos têm-se mostrado eficazes, nomeadamente em cenários dinâmicos e flexíveis, como por exemplo no setor de TI. No entanto, é necessário analisar de forma crítica o momento em que cada uma das práticas deve ser aplicada. O equilíbrio entre as duas é da responsabilidade do líder do projeto, assim como adaptações necessárias ao longo do projeto. O modelo deve estar alinhado com a realidade das pessoas, cenários e objetivos (Silva & Melo, 2016). Para o desenvolvimento da plataforma a equipa seguiu um modelo híbrido. Este modelo foi prédefinido pelos docentes da Unidade Curricular - UC onde se integra este projeto. As práticas do modelo tradicional foram aplicadas na iniciação, planeamento e conclusão. Na fase de desenvolvimento foi utilizada a metodologia scrum . 56 3. DEFINIÇÃO DA PLATAFORMA Neste capítulo apresenta-se a definição da plataforma pela perspetiva do product owner , o trabalho desenvolvido pelo mesmo, antes e durante o contacto com a equipa de desenvolvimento. Para a definição da plataforma foi desenvolvido trabalho referente aos stakeholders, aos requisitos, à qualidade e ao risco. Stakeholders Os stakeholders da plataforma HELP PME PROJECTS, Figura 15, são as entidades mais importantes para o seu desenvolvimento, uma vez que podem afetar ou ser afetados por um acontecimento no projeto. Stakeholders PME Estudantes Docentes Intestigadores Profissionais da área Equipa scrum Orientadores Organizações de apoio à GP Outros stakeholders Figura 15: Stakeholders da plataforma HELP PME PROJECTS 57 Equipa scrum A equipa scrum é um dos principais stakeholders do desenvolvimento desta plataforma uma vez que é um dos principais interessados no seu desenvolvimento. Nesta dissertação a equipa scrum é constituída pela investigadora, que assumiu o papel de product owner, e por um grupo de alunos do curso de MIEGSI, que assumiu o papel de equipa de desenvolvimento, sendo um deles scrum master. PME As PME são o público-alvo da plataforma. Estas gerem projetos no seu dia-a-dia, ainda que por vezes de forma inconsciente. O interesse das PME na plataforma passa pela melhoria ou implementação da GP internamente através da informação de GP disponibilizada, pela possibilidade de interação e esclarecimento com profissionais da área e pelo acesso a informação sobre eventos a realizar da área. Organizações de apoio à GP As organizações de apoio à GP terão espaço para anunciar na plataforma o seu calendário de eventos, os trabalhos, standards , certificações, entre outras. O seu interesse passa pela divulgação da organização e do trabalho realizado. Profissionais da área Os profissionais da área pertencem ao público-alvo. O interesse destes prende-se maioritariamente com a possibilidade de interação e esclarecimento com outros profissionais e o acesso à informação relativa aos eventos calendarizados. Estudantes Os estudantes fazem também parte do público-alvo. Estes procuram informações, esclarecimento de dúvidas e também formas de aprimoramento do seu conhecimento na área. Investigadores, docentes e outros stakeholders Os investigadores, docentes e outros stakeholders são entidades que poderão também apresentar algum interesse na plataforma, no entanto assumiu-se como de menor importância para o desenvolvimento da mesma. Orientadores O interesse dos orientadores prende-se com o acompanhamento dos alunos ao longo do desenvolvimento da plataforma. 64 qual o tipo de requisito, se este é funcional (serviço que deve ser fornecido pelo sistema) ou se é um requisito não funcional (restrição ou função). O autor é um atributo importante pois diz-nos quem é o responsável pelo requisito, aquele que o definiu e que deve ser consultado em caso de necessidade. O ownership é aquele para o qual o requisito foi definido, é um atributo importante para ter em consideração aquando da necessidade mudanças. A prioridade do requisito é um atributo muito importante especialmente para a organização do trabalho a realizar pela equipa de desenvolvimento e o estado permite ter uma visão geral do desenvolvimento do projeto. Tabela 8: Matriz de rastreabilidade inicial Nº Classificação Autor Ownership Prioridade Estado R1 Não Funcional P. Owner P. Owner 5 Aceite R2 Não Funcional P. Owner P. Owner 5 Aceite R3 Não Funcional P. Owner P. Owner 5 Aceite R4 Não Funcional P. Owner P. Owner 3 Proposto R5 Não Funcional P. Owner Utilizadores 4 Aceite R6 Não Funcional P. Owner Utilizadores 4 Aceite R7 Não Funcional P. Owner P. Owner 5 Aceite R8 Não Funcional P. Owner P. Owner 5 Aceite R9 Não Funcional P. Owner P. Owner 5 Aceite R10 Funcional P. Owner Utilizadores 4 Aceite R11 Funcional P. Owner Utilizadores 4 Aceite R12 Não Funcional P. Owner P. Owner 5 Aceite R13 Não Funcional P. Owner P. Owner 5 Aceite R14 Funcional P. Owner Utilizadores 5 Aceite R15 Não Funcional P. Owner P. Owner 5 Aceite R16 Funcional P. Owner Utilizadores 4 Aceite R17 Funcional P. Owner Utilizadores 2 Aceite R18 Funcional Orientador Utilizadores 2 Proposto R19 Funcional P. Owner Utilizadores 3 Aceite R20 Funcional P. Owner Utilizadores 4 Aceite R21 Funcional P. Owner Utilizadores 4 Aceite R22 Funcional Orientador Utilizadores 2 Aceite R23 Funcional Orientador Utilizadores 2 Proposto R24 Funcional Orientador Utilizadores 2 Proposto R25 Funcional P. Owner Utilizadores 5 Aceite R26 Funcional P. Owner Utilizadores 2 Proposto R27 Funcional P. Owner Utilizadores 1 Proposto R28 Funcional P. Owner Utilizadores 5 Aceite Tabela 9: Matriz de rastreabilidade dos requisitos identificados ao longo do desenvolvimento da plataforma Nº Classificação Autor Ownership Prioridade Estado R29 Funcional E. Desenv. Utilizadores 2 Proposto R30 Não Funcional P. Owner Utilizadores 5 Aceite 65 Nº Classificação Autor Ownership Prioridade Estado R31 Funcional P. Owner Utilizadores 2 Proposto R32 Funcional P. Owner Utilizadores 4 Proposto R33 Funcional P. Owner Utilizadores 4 Proposto R34 Funcional P. Owner Utilizadores 4 Aceite R35 Funcional E. Desenv. Utilizadores 4 Aceite R36 Funcional P. Owner Utilizadores 5 Aceite R37 Funcional P. Owner Utilizadores 5 Aceite Os atributos complexidade, os riscos, a fonte, a estabilidade, a urgência e as dependências foram retirados pois nesta investigação apenas é considerada a perspetiva do product owner e os atributos complexidade e dependências relacionam-se com a avaliação e análise da equipa de desenvolvimento. Os riscos foram tratados para o projeto como um todo e não para cada um dos requisitos em particular, devido à já falada pequena dimensão do projeto. A fonte e o autor são por norma diferentes, no entanto, aqui, devido ao papel do product owner de representante de todos os stakeholders , não existe distinção entre estes dois atributos. A pequena dimensão do projeto não justifica a utilização da variável estabilidade. A urgência apenas é especificada quando existem deadlines de implementação, neste caso, apenas existe deadline de entrega da plataforma e não para cada um dos requisitos em particular, pelo que a urgência também foi um atributo retirado. Os requisitos apresentados não integram os requisitos técnicos apresentados pela equipa de desenvolvimento. Priorização dos requisitos A priorização dos requisitos indica a importância relativa dos requisitos (IIBA, 2015). Para a priorização dos requisitos em scrum considera-se o valor, o risco e a dependência. No entanto, como se trata da ótica product owner, apenas se considera a priorização. Como referido anteriormente, o risco não foi identificado nem gerido para cada um dos requisitos em particular, pelo que não será englobado no processo de priorização. Devido à sua simplicidade foi selecionado o método de priorização de atribuição numérica (Tabela 10, Tabela 11). A importância de cada um dos requisitos será avaliada através de uma escala de 1 (um) a 5 (cinco): • 1 – Nada Importante • 2 – Pouco Importante • 3 – Neutro • 4 – Importante • 5 – Muito Importante 66 Tabela 10: Priorização dos requisitos iniciais pelo método de atribuição numérica Grau de Importância Requisitos 1 2 3 4 5 R1 x R2 x R3 x R4 x R5 x R6 x R7 x R8 x R9 x R10 x R11 x R12 x R13 x R14 x R15 x R16 x R17 x R18 x R19 x R20 x R21 x R22 x R23 x R24 x R25 x R26 x R27 x R28 x Tabela 11: Priorização dos requisitos identificados ao longo do desenvolvimento da plataforma pelo método de atribuição numérica Grau de Importância Requisitos 1 2 3 4 5 R29 x R30 x R31 x R32 x R33 x R34 x R35 x R36 x R37 x 67 Qualidade da Plataforma Qualidade para este projeto define-se como o atendimento dos requisitos apresentados à equipa de desenvolvimento. Assim, tendo em consideração a revisão da literatura, a qualidade será avaliada de acordo com os requisitos atendidos, a sua execução, os “bugs”, o desempenho e a facilidade de utilização. Um reduzido número de requisitos não atendidos são considerados defeitos. A garantia da qualidade será realizada através de um conjunto de medidas de modo a garantir que as necessidades do projeto são satisfeitas e que se procura colaborar no sentido da melhoria contínua. Para tal será realizado o acompanhamento da equipa ao longo do desenvolvimento do projeto por parte do product owner , que terá lugar nas reuniões de planeamento do sprint , onde será revisto o trabalho realizado até ao momento e também avaliadas as mudanças e a aprovação de novos requisitos. Aqui serão aplicadas as questões sugeridas por Sommerville (2011): As normas foram seguidas? O software foi testado corretamente? O software é confiável? O software tem um desempenho aceitável? O software está bem estruturado? Risco A incerteza nos projetos de software é alta pelo que a gestão dos riscos é essencial. O risco foi tratado pelo product owner para o projeto em geral e procura reunir toda a incerteza do projeto para que não se seja surpreendido e dessa forma garantir o sucesso do projeto. Tendo em consideração que a metodologia utilizada para a fase desenvolvimento da plataforma é o scrum, e que este projeto consiste no desenvolvimento de software , para a gestão do risco será seguido o processo de quatro etapas sugerido por Sommerville (2011). Existem várias técnicas que podem ser utilizadas para a identificação do risco, tais como: brainstorming , entrevistas, análise causa-raiz, listas de verificação, análise de documentos e análise SWOT – Strenghts (pontos fortes), Weaknesses (pontos fracos), Opportunities (oportunidades) e Threats (ameaças). A identificação dos riscos foi realizada através de uma lista de requisitos. De seguida procedeuse à análise e impacto de ocorrência dos riscos, bem como a estratégia de mitigação dos mesmos, Tabela 12. 68 Tabela 12: Identificação, avaliação e estratégia de mitigação dos riscos Riscos Impacto Probabilidade Estratégia de Mitigação Má definição dos requisitos 8 4 Revisão dos requisitos, análise dos requisitos junto dos orientadores da dissertação. Má compreensão dos requisitos / Falha na comunicação 8 5 Preparação antecipada de reuniões, e utilização da técnica de feedback para garantir a compreensão dos requisitos por parte da equipa. Falta de comprometimento da equipa de desenvolvimento 10 1 Contacto constante com a equipa e demonstração de confiança na mesma de modo a aumentar o envolvimento dos elementos no projeto. Má relação entre equipa e product owner 9 2 Promoção de um ambiente propício à entreajuda e de respeito entre as partes. Promoção da aceitação social. Parceria com APOGEP 6 5 Contacto antecipado e atempado com elementos responsáveis de modo a garantir uma parceria. Burocracia 10 3 Comunicação antecipada com os serviços da universidade para disponibilização de servidor e domínio. 69 4. DESENVOLVIMENTO DA PLATAFORMA HELP PME PROJECTS: AS PRÁTICAS DE GESTÃO DE PROJETOS DA EQUIPA Neste capítulo serão descritas as práticas de gestão dos projetos da equipa de desenvolvimento desta plataforma. A metodologia scrum foi a escolhida para o desenvolvimento do projeto, no entanto tendo em consideração que se trata de um modelo híbrido, na fase de planeamento e gestão do projeto foi adotada uma metodologia tradicional, o modelo em cascata. Esta descrição será realizada pela perspetiva do product owner, e divide-se em 4 partes: o modelo híbrido, equipa, planeamento do projeto e desenvolvimento do projeto. O Modelo Híbrido de Gestão de Projetos O modelo híbrido de gestão adotado para este projeto encontra-se representado na Figura 19. A metodologia tradicional foi aplicada na iniciação, no planeamento e na conclusão, e a metodologia scrum na fase de desenvolvimento. Figura 19: Modelo híbrido utilizado para este projeto Elaborado pela autora Ao longo das próximas secções será explorado de forma detalhada a forma como este modelo foi aplicado, bem como práticas de cada uma das metodologias a que a equipa recorreu. A Equipa A equipa scrum desta plataforma divide-se em Equipa de Desenvolvimento, Scrum Master e Product Owner. O papel de equipa de desenvolvimento e de scrum master é assumido por um grupo de 70 alunos integrantes do MIEGSI, da Universidade do Minho. O papel de product owner é assumido pela investigadora. A equipa de desenvolvimento é composta por 6 elementos. Foi-lhes proposto o desenvolvimento da plataforma HELP PME PROJECTS, no âmbito da UC Projetos e Tecnologias de Sistemas de Informação - PTSI, integrante do plano de estudos do quarto ano do mestrado integrado que frequentam. A escolha dos elementos da equipa foi realizada pelos próprios, sendo que inicialmente, esta seria constituída apenas por 5 elementos, no entanto, após a iniciação do projeto, devido à impossibilidade de realização do programa ERASMUS, foi adicionado o sexto elemento ao grupo. A eleição do scrum master ficou a cargo da equipa, sendo este o porta-voz, responsável pelo contacto com o product owner e pela coordenação da equipa de desenvolvimento, com o objetivo de alcançar uma gestão eficaz dos recursos. Este papel não foi atribuído a um único indivíduo, tendo sido desempenhado por todos eles. Internamente a equipa definiu uma frequência de reunião semanal, para coordenação do trabalho em desenvolvimento no sprint . A reunião de planeamento do sprint com o product owner foi definida com frequência quinzenal. Planeamento do Projeto: descrição do trabalho realizado pela equipa O planeamento do projeto iniciou-se com a primeira reunião com o product owner. Após a reunião, a equipa procedeu à elaboração do project charter (Anexo I – Project Charter ), que consiste num documento que formaliza a autorização para a existência de um projeto. Os objetivos e os deliverables da equipa prendem-se essencialmente com o processo de desenvolvimento da plataforma e atendimento dos requisitos solicitados. Assim, para este projeto, a equipa tinha como objetivos: recolher os requisitos da plataforma web; idealizar e desenvolver uma plataforma intuitiva, completa e atrativa para as PME que procuram ajuda no âmbito da gestão de projetos; testar, documentar e implementar a plataforma web. Os principais deliverables consistem num protótipo funcional da plataforma web, base de dados da plataforma, manual do utilizador e implementação da plataforma no servidor. O project charter desenvolvido divide-se em 15 secções: resumo executivo, enquadramento, finalidade, objetivo , deliverables , requisitos, stakeholders , timelines e milestone, recursos e orçamento, restrições, pressupostos, lista de riscos, e por fim, fatores e critérios de sucesso. 71 Stakeholders Uma boa gestão dos stakeholders é essencial para o sucesso do projeto. Nesse sentido, na fase de planeamento da gestão dos stakeholders, a equipa começou pela identificação destes e atribuição das respetivas funções. Os docentes da UC, os clientes e a equipa apresentam-se como os stakeholders identificados. Após o processo de identificação dos stakeholders e respetivas funções, foi construída uma matriz de stakeholders (Anexo II – Matriz de Stakeholders ), de dupla entrada, que relaciona o poder de cada um dos stakeholders com o nível de suporte que este apresenta para o projeto. O poder dos stakeholders divide-se em Alto, Médio e Baixo, e o nível de suporte ao projeto divide-se em Oposição, Indiferença e Suporte. Através desta matriz desencadeou-se a definição da estratégia de gestão dos stakeholders (Anexo III - Estratégia de Gestão dos Stakeholders ). O feedback ao longo do desenvolvimento do projeto, o contacto direto e constante e o interesse dos stakeholders no projeto, especialmente o cliente, foi considerado pela equipa como essencial. Na matriz de registo dos stakeholders foram definidos os interesses e o impacto no projeto de cada um e, de acordo com essas variantes, elaboraram as estratégias para obter um maior nível de suporte e uma redução da oposição. De modo a gerir de melhor forma a interação dos stakeholders no projeto, a matriz de perspetiva temporal foi a ferramenta utilizada pela equipa (Anexo IV – Matriz de Perspetiva Temporal dos Stakeholders Anexo IV – Matriz de Perspetiva Temporal dos Stakeholders ). Nesta, uma vez que divide o cronograma do projeto em semanas, e identifica em que semanas cada um dos stakeholders vai interagir no projeto, é evidenciado, de forma mais clara, o impacto de cada um, bem como a sua importância para o mesmo. Assim, espera-se que os stakeholders mais presentes sejam aqueles com maior importância e impacto para o projeto. Por fim, a equipa recorreu a uma matriz de dupla entrada onde se cruzam as diferentes fases do projeto com os diferentes stakeholders, obtendo assim uma perspetiva Work-Package (Anexo V – Stakeholders vs Work Package Anexo V – Stakeholders vs Work Package ). O projeto foi dividido em 4 fases: Iniciação; Planeamento; Desenvolvimento; e Conclusão. Esta matriz permite que a equipa perceba em qual destas fases irão estar presentes cada um dos stakeholders identificados. Cronograma Este projeto enquadra-se dentro de uma UC pelo que o cronograma é restritivo, pré-definido e a equipa não é 100% dedicada, exigindo que este seja bem planeado, definido e organizado. 72 A equipa começou pela elaboração de uma lista de atividades a realizar. As principais atividades definidas foram: Iniciação do Projeto; Criação do Project Charter ; Planeamento do Projeto; Desenvolvimento do Projeto; e Conclusão do Projeto. Cada uma das atividades principais divide-se em tarefas que permitem uma análise mais detalhada do trabalho a realizar. A equipa, após enumeração das tarefas necessárias para a satisfação dos requisitos, procedeu à organização das mesmas, distribuindo-as pelos sprints. Para controlar a atividade do projeto a equipa recorreu ao Microsoft Project . O Diagrama de Gantt foi a ferramenta escolhida para a representação do fluxo de trabalho, da duração, deadlines das tarefas , timelines e milestones . O diagrama permite ainda evidenciar as dependências entre as tarefas (Anexo VI – Cronograma). No que se refere ao cálculo das estimativas, a equipa teve por base a sua própria experiência. O cálculo das reservas realizou-se através do cálculo PERT, tendo em consideração 3 variáveis: Estimativa Otimista, Estimativa Pessimista e Estimativa Provável. A Estimativa Otimista representa o cenário onde se espera que as tarefas sejam concluídas antes do tempo previsto. A redução de tempo para conclusão do projeto considerada foi de 15%. A Estimativa Pessimista representa o cenário onde se espera que as tarefas não sejam concluídas no tempo previsto, levando a uma extensão do tempo do projeto. A adição de tempo para conclusão do projeto considerada foi de 35%. A Estimativa Provável representa o cenário em que as previsões se verificam, ou seja, a conclusão do projeto acontece no tempo previsto. O provável é o tempo representado no diagrama de Gantt . A fórmula utilizada no cálculo de PERT foi: 𝑃𝐸𝑅𝑇 = 𝑝𝑒𝑠𝑠𝑖𝑚𝑖𝑠𝑡𝑎 + 4 ∗ 𝑝𝑟𝑜𝑣á𝑣𝑒𝑙 + 𝑜𝑡𝑖𝑚𝑖𝑠𝑡𝑎 6 e para o cálculo de reservas: 𝑅𝑒𝑠𝑒𝑟𝑣𝑎𝑠 = 𝑃𝐸𝑅𝑇 − 𝑝𝑟𝑜𝑣á𝑣𝑒𝑙 O caminho crítico (Anexo VII – Caminho Crítico) corresponde ao conjunto de tarefas que, em caso de verificação da perspetiva pessimista, irão desencadear o atraso no projeto, que se reflete na data de conclusão do mesmo. Neste sentido, para procurar evitar atrasos, a equipa procedeu à definição do mesmo, permitindo à equipa redobrar a atenção nas atividades em questão. 73 Orçamento Este projeto tem cariz académico pelo que os valores monetários aqui apresentados são simbólicos e representativos de uma simulação real, não serão valores aplicados. O orçamento atribuído para este projeto é de 8 435€ (Anexo VIII – Orçamento). O orçamento total do projeto divide-se em custo e reserva. No processo de cálculo do custo, a equipa começou por listar os recursos necessários à realização do projeto, tais como recursos humanos, custos de deslocação, equipamentos e documentação. Para o cálculo da reserva, à semelhança das reservas do cronograma, a equipa recorreu ao cálculo de PERT, tendo por base a estimativa otimista, pessimista e provável. Através dos 3 cenários e da atribuição de custo a cada hora de duração do projeto, a equipa determinou o orçamento do projeto. Numa perspetiva work-package o desenvolvimento apresenta-se como o processo de custo mais elevado, mas também com um valor monetário superior, seguindo-se da planificação e finalização. O processo que agrega um valor monetário mais baixo é a iniciação. Apesar do desenvolvimento ser o processo que tem uma atribuição de valor monetário superior, numa perspetiva da distribuição dos custos ao longo do tempo do projeto, o pico dos custos é na fase final do projeto. Este facto explica-se pela curta duração da finalização do projeto na qual entram em vigor os custos de documentação. Recursos O bom relacionamento da equipa e a harmonia entre os elementos é um dos fatores de impacto no sucesso de uma equipa. Neste sentido, no início do projeto, a equipa definiu algumas regras (Anexo IX – Regras de Trabalho), nas quais estão definidas as horas de trabalho semanais, as vias de comunicação, prémios e penalizações ao não cumprimento das regras, renumeração fictícia de trabalho, políticas de trabalho e por fim local de trabalho e respetivos pontos de encontro para reunião. Após o estabelecimento de regras procedeu-se à elaboração do organigrama (Anexo X – Organigrama), que retrata os cargos e a hierarquia da equipa, e posteriormente à elaboração de uma matriz RAM (Anexo XI – RAM). Esta matriz atribui tarefas a cada um dos stakeholders , respeitando sempre a utilização dos recursos. Para a construção da mesma, a equipa seguiu uma abordagem RACI, R – responsável pela execução, A - aprovar e garantir a execução, C - consultado, I – informado, e cruzou com as tarefas representadas no diagrama de Gantt . Os stakeholders presentes nesta matriz são cada um dos elementos da equipa, o cliente, o sponsor , o proponente e o administrador. 80 Sprint 4 Introdução de novos requisitos R32, R33, R34, R35, R36 e R37 R32 – Possibilidade de enviar mensagem privada para o administrador R33 – Perfil específico da organização com livre acesso ao anúncio de eventos R34 – Pop-up informativo R35 – Reencaminhamento para inscrição R36 – Ferramentas de referência R37 – Referências de referência À semelhança do sprint 2, aquando da reunião do sprint 4 procedeu-se à introdução de novos requisitos. Estes novos requisitos foram introduzidos no backlog do produto, no entanto apenas os requisitos R34, R35, R36 e R37 foram incluídos no backlog do sprint 4. O R34 foi integrado na tarefa “Criação do reencaminhamento para inscrição” e os requisitos R35, R36 e R37 foram integrados na tarefa “ Pop-up informativo”. Neste sprint, Tabela 17, foram entregues incrementos muito importantes para a plataforma através da conclusão da tarefa “Criar funcionalidade login e registar” e “Disponibilizar o site em duas versões: Portuguesa e Inglesa”. A funcionalidade login e registar foi aquela onde a equipa teve mais dificuldades, sendo, portanto, a única com uma duração de três sprints. Tabela 17: Planeamento sprint - Sprint 4 Planeamento Sprint 4 Tarefas Estado Criar funcionalidade login e registar Concluído Disponibilizar o site em duas versões: Portuguesa e Inglesa Concluído Criação da funcionalidade de criar pergunta Em desenvolvimento Criação da funcionalidade de criar resposta Em desenvolvimento Criação das funcionalidades do administrador Em desenvolvimento Criação do reencaminhamento para inscrição Concluído Pop-up informativo Em desenvolvimento 81 Sprint 5 O sprint 5, Tabela 18, é o final. Após a finalização deste, a equipa apenas poderá proceder a pequenos ajustes da mesma. Tabela 18: Planeamento sprint - Sprint 5 Planeamento Sprint 5 Tarefas Estado Criação da funcionalidade de adicionar relatórios por utilizador Concluído Criar funcionalidade eventos Concluído Criação da funcionalidade de criar pergunta Concluído Criação da funcionalidade de criar resposta Concluído Criação das funcionalidades do administrador Concluído Adicionar informação estática Concluído Moldar layout para ser adaptável a qualquer dimensão de ecrã Concluído Funcionalidades de restrição a utilizadores sem registo Concluído Realizar testes às funcionalidades Concluído Este sprint foi o mais sobrecarregado para a equipa, sendo compensado por uma duração superior aos 15 dias standard dos sprints anteriores. O prolongamento do sprint ocorreu devido à pandemia do Covid-19 que foi decretada dias após a reunião do sprint 2. A suspensão temporária de aulas e reuniões impossibilitaram, temporariamente, o contacto com os apoios de ajuda à equipa, levando ao acumular de dúvidas e erros na plataforma. 82 5. RESULTADOS OBTIDOS E DISCUSSÃO Neste capítulo pretende-se analisar os resultados do trabalho realizado e analisar o desempenho da equipa na gestão deste projeto. Aquando da discussão dos resultados importa reforçar que mais de metade do tempo dedicado ao desenvolvimento desta plataforma esteve sob influência da pandemia do Covid-19. Assim, a equipa viu-se impossibilitada de reunir presencialmente e privada de infraestruturas adequadas, o que se refletiu numa dificuldade acrescida na resolução de problemas. Este capítulo é composto pela descrição da plataforma HELP PME PROJECTS e análise da qualidade da plataforma e do sucesso do projeto. A Plataforma HELP PME PROJECTS A execução dos requisitos deu origem à plataforma HELP PME PROJECTS disponível através do link https://help-pme.dsi.uminho.pt/. Nesta secção é realizada uma descrição do protótipo da plataforma, das funcionalidades e das restrições. A página inicial da plataforma, Figura 20, tem um layout apelativo, simples e intuitivo, todas as funções da plataforma são acessíveis a partir desta. Nesta temos os botões “Página Inicial”, “Fórum”, “Eventos”, “Relatórios”, “Noções Base”, “Informação”, “Login”, “PT|EN” e “Sobre Nós”. O cabeçalho onde se encontram estes botões, acompanha sempre a plataforma em todas as páginas. A secção “Fórum”, Figura 21, está organizada de acordo com as áreas de conhecimento do PMBOK e a cada uma das áreas está associado um pop-up com uma breve explicação de cada uma das Figura 20: “Página Inicial” da plataforma HELP PME PROJECTS 83 áreas. O acesso a esta secção da plataforma é restrito, uma vez que apenas utilizadores inscritos poderão participar do mesmo. No caso de algum utilizador iniciar a sua participação sem ter realizado inscrição/login, este será automaticamente reencaminhado para essa ação. Na secção “Sobre Nós”, Figura 22, para a qual é possível ser encaminhado a partir da página inicial, encontra-se disponível a história do site , os valores, missão e visão pela qual este preza. Nesta área, é possível ainda enviar sugestões de melhoria para o administrador para que estas sejam avaliadas e tidas em consideração. Figura 22: Secção “Sobre Nós” da HELP PME PROJECTS A secção eventos, Figura 23, não está sujeita a inscrição, qualquer utilizador poderá ter acesso aos eventos anunciados na plataforma. Cada evento é associado a uma área de conhecimento (das 10 Figura 21: “Fórum” da plataforma HELP PME PROJECTS 84 do PMBOK), e é enquadrado em cada um dos tipos, podendo ser “Workshop”, “Palestra”, “Trainee”, “Conferência”, “Feira de Emprego” ou “Outro”. Esta funcionalidade orienta o utilizador para a área ou eventos que lhe é preferido ou de maior interesse. Figura 23: Secção “Eventos” da HELP PME PROJECTS Na secção eventos os utilizadores inscritos têm a possibilidade de solicitar a partilha de um evento. Para tal, estes devem clicar no botão “fazer pedido de novo evento”, preencher com os respetivos dados do evento, e posteriormente adicionar a imagem de capa do evento. A publicação e partilha deste evento fica sujeita a aprovação por parte do administrador da plataforma. A secção relatórios, Figura 24, segue uma lógica idêntica à secção eventos. Figura 24: Secção “Relatórios” da HELP PME PROJECTS 85 Os relatórios dividem-se por áreas de conhecimento e apenas os utilizadores inscritos poderão ter acesso aos mesmos, sendo a funcionalidade do botão “fazer pedido de novo relatório” semelhante ao existente na secção eventos. Nesta secção esperam-se temáticas relacionadas com a gestão de projetos, como relatórios anuais de desempenho das empresas na gestão de projetos, artigos, trabalhos, dissertações relacionadas com o tema. Na secção “Noções Base”, Figura 25, encontram-se disponíveis alguns conceitos base e essenciais da gestão de projetos. É uma área de acesso livre, e as definições têm como referência o PMBOK. Figura 25: Secção “Noções Base” da HELP PME PROJECTS A secção “Informação”, Figura 26, tem como objetivo ajudar e apoiar os utilizadores na procura pelo conhecimento de gestão de projetos, compactando algumas fontes de conhecimento da área. Neste, são partilhadas as “Normas ou Projetos de Normas de Gestão de Projetos”, “Cursos e Certificações em Gestão de Projetos em Portugal”, “Referenciais de Gestão de Projetos”, “Guias disponibilizados pela APOGEP” e alguns “ Sites de Gestão de Projetos”. Nas áreas de “Cursos e Certificações em Gestão de Projetos em Portugal”, “Guias de Gestão disponibilizados pela APOGEP” e alguns “ Sites de Gestão de Projetos” é possível ter acesso direto aos conteúdos, isto é, por exemplo, se clicar em “Mestrado em Gestão de Projetos de Engenharia – Universidade do Minho” o utilizador irá ser reencaminhado para a página oficial do mestrado em questão. 86 Relativamente aos “Guias de Gestão disponibilizados pela APOGEP”, estes são guias disponibilizados pela APOGEP para a plataforma HELP PME PROJECTS. Figura 26: Secção "Informação" da HELP PME PROJECTS O perfil do administrador, Figura 27, permite-lhe monitorizar e gerir a plataforma, e ainda recolher alguns dados relativamente aos utilizadores da mesma. Para além da funcionalidade de monitorização, através deste perfil é possível caracterizar a comunidade de utilizadores da plataforma. Os dados recolhidos são o número de utilizadores, número de relatórios, número de eventos, número de perguntas do fórum, número de pedidos de eventos e número de sugestões de melhoria. Figura 27: Perfil do administrador da HELP PME PROJECTS 87 Relativamente aos utilizadores, a plataforma permite a eliminação de um utilizador e também a caracterização dos mesmos, em relação ao tipo de utilizadores (estudantes, professores/investigadores, empresas e gestores de projeto). Os estudantes, professores/investigadores são caracterizados pela idade, género, profissão, área de conhecimento e ciclo de estudo. Os gestores de projetos são caracterizados pela idade, género, profissão, nome da empresa, ramo empresarial, número de trabalhadores da empresa e região do país. Por fim, as empresas são caracterizadas pelo nome da empresa, profissão do utilizador em nome da empresa, ramo empresarial, número de trabalhadores da empresa e região do país. Na secção gestão de eventos é possível adicionar, editar ou eliminar eventos. Já na secção de gestão de pedidos de eventos apenas é possível aceitar ou rejeitar o evento. Na gestão de relatórios é possível adicionar, editar e eliminar relatórios. A secção gestão de sugestões dá-nos acesso a todas as sugestões de melhoria enviadas. Estas poderão ser eliminadas ou mantidas no perfil do administrador. Relativamente ao fórum, o administrador tem acesso ao número de perguntas existentes para cada uma das áreas de conhecimento. No entanto, não tem controlo sobre este, ou seja, não lhe é permitido eliminar perguntas ou respostas. Análise da Qualidade da Plataforma e do Sucesso do Projeto Os resultados obtidos devem ter em consideração a definição de qualidade aplicada a este projeto. Um dos pressupostos da qualidade aplicada a este projeto prende-se com os requisitos. A plataforma HELP PME PROJECTS será de qualidade se a maioria dos requisitos forem atendidos (se um número reduzido de requisitos não for atendido serão considerados defeitos). A execução, a presença de “bugs”, o desempenho e a facilidade de utilização são também critérios de avaliação da qualidade. Análise da matriz de rastreabilidade dos requisitos A matriz de rastreabilidade dos requisitos, Tabela 19, permite analisar a progressão dos requisitos ao longo do projeto. Tabela 19: Matriz de rastreabilidade dos requisitos após conclusão do projeto Nº Classificação Autor Ownership Prioridade Estado R1 Não Funcional P. Owner P. Owner 5 Concluído R2 Não Funcional P. Owner P. Owner 5 Concluído R3 Não Funcional P. Owner P. Owner 5 Concluído R4 Não Funcional P. Owner P. Owner 3 Concluído R5 Não Funcional P. Owner Utilizadores 4 Concluído 88 Nº Classificação Autor Ownership Prioridade Estado R6 Não Funcional P. Owner Utilizadores 4 Concluído R7 Não Funcional P. Owner P. Owner 5 Concluído R8 Não Funcional P. Owner P. Owner 5 Concluído R9 Não Funcional P. Owner P. Owner 5 Concluído R10 Funcional P. Owner Utilizadores 4 Concluído R11 Funcional P. Owner Utilizadores 4 Concluído R12 Não Funcional P. Owner P. Owner 5 Concluído R13 Não Funcional P. Owner P. Owner 5 Não concluído R14 Funcional P. Owner Utilizadores 5 Concluído R15 Não Funcional P. Owner P. Owner 5 Não concluído R16 Funcional P. Owner Utilizadores 4 Concluído R17 Funcional P. Owner Utilizadores 2 Eliminado R18 Funcional Orientador Utilizadores 2 Eliminado R19 Funcional P. Owner Utilizadores 3 Concluído R20 Funcional P. Owner Utilizadores 4 Concluído R21 Funcional P. Owner Utilizadores 4 Concluído R22 Funcional Orientador Utilizadores 2 Eliminado R23 Funcional Orientador Utilizadores 2 Eliminado R24 Funcional Orientador Utilizadores 2 Eliminado R25 Funcional P. Owner Utilizadores 5 Concluído R26 Funcional P. Owner Utilizadores 2 Não concluído R27 Funcional P. Owner Utilizadores 1 Eliminado R28 Funcional P. Owner Utilizadores 5 Concluído R29 Funcional E. Desenv. Utilizadores 2 Não concluído R30 Não Funcional P. Owner Utilizadores 5 Concluído R31 Funcional P. Owner Utilizadores 2 Não concluído R32 Funcional P. Owner Utilizadores 4 Não concluído R33 Funcional P. Owner Utilizadores 4 Não concluído R34 Não Funcional P. Owner Utilizadores 5 Concluído R35 Funcional E. Desenv. Utilizadores 4 Concluído R36 Funcional P. Owner Utilizadores 5 Concluído R37 Funcional P. Owner Utilizadores 5 Concluído Legenda: Concluído: o requisito foi atendido Não concluído: o requisito não foi atendido Eliminado: o requisito foi eliminado pelo product owner Após a análise da matriz de rastreabilidade dos requisitos é possível concluir que dos 37 (trinta e sete) requisitos da plataforma, 7 (sete) não foram concluídos e 6 (seis) foram eliminados. Dos 7 (sete) requisitos que não foram desenvolvidos, 4 (quatro) têm um grau de importância elevado (quatro e cinco), enquanto os restantes 3 (três) apresentam um grau de importância dois. O requisito R13 não foi concluído uma vez que após o login na plataforma, a palavra “login” é substituída pela palavra “perfil” e não pelo nome do utilizador como requerido neste requisito. O requisito R15 não foi concluído pois o administrador não tem um acesso livre às informações e noções base, não é capaz de alterar o material disponibilizado nestas secções. A impossibilidade de eliminação de uma resposta ou uma pergunta por parte do administrador é uma limitação, pois não 89 existe qualquer controlo sobre os temas debatidos no fórum, estando sujeito a boicote por parte dos utilizadores. Os requisitos R26, R29 e R31 não foram concluídos. A equipa de desenvolvimento informou o product owner que, devido à necessidade de cumprimento do prazo, estes requisitos não iriam ser atingidos, tendo sido selecionados aqueles com um grau de importância associado mais baixo. O requisito R32 não foi concluído pois, apesar de ter um grau de importância associado elevado, devido à necessidade de cumprimento do prazo, a equipa de desenvolvimento considerou como um requisito de menor importância uma vez que todos os utilizadores têm a possibilidade de comunicar com o administrador através da funcionalidade “Ajuda-nos e envia as tuas sugestões de melhoria!”. O R33 encontra-se numa situação semelhante uma vez que todos os utilizadores têm a possibilidade de solicitar ao administrador que este adicione um evento em particular. Os requisitos R17, R18, R22, R23, R24 e R27 são requisitos eliminados pelo product owner. Ao longo do desenvolvimento do projeto a pesquisa relativa às funcionalidades mais apreciadas e consideradas essenciais neste tipo de plataformas levou à introdução de novos requisitos, mas também à eliminação, como foi o caso dos requisitos mencionados. Análise do desempenho da plataforma Execução da plataforma A plataforma HELP PME PROJECTS apresenta uma boa execução, as suas funcionalidades são desempenhadas e obedece às suas limitações, no entanto existe uma falha. A organização da plataforma diverge de acordo com a versão da plataforma, isto é, a versão portuguesa está organizada em “página inicial” – “fórum” – “sobre nós” e a versão inglesa “página inicial” - “carrossel de eventos” – “fórum” – “sobre nós”. A ausência do “carrossel de eventos” na versão portuguesa apresenta-se como um erro de execução. “Bugs” Na versão inglesa da plataforma HELP PME PROJECTS o “carrossel de eventos” apresenta um “bug” uma vez que, apesar da alteração dos eventos na sua secção, os eventos presentes no “carrossel” não são alterados e, por conseguinte, não é possível atualizar o mesmo. Desempenho e facilidade de utilização De forma geral, a plataforma tem um bom desempenho e é de fácil utilização. A plataforma tem uma velocidade de utilização alta, não apresentando falhas. 96 quanto na utilização das técnicas e ferramentas de gestão de projetos. O bom desempenho da equipa foi refletido na avaliação do projeto, à qual foi atribuído a nota final de 18 (dezoito) valores, numa escala de 0 (zero) a 20 (vinte). Para trabalho futuro propõe-se o aprimoramento da plataforma bem como a realização de um estudo e análise de viabilidade desta forma de divulgação da gestão de projetos e apoio às PME. Propõem-se a ainda o estudo e a análise do rácio de planeamento das tarefas nas diferentes combinações dos modelos híbridos, isto é, o estudo da questão: quanto devo planear num modelo híbrido? 97 REFERÊNCIAS BIBLIOGRÁFICAS Abe, P., & Jordan, N. A. (2013). Integrating Social Media Into the Classroom Curriculum. About Campus , 18 (1), 16–20. https://doi.org/10.1002/abc.21107 APOGEP. (2020). Bem Vindos ao site APOGEP. Retrieved April 14, 2020, from http://www.apogep.pt/ Beaver, G. (2007). The strategy payoff for smaller enterprises. Journal of Business Strategy , 28 (1), 11–17. https://doi.org/10.1108/02756660710723161 Cardon, P. W., & Marshall, B. (2015). The hype and reality of social media use for work collaboration and team communication. International Journal of Business Communication , 52 (3), 1–21. https://doi.org/10.1177/2329488414525446 Chawinga, W. D. (2017). Taking social media to a university classroom: teaching and learning using Twitter and blogs. International Journal of Educational Technology in Higher Education , 14 (3), 19. https://doi.org/10.1186/s41239-017-0041-6 Comissão Europeia. (2015). Economia: Guia do Utilizador da Comissão Europeia relativo à definição de PME. In Serviço das Publicações da União Europeia . Luxemburgo: União Europeia. Conforto, E., Barreto, F., Amaral, D. C., & Rebentisch, E. (2015). Modelos híbridos. Revista Mundo Project Management , 64 , 10–17. Cunha, F., & Paiva, J. (2003). A Utilização de Fóruns em Contexto de Ensino/Aprendizagem. Actas Da III Conferência Internacional Sobre Tecnologias de Informação e Comunicação Na Educação. Braga: Portugal . Fernandes, G., Ward, S., & Araújo, M. (2014). Developing a Framework for Embedding Useful Project Management Improvement Initiatives in Organizations. Project Management Journal , 45 (4), 81–108. https://doi.org/10.1002/pmj.21441 Fernandes, J., & Machado, R. J. (2016). Requirements in Engineering Projects (Lecture Notes in Management and Industrial Engineering) (Kindle; A. López-Paredes, Ed.). Braga: Springer. Ferreira, M., Tereso, A., Ribeiro, P., Fernandes, G., & Loureiro, I. (2013). Project Management Practices in Private Portuguese Organizations. Procedia Technology , 9 , 608–617. https://doi.org/10.1016/j.protcy.2013.12.067 Fonseca, A. (2011). AS PME em Portugal: reflexões e desafios (ISCTE Business School). Retrieved from https://repositorio.iscteiul.pt/handle/10071/4272 Gilb, T., & Finzi, S. (1988). Principles of Software Engineering Management . https://doi.org/10.1017/s0263574700005671 Gregor, S., & Hevner, A. R. (2013). Positioning and Presenting Design Science Research for Maximum Impact on JSTOR. MIS Quarterly , 19. Retrieved from https://bityli.com/s18uh Harvey, L., & Green, D. (1993). Defining Quality. Assessment & Evaluation in Higher Education , 18 (1), 9–34. https://doi.org/10.1080/0260293930180102 Hay, M., & Kamshad, K. (1994). Small Firm Growth: Intentions, Implementation and Impediments. Business Strategy Review , 5 (3), 49–68. https://doi.org/10.1111/j.1467-8616.1994.tb00166.x Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in Information Systems Research. MIS Quarterly , 28 (1), 75–105. https://doi.org/10.2307/25148625 Hysa, B., & Spalek, S. (2019). Opportunities and threats presented by social media in project management. Heliyon , 5 (4), e01488. https://doi.org/10.1016/j.heliyon.2019.e01488 IIBA, I. I. of B. A. (2011). Um guia para o Corpo de Conhecimento de Análise de Negócios (Guia BABOK®) V2 . Toronto: International Institute of Business Analysis. IIBA, I. I. of B. A. (2015). A Guide To The Business Analysis Body Of Knowledge (Guia BABOK®) V3 . Toronto: International Institute of Business Analysis. INE. (2010). Estudos sobre Estatísticas Estruturais das Empresas - 2008 . https://doi.org/4-3 INE. (2019). Portal do INE - Anuário Estatístico de Portugal - 2018 . Lisboa. IPMA. (2015). Referencial de Competências Individuais para Gestão de Projetos, Programas e Portefólios (Vol. 4). International Project Management Association. 98 IPQ. (2020). O “Top 10” das dificuldades das PME. Kickstarter. (2020). Kickstarter. Retrieved January 4, 2020, from https://www.kickstarter.com/ Kwahk, K. Y., & Park, D. H. (2016). The effects of network sharing on knowledge-sharing activities and job performance in enterprise social media environments. Computers in Human Behavior , 55 , 826–839. https://doi.org/10.1016/j.chb.2015.09.044 McCain, R. A. (2018). Entrepreneurship and Small Business. In The Economics of Small Business (4th ed., pp. 69–88). Philadelphia: Word Scientific. Miranda, L., Morais, C., Dias, P., & Almeida, C. (2001). Ambientes de aprendizagem na web: Uma experiência com fóruns de discussão. Actas Do Challenges 2001, II Conferência Internacional de Tecnologias de Informação e Comunicação Na Educação. , 585–593. Braga: Centro de Competência Nónio da Universidade do Minho. Mitchell, R. K., Agle, B. R., & Wood, D. J. (1997). Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts. Academy of Management Review , 22 (4), 853–886. https://doi.org/10.1037/h0035597 MSI. (1997). Missão para a sociedade da Informação: Livro Verde Para a Sociedade da Informação em Portugal (Vol. 14; M. P. a S. da Informação, Ed.). Lisboa: Missão para a Sociedade da Informação. Paula Filho, W. de P. (2000). Engenharia de Software: fundamentos, métodos e padrões. In Manual do Engenheiro de Software (pp. 1– 260). Editora LTC. Peças, P., Jorge, A., Morgado, J., Henriques, E., & Cernadas, R. (2012). Collaborative approach for performance improvement of non-added value activities in SMEs. 2012 18th International Conference on Engineering, Technology and Innovation, ICE 2012 - Conference Proceedings , 10. https://doi.org/10.1109/ICE.2012.6297681 Pinto, R., & Dominguez, C. (2012). Characterization of the practice of project management in 30 Portuguese metalworking companies. Procedia Technology , 5 , 83–92. https://doi.org/10.1016/j.protcy.2012.09.010 PME. (2020). Portal PME - Portal da Empresa. Retrieved January 4, 2020, from https://pme.pt/ PMI. (2017a). A Guide To The Project Management Body of Knowledge (PMBOK GUIDE) (6th ed.). Pennsylvania: Project Management Institute, Inc. PMI. (2017b). The Standard for Portfolio Management (4th ed.). Pennsylvania: Project Management Institute, Inc. PMI. (2017c). The Standard For Program Management (4th ed.). Pennsylvania: Project Management Institute, Inc. PMI. (2020). PMI Standards - PMI Portugal. Retrieved April 13, 2020, from https://pmi-portugal.org/pmi-standards/ Pollack, J., & Adler, D. (2014). Does project management affect business productivity? Evidence from australian small to medium enterprises. Project Management Journal , 45 (6), 17–24. https://doi.org/10.1002/pmj.21459 PORDATA. (2020). Empresas. Retrieved April 13, 2020, from https://www.pordata.pt/Subtema/Portugal/Empresas-374 Praxis. (2020). Praxis is a free framework for the management of projects, programmes and portfolios - Praxis Framework. Retrieved November 10, 2020, from https://www.praxisframework.org/ Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A Practitioner’s Approach (Eighth; V. Bradshaw, Ed.). New York: Raghu Srinivasan. Remidez, H., & Jones, N. B. (2012). Developing a Model for Social Media in Project Management Communications. In International Journal of Business and Social Science (Vol. 3). Retrieved from https://bityli.com/fJOXr Ribeiro, L., & Gusmão, C. (2008). Definição de um Processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos. Hífen , 32 (62), 67–74. Retrieved from http://revistaseletronicas.pucrs.br/ojs/index.php/hifen/article/view/4580 Romano, B. L., & Silva, A. D. da. (2015). Project management using the scrum agile method: A case study within a small enterprise. 12th International Conference on Information Technology: New Generations , 774–776. https://doi.org/10.1109/ITNG.2015.139 Royce, W. W. (1970). Managing the development of large software systems. Proceedings IEEE WESCON , 1–9. https://doi.org/10.1016/0378-4754(91)90107-E Santos, A. (2018). Seleção do Método de Pesquisa - Guia para Pós-Graduados em Design e Áreas Afins (22o, p. 230). 22o, p. 230. Curitiba: Insight Editora. 99 Saunders, M., Lewis, P., & Thornhill, A. (2009). Research Methods for Business Students. In Financial Times (5th ed., Vol. 30). Harlow: Pearson Education Limited. SBOK. (2017). Conhecimento em Scrum TM (Guia SBOK ) 3rd Edição . Arizona: SCRUMstudy. Schwaber, K., & Sutherland, J. (2017). The Scrum Guide: The Definitive The Rules of the Game . https://doi.org/10.1053/j.jrn.2009.08.012 Seymour, T., & Hussein, S. (2014). The History Of Project Management. International Journal of Management & Information Systems , 18 (4), 233–240. https://doi.org/10.19030/ijmis.v18i4.8820 Shahin, A., van Gurp, T., Peters, S. A., Visser, R. G., van Tuyl, J. M., & Arens, P. (2012). SNP markers retrieval for a non-model species: a practical approach. BMC Research Notes , 5 (1), 79. https://doi.org/10.1186/1756-0500-5-79 Shevtshenko, E., Poljantchikov, I., Mahmooda, K., Kangilasski, T., & Norta, A. (2015). Collaborative project management framework for partner network initiation. Procedia Engineering , 100 , 159–168. https://doi.org/10.1016/j.proeng.2015.01.354 Sierve, F. (2014). Gestão por Processos e Projetos. Retrieved January 4, 2020, from https://www.gestaoporprocessos.com.br/sobre/ Silva, R. F., & Melo, F. C. L. (2016). Modelos híbridos de gestão de projetos como estratégia na condução de soluções em cenários dinâmicos e competitivos. Revista Brasileira de Gestao e Desenvolvimento Regional , 12 (3), 443–457. Simon, H. A. (1996). The Sciences of the Artificial. In Massachusetts Institute of Technology (Third Edit, Vol. 11). Massachusets: MIT Press. Smith, L. W. (2000). Project Clarity Through Stakeholder Analysis. The Journal of Defense Software Engineering , (Dec.), 4–9. Sommerville, I. (2011). Engenharia de Software (9th ed.). São Paulo: Pearson Education do Brasil. Souza, M. M. (2010). Uma proposta para aplicar análise quantitativa de riscos em projetos de software ágeis . Universidade Federal de Pernambuco. Sutherland, J. (2014). SCRUM: A arte de fazer o dobro do trabalho com metade do tempo (Texto Edit). São Paulo: LeYa. Tait, B., & Eds, S. G. (2012). ICT Education. In Encyclopedia of the Sciences of Learning . Northern Drakensberg: Springer. Takeuchi, H., & Nonaka, I. (1986). The new new product development game . Tang, Y., & Hew, K. F. (2017). Using Twitter for education: Beneficial or simply a waste of time? Computers and Education , 106 , 97–118. https://doi.org/10.1016/j.compedu.2016.12.004 Tereso, A., Ribeiro, P., Fernandes, G., Loureiro, I., & Ferreira, M. (2019). Project Management Practices in Private Organizations. Project Management Journal , 50 (1), 1–17. https://doi.org/10.1177/8756972818810966 The Standish Group International. (2009). CHAOS Summary 2009 . Retrieved from https://bityli.com/FDUEF The Standish Group International. (2015). CHAOS Report 2015. In The Standish Group International, Inc. Turner, R., & Ledwith, A. (2016). Project Management in Small to Medium-Sized Enterprises: Fitting the Practices to the Needs of the Firm to Deliver Benefit. Journal of Small Business Management , 56 (3), 475–493. https://doi.org/10.1111/jsbm.12265 Turner, R., Ledwith, A., & Kelly, J. (2010). Project management in small to medium-sized enterprises: Matching processes to the nature of the firm. International Journal of Project Management , 28 , 744–755. https://doi.org/10.1016/j.ijproman.2010.06.005 Turner, R., Ledwith, A., & Kelly, J. (2012). Project management in small to medium-sized enterprises: Tailoring the practices to the size of company. Management Decision , 50 (5), 942–957. https://doi.org/10.1108/00251741211227627 Van Scoy, R. L. (1992). Software Development Risk : Opportunity, Not Problem. In Distribution Unlimited . Pittsburgh, Pennsylvania 15213. Vargas, R. (2020). Ricardo Vargas é um dos principais defensores da economia por projetos. Retrieved November 10, 2020, from https://ricardo-vargas.com/pt/ Yin, R. K. (2018). Case Study Research and Applications: design and methods (6th ed.). London: Cosmos Corporation. Zimba, O., Radchenko, O., & Strilchuk, L. (2019). Social media for research, education and practice in rheumatology. Rheumatology International , 40 , 183–190. https://doi.org/10.1007/s00296-019-04493-4 100 APÊNDICE I – QUESTIONÁRIO DE AVALIAÇÃO DAS METODOLOGIAS Questionário de Avaliação das Metodologias 1. Quais as metodologias utilizadas para a gestão de projetos da HELP PME PROJECTS? 2. Em que fase da gestão de projeto foi aplicada cada uma das metodologias? Identificação das Metodologia Utilizadas 3. Quais foram as práticas da metodologia tradicional utilizadas? 4. Quais foram as práticas de scrum utilizadas? 5. Qual a percentagem de tempo que utilizaste na aplicação das metodologias tradicionais de gestão de projetos em todo o trabalho deste projeto? □ 10% □ 20% □ 30% □ 40% □ 50% □ 60% □ 70% □ 80% □ 90% 6. Qual a percentagem de tempo que utilizaste na aplicação das metodologias ágeis de gestão de projetos em todo o trabalho deste projeto? □ 10% □ 20% □ 30% □ 40% □ 50% □ 60% □ 70% □ 80% □ 90% 7. Qual percentagem de tempo utilizaste na componente de implementação técnica deste projeto? □ 10% □ 20% □ 30% □ 40% □ 50% □ 60% □ 70% □ 80% □ 90% 8. Consideras que estas percentagens foram adequadas? □ Sim □ Não 8.1. Se sim, o que farias diferente? Apreciação Global da Metodologia Utilizada 9. Qual a tua opinião relativamente à metodologia global utilizada? Apreciação Global do Desempenho da Equipa 10. Como classificas o desempenho da equipa na gestão deste projeto? □ Fraco □ Médio □ Bom □ Muito Bom □ Excelente Este questionário insere-se no desenvolvimento de uma dissertação que consiste na definição e acompanhamento do desenvolvimento de uma plataforma digital: HELP PME PROJECTS. Através deste pretende-se compreender qual a opinião da equipa de desenvolvimento da plataforma relativamente à metodologia utilizada para a gestão de projetos. Esta metodologia foi imposta à equipa uma vez que se insere numa Unidade Curricular do Curso de MIEGSI da Universidade do Minho. Este questionário insere-se no desenvolvimento de uma dissertação que consiste na definição e acompanhamento do desenvolvimento de uma plataforma digital: HELP PME PROJECTS. Através deste pretende-se compreender qual a opinião da equipa de desenvolvimento da plataforma relativamente à metodologia utilizada para a gestão de projetos. Esta metodologia foi imposta à equipa uma vez que se insere numa Unidade Curricular do Curso de MIEGSI da Universidade do Minho. 101 APÊNDICE II – DESCRIÇÃO DETALHADA DOS REQUISITOS Requisitos da plataforma HELP PME PROJECTS R1 Cores: Azul, Vermelho, Laranja ou cinza. As cores não devem ser fortes; R2 O logotipo deve ser criado e estará localizado no canto superior esquerdo; R3 Login localizado no canto superior direito; R4 O cabeçalho deve estar centrado, e terá as componentes: Página Inicial, Relatórios, Eventos, Sobre Nós e Aba de Pesquisa; R5 O layout deve ter adaptação para consulta através do telemóvel e tablet, este deverá ser semelhante ao web, sendo sempre o foco principal o Fórum; R6 Versão da plataforma em Inglês; R7 A consulta da plataforma sem inscrição na mesma deve ser restrita, não poderão aceder aos relatórios, nem os comentários das perguntas (poderão aceder às perguntas); R8 Ter um perfil de administrador; R9 A plataforma deve ser habilitada para a inscrição de vários utilizadores; R10 O Perfil do utilizador deverá ter oportunidade de alteração de todos os campos; R11 O utilizador poderá permitir a visualização por parte dos outros utilizadores a sua informação pessoal não sensível, tendo possibilidade de escolha da mesma. Assim, se nada for selecionado apenas será visível o nome do utilizador e a sua profissão; R12 O login/inscrição estará localizado/a no canto superior direito, sendo necessária para inscrição as seguintes informações: • Nome*; • Idade*; • Género*; • Profissão (professor/investigador, estudante, empresa, gestor de projetos, preenchimento livre) se *: o Empresa: ▪ Qual o ramo empresarial, nº de empregados e região do país. Ramo empresarial será de resposta fechada e Região por região agrária o Gestor de projetos e preenchimento livre: ▪ Trabalha numa PME? Se sim: • Qual o ramo empresarial, nº de empregados, região do país. Ramo empresarial será de resposta fechada e Região por região agrária o Professor/investigador: ▪ Área científica o Estudante: ▪ Ciclo de estudo • Email* • Palavra-passe* • Confirmação da palavra-passe* • Pequeno texto de apresentação pessoal • Termos e condições (p.ex: permitir a visualização por parte dos outros do nome e profissão) *simboliza campos de preenchimento obrigatório. Essa informação deverá estar presente aquando da inscrição. R13 Após realizado o login, este será substituído pelo nome do utilizador; 102 R14 Aquando do login deverá também a opção “inscrever” e esqueci a minha palavra passe – caso o utilizador se esqueça da palavra passe este poderá recuperá-la através do email; R15 Manutenção e atualização fácil; R16 Links para normas de Gestão de Projetos; R17 Organizações que se debruçam sobre a GP; R18 Informações sobre projetos financiados pela ANI: Link para o site; R19 Cursos, pós-graduações, certificações em GP existem; R20 Informações básicas sobre gestão de projetos (PMI, 2017a). A página deve ter a referência do PMBOK: • As questões presentes na página principal serão: o O que é um projeto? o O que é Gestão de Projetos? o Qual é o Papel do Gestor de Projetos? • Quando realizado o clique será direcionado para a página com essas informações, diretamente para a linha onde a mesma está presente. • A página com estas informações deverá manter o cabeçalho da página inicial. R21 Sobre nós • História do site • Valores • Objetivos • Metas • Sugestão de melhoria R22 Link para a página da União Europeia de Gestão de Projetos; R23 Contador de temas de GP mais falados, isto é, a plataforma deverá pesquisar no Google Schoolar quais os temas de Gestão de Projetos mais publicados; R24 Observatório do sucesso dos projetos nas PME Portuguesas. Recolher e tratar dados e fornecer relatórios trimestrais sobre o sucesso dos projetos. Género Chaos Report para PME em Portugal; R25 Possibilidade de anunciar eventos sobre a GP; R26 Help-desk automático. Este deverá surgir automaticamente como “no que posso ajudar?”. Este, de acordo com a resposta, deverá redirecionar o utilizador para as guias de pesquisa, tendo por base palavras chave e frases padrão. O help-desk deverá ter a possibilidade de minimizar. Quando minimizado ficará disponível através do ícone do ponto de interrogação (?); R27 Alerta de notícias relativas a palavras chave; R28 Fórum • O fórum será de disponível utilização apenas para aqueles que são inscritos. Este estará disponível na página principal.; • Do lado esquerdo do painel central estarão disponíveis as 10 áreas de conhecimento da gestão de projetos do PMBOK, que serão as áreas de discussão no fórum: o Gestão da Integração o Gestão do âmbito o Gestão do Cronograma o Gestão do Custo o Gestão da Qualidade o Gestão dos Recursos o Gestão da Comunicação o Gestão de Riscos o Gestão de Aquisições o Gestão dos Stakeholders 103 À frente de cada uma das áreas deverá aparecer o número de perguntas daquela área: • Quando uma das áreas é selecionada, a mesma deve aparecer da mesma cor da área de perguntas, dando destaque da área que está a ser consultada; • O fórum será de visualização pública das perguntas, porém os comentários ou para colocar uma questão terá de se inscrever; • Em cada uma das perguntas deverá ter disponível o número de comentários; • Quando é escrita uma pergunta/dúvida é obrigatório escolher pelo menos uma das áreas de conhecimento na qual esta se enquadra. Na página deve aparecer o nome de quem colocou a questão e no máximo 3 linhas escritas; • Nos comentários deverá ser possível colocar um like (através do ícone do like ), e também deverá possibilitar a eleição da melhor resposta (através do ícone taça). Os comentários devem estar dispostos por ordem de mais eleito e mais “like”; • A plataforma deverá permitir enviar uma mensagem privada para outro utilizador, que surgirá como uma caixa de diálogo. Esta caixa de diálogo deverá ter a opção de minimizar ou fechar; R29 Ranking dos utilizadores que mais participam. Aqui deverão aparecer os 10 utilizadores da plataforma que mais interagem, isto é, o ranking irá dar a conhecer os utilizadores que mais respondem às perguntas realizadas no Fórum; R30 No cabeçalho deverá ser introduzido um botão para acesso ao fórum; R31 Templates base: deverá ser adicionada uma secção com templates base das práticas/ferramentas de gestão de projetos consideradas indispensáveis para levar um projeto a bom porto; • Deverão existir diferentes templates para as diferentes áreas de atuação (construção civil, TSI, industrial, etc); • Este template base será disponibilizado pelo administrador, mas será interativa com os utilizadores; • À frente de cada uma das práticas terá um botão de votação nas práticas mais importantes. Assim, os utilizadores poderão selecionar as práticas que consideram mais importantes; • Os utilizadores poderão sugerir a adição de novas práticas, para tal, deverá ter um botão de “sugestão de uma prática/ferramenta”. Esta sugestão irá criar uma solicitação no perfil do administrador que irá aceitar ou não a sugestão; R32 Os utilizadores terão a possibilidade de enviar mensagem privada para o administrador; R33 O perfil de uma organização deverá ter a possibilidade de solicitar livre acesso para a divulgação de eventos. Esta solicitação ser aceite pelo administrador; R34 Em cada área de gestão de projetos do fórum deverá existir um pop-up com uma breve definição de cada uma das áreas; R35 Botão no fórum para encaminhar para a inscrição; R36 Ferramentas de referência – deverá haver uma secção com as ferramentas consideradas de referência – estas ferramentas devem estar associadas a cada uma das áreas de conhecimento e de acordo com a área de atuação da empresa; R37 Referências de referência – deverá haver uma secção com as ferramentas consideradas de referência – estas referências devem estar associadas a cada uma das áreas de conhecimento e de acordo com a área de atuação da empresa. 104 APÊNDICE III – INFORMAÇÕES DA PLATAFORMA Secção “Noções Base” Projeto / Project Um projeto é um esforço temporário realizado com o objetivo de criar um produto, serviço ou resultado único. É temporário pois tem um início e um fim definidos, sendo que o fim pode ser definido não só através de uma data, mas também através do alcance dos objetivos do projeto, da impossibilidade de cumprimento dos objetivos, ausência de recursos, entre outros (PMI, 2017a). “A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end”. “A project’s end is reached when the objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists” (PMI, 2017a, p. 152). Programa / Program Um programa define-se como um conjunto de projetos, programas subsidiários e atividades relacionadas do programa, que geridos em conjunto possibilitam a obtenção de benefícios que não seriam possíveis que fossem geridos individualmente (PMI, 2017a). “A program is defined as related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually” (PMI, 2017a, p. 543). Portefólio / Portfolio Um portefólio define-se como um conjunto de projetos, programas, portefólios subsidiários e operações geridas em conjunto de modo a alcançar objetivos estratégicos (PMI, 2017a). “A portfolio is defined as projects, programs, subsidiary portfolios, and operations managed in a coordinated manner to achieve strategic objectives” (PMI, 2017a, p. 543). Gestão de Projetos / Project Management A gestão de projetos define-se como a aplicação de conhecimentos, habilidades, ferramentas e técnicas com o objetivo de cumprir os requisitos de um projeto. Esta é realizada através da aplicação e integração apropriada dos processos de gestão de projetos selecionados, focando-se nas interdependências que existem dentro de um projeto para determinar a abordagem ideal para o gerir (PMI, 2017a). “Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project management is accomplished through the appropriate application and integration of the project management processes identified for the project. Project management focuses on interdependencies within a project to determine the optimal approach for managing the project” (PMI, 2017a, p. 542). Gestão de Programas / Program Management A gestão de programas é definida como a aplicação de conhecimentos, habilidades e princípios de modo a atingir os seus objetivos e a obter os benefícios e controlo que não estariam disponíveis se os componentes fossem geridos individualmente. Assim, a gestão de programas foca-se nas interdependências entre projetos e entre projetos e o nível do programa, com o objetivo de definir a abordagem ideal para os gerir (PMI, 2017a). “Program management is defined as the application of knowledge, skills, and principles to a program to achieve the program objectives and to obtain benefits and control not available by managing program components individually”. “Program management focuses on the interdependencies between projects 105 and between projects and the program level to determine the optimal approach for managing them” (PMI, 2017a, p. 14). Gestão de Portefólios / Portfolio Management A gestão de portefólios define-se como a gestão centralizada de um ou mais portefólios para alcançar objetivos estratégicos, devendo esta ser consistente e alinhada com a estratégia organizacional. Os componentes do portefólio (programas e projetos) podem não ser interdependentes ou estar diretamente relacionados (PMI, 2017a). “Portfolio management is defined as the centralized management of one or more portfolios to achieve strategic objectives”. “Portfolio management confirms that the portfolio is consistent with and aligned with organizational strategies. The programs or projects of the portfolio may not necessarily be interdependent or directly related” (PMI, 2017a, p. 15). Gestor de Projetos / The Project Manager O papel do Gestor de Projetos é liderar a equipa definida para alcançar os objetivos do projeto. Este é responsável por moldar a abordagem do projeto, o ciclo de vida e os processos de gestão de projetos de modo a cumprir os requisitos do projeto e do produto (PMI, 2017a). “The project manager is the person assigned by the performing organization to lead the team responsible for achieving the project objectives” (PMI, 2017a, p. 52). “To be successful, the project manager should tailor the project approach, life cycle, and project management processes to meet the project and product requirements” (PMI, 2017a, p. 552) Gestor de Programas / The Program Manager O gestor de programas é autorizado pela organização para liderar a(s) equipa(s) responsável(is) por atingir os objetivos do programa. Este mantém a responsabilidade pela liderança, conduta e desempenho do programa, e por selecionar a equipa do programa capaz de atingir os objetivos do programa e de entregar os benefícios do mesmo antecipadamente (PMI, 2017a, 2017c) “The Program Manager is the person authorized by the organization to lead the team(s) responsible for achieving program goals and objectives” (PMI, 2017a, p. 52). “The program manager maintains responsibility for the leadership, conduct, and performance of a program, and for building a program team that is capable of achieving program objectives and delivering anticipated program benefits” (PMI, 2017c, p. 16) . Gestor de Portefólios / The Portfolio Manager O papel do Gestor de Portefólios é estabelecer e implementar a gestão do portefólio. Este é responsável por assegurar a comunicação e coordenação entre os componentes do portefólio. “Portfolio managers have the responsibility for the establishment and implementation of portfolio management” (PMI, 2017a, p. 19). “Portfolio managers are responsible for ensuring proper communication and coordination among portfolio components” (PMI, 2017b, p. 13) . 112 que as PME detenham o conhecimento necessário ao nível da gestão de projetos de forma adequada, eficaz, minimizando os recursos dispêndios e o dinheiro investido. Finalidade A finalidade deste projeto é o desenvolvimento de uma plataforma interativa de apoio às práticas de gestão de projetos nas pequenas e médias empresas. Objetivos ✓ Recolher os requisitos da plataforma web; ✓ Idealizar e desenvolver uma plataforma intuitiva, completa e atrativa para as PME que procuram ajuda no âmbito da gestão de projetos; ✓ Testar, documentar e implementar a plataforma web. Deliverables ✓ Protótipo funcional da plataforma web; ✓ Documentação técnica da plataforma web; ✓ Manual do Utilizador; ✓ Base de dados da plataforma; ✓ Demonstração da plataforma a PME; ✓ Implementação da plataforma no servidor; ✓ O website será entregue com opção de idioma pt-pt e en-gb. Requisitos De seguida estão apresentados todos os requisitos, impostos pelo cliente, que correspondem às principais funcionalidades que integram a plataforma web. ✓ A plataforma deve ser habilitada para a inscrição de vários utilizadores; ✓ O logotipo estará localizado no canto superior esquerdo; ✓ O login/inscrição estará localizado/a no canto superior direito; ✓ O Perfil do utilizador deverá ter oportunidade de alteração de todos os campos. ✓ O utilizador poderá permitir a visualização por parte dos outros utilizadores a sua informação pessoal não sensível, tendo possibilidade de escolha da mesma; ✓ Caso o utilizador se esqueça da palavra passe este poderá recuperá-la através do email; ✓ Aquando do login deverá também possuir a opção “inscrever-se” e “esqueci a minha palavra passe”; ✓ O cabeçalho deve estar centrado, e terá as componentes: Página Inicial, Relatórios, Eventos, Sobre Nós e Aba de Pesquisa; ✓ A consulta da plataforma sem inscrição na mesma deve ser restrita, não poderão aceder aos relatórios, nem os comentários das perguntas (poderão aceder às perguntas); ✓ O layout deve ter adaptação para consulta através do telemóvel e tablet, este deverá ser semelhante ao web, sendo sempre o foco principal o Fórum; ✓ Manutenção e atualização fácil; ✓ Versão da plataforma em Inglês; ✓ Deve conter link’s para normas de Gestão de Projetos. Stakeholders A tabela apresentada abaixo possui todas as partes interessadas que podem de certo modo influenciar o projeto a ser desenvolvido. 113 Tabela 22: Lista de stakeholders Matriz Stakeholders Na matriz apresentada abaixo, podemos evidenciar o poder e o nível de suporte de cada stakeholder em relação ao projeto. Tabela 23: Matriz de stakeholders - Project Charter Registo dos Stakeholders Na tabela apresentada abaixo, mostramos o registo dos stakeholders, de modo a esclarecer a atuação de cada stakeholders no projeto em questão. Tabela 24: Registo dos stakeholders Stakeholders Interesses no projeto Impacto no projeto Estratégias para obter suporte ou reduzir oposição Administração da PTSI Consulting Sucesso do projeto Feedback e avaliação sobre o projeto desenvolvido pela equipa de trabalho. Garantir que todos os objetivos definidos no projeto, sejam alcançados. Assessoria de GP Sucesso do projeto Orientação da equipa de trabalho ao longo do projeto. Garantir que todos os objetivos definidos no projeto, sejam alcançados. Direção Comercial e Financeira Sucesso do projeto Orientação da equipa de trabalho ao longo do projeto. Fazer o acompanhamento da equipa através de reuniões semanais, de maneira a conseguir realizar uma melhor gestão do projeto, conseguindo assim realizar entregar um bom projeto final. Funções Administração da PTSI Consulting Assessoria de Gestão de Projetos Direção Comercial e Financeira Direção de Gestão de Projetos Interlocutor do cliente Cliente final Líder de equipa Restante equipa Nível de suporte ao projeto Oposição Indiferença Suporte Poder Alto Direção de Gestão de Projetos; Interlocutor do Cliente; Administração da PTSI Consulting; Product Owner Médio Direção Comercial e Financeira; Assessoria de Gestão de Projetos Baixo Equipa de trabalho; Utilizadores da plataforma Bloqueadores Posição Flutuante Campeões 114 Stakeholders Interesses no projeto Impacto no projeto Estratégias para obter suporte ou reduzir oposição Direção de Gestão de Projetos Sucesso do projeto Orientação da equipa de trabalho ao longo do projeto. Fazer o acompanhamento da equipa através de reuniões semanais, de maneira a conseguir realizar uma melhor gestão do projeto, conseguindo assim realizar entregar um bom projeto final. Interlocutor do cliente Plataforma web funcional; Sucesso do projeto Intermediário entre a equipa de trabalho e o cliente final, tendo de garantir uma boa negociação entre ambas as partes, não deixando espaços para más interpretações. Reuniões quinzenais para apresentar o estado do atual do projeto, recebendo assim feedback importante para a continuação do projeto; contacto constante, de maneira a esclarecer pequenas dúvidas que possam surgir. Product Owner Plataforma web funcional; Sucesso do projeto É quem vai usufruir do produto final, sendo este que define qual os requisitos do projeto. Reuniões quinzenais para apresentar o estado do atual do projeto, recebendo assim feedback importante para a continuação do projeto; contacto constante, de maneira a esclarecer pequenas dúvidas que possam surgir. Líder da equipa Sucesso do projeto Fazer a coordenação da equipa de trabalho, de modo a realizar uma gestão de recursos eficaz. Reuniões semanais para coordenação do trabalho a ser desenvolvido pela equipa. Restante equipa Sucesso do projeto Desenvolvimento do projeto. Reuniões semanais para o desenvolvimento do projeto. Timeline & Milestones Figura 31: Timeline & Milestones 115 Recursos e Orçamento Local de trabalho: Universidade do Minho Deslocações: 15€ diários; 28 dias de reunião Custo Total de Deslocações: 420€ Software: Sem custos acrescidos Equipamento: 6 computadores Desgaste dos equipamentos: 0.90€ diários por computador utilizado Duração: 70 dias Custo Total de Equipamento: 378€ Documentos impressos e outros: 50€ Equipa: 6 elementos Recursos Humanos: 7€/h por elemento Duração do projeto: 15 semanas; 15h/semana, que equivale a 9 450€ Custo Total de Recurso Humanos: 10 298€ Restrições Ao definir e planear o projeto foram encontradas restrições inerentes ao mesmo, estando elas apresentadas abaixo e ordenadas por nível de importância. ✓ A equipa de trabalho será constituída por 6 elementos que possuem horários distintos, o que vai condicionar a marcação de reuniões; ✓ Cada elemento do grupo irá dedicar 15 horas semanais, podendo ser acumuladas ou utilizadas nas semanas seguintes; ✓ Cada componente terá uma data de entrega e não poderá ser ultrapassada; ✓ A plataforma será desenvolvida consoante os requisitos e template fornecido pelo cliente. Pressupostos ✓ Pequenas e médias empresas como público alvo, no entanto, esta aplicação pode ter utilidade para qualquer utilizador; ✓ Disponibilidade e comunicação facilitada com cliente durante todo o desenvolvimento do projeto; ✓ Serão utilizadas tecnologias opensource ; ✓ Alojamento da plataforma web é da responsabilidade do cliente; ✓ Acompanhamento semanal do PTSI consulting; ✓ A documentação de apoio será entregue com recurso ao idioma pt-pt. Lista de Riscos No decorrer de qualquer projeto, pode haver situações que ponham em causa ou bom funcionamento do projeto. De modo a conseguir evitar ou atenuar essas situações realizamos uma lista de riscos de modo a equipa ter consciência de riscos de possam acontecer e como agir perante eles. 116 Tabela 25: Lista de riscos Riscos Impacto Probabilidade Estratégia de mitigação Planeamento do projeto mal efetuado 7 5 Fazer uma gestão de recursos e de tempo mais aprofundada, para que o projeto seja realizado nos limites pretendidos. Avaria de alguma das máquinas disponíveis ao projeto 8 2 Ter sempre backups do trabalho realizado até ao momento de maneira a não perder nenhuma informação relevante ao projeto. Atrasos nos prazos de entregas definidos 10 1 Realizar um bom planeamento de projeto, de maneira a que os recursos disponíveis ao projeto, consigam dar uma resposta esperada nos prazos definidos. Falta de conhecimentos para realizar tarefas 9 5 Procurar ajuda especializada que consiga dar o conhecimento necessário para realizar certas tarefas Má relação com o cliente 9 2 Tentar mudar atitudes pejorativas de ambas as partes, de modo que se consiga realizar o projeto num ambiente amigável e de interajuda. Sobrecarga de trabalho devido outras unidades curriculares 5 5 Realizar um bom planeamento de projeto que antecipe estas situações, de modo a saber realizar uma boa gestão de recursos. Falta de informação ou informação mal interpretada segundo os requisitos do cliente 7 6 Preparar antecipadamente as reuniões com o cliente, para que não haja espaço para ambiguidades, e manter o contacto constante com o mesmo para ter a certeza que estamos a desenvolver o que nos foi pedido. Desistência de algum elemento da equipa 10 1 Realizar um bom planeamento de projeto que antecipe erros, de modo a que ao redistribuir tarefas do elemento desistente pelos restantes elementos da equipa, não existe atrasos nas entregas. Má coordenação do trabalho desenvolvido pela equipa 8 3 O líder de equipa deve periodicamente abordar os elementos da equipa para ver o trabalho realizado. Fatores e Critérios de Sucesso Fatores de sucesso ✓ Cumprimentos dos prazos de entregas; ✓ Satisfação das necessidades do lado cliente; ✓ Bom desempenho da equipa de desenvolvimento; ✓ Interesse da equipa de trabalho; ✓ Bom planeamento da totalidade do projeto; ✓ Revisão detalhada por todos os membros da equipa de trabalho. Critérios de Sucesso ✓ Documentação de acordo com o trabalho desenvolvido; ✓ Plataforma dinâmica dos requisitos do cliente; ✓ Plataforma eficaz e escalável; ✓ Plataforma de acordo com a visão do cliente; ✓ Cumprimento de todos os prazos de entrega; ✓ Avaliação positiva pelo cliente do trabalho desenvolvido. 117 ANEXO II – MATRIZ DE STAKEHOLDERS Tabela 26: Matriz de stakeholders do projeto HELP PME PROJECTS Nível de suporte ao projeto Oposição Indiferença Suporte Poder Alto Direção de Gestão de Projetos; Interlocutor do Cliente; Administração da PTSI Consulting; Product Owner Médio Direção Comercial e Financeira; Assessoria de Gestão de Projetos Baixo Equipa de trabalho; Utilizadores da plataforma Bloqueadores Posição Flutuante Campeões 118 ANEXO III - ESTRATÉGIA DE GESTÃO DOS STAKEHOLDERS Tabela 27: Estratégia de gestão dos stakeholders do projeto HELP PME PROJECTS Stakeholders Interesses no projeto Impacto no projeto Estratégias para obter suporte ou reduzir oposição Administração da PTSI Consulting Sucesso do projeto Feedback e avaliação sobre o projeto desenvolvido pela equipa de trabalho. Garantir que todos os objetivos definidos no projeto, sejam alcançados. Assessoria de GP Sucesso do projeto Orientação da equipa de trabalho ao longo do projeto. Garantir que todos os objetivos definidos no projeto, sejam alcançados. Direção Comercial e Financeira Sucesso do projeto Orientação da equipa de trabalho ao longo do projeto. Fazer o acompanhamento da equipa através de reuniões semanais, de maneira a conseguir realizar uma melhor gestão do projeto, conseguindo assim realizar entregar um bom projeto final. Direção de Gestão de Projetos Sucesso do projeto Orientação da equipa de trabalho ao longo do projeto. Fazer o acompanhamento da equipa através de reuniões semanais, de maneira a conseguir realizar uma melhor gestão do projeto, conseguindo assim realizar entregar um bom projeto final. Interlocutor do cliente Plataforma web funcional; Sucesso do projeto Intermediário entre a equipa de trabalho e o cliente final, tendo de garantir uma boa negociação entre ambas as partes, não deixando espaços para más interpretações. Reuniões quinzenais para apresentar o estado do atual do projeto, recebendo assim feedback importante para a continuação do projeto; contacto constante, de maneira a esclarecer pequenas dúvidas que possam surgir. Product Owner Plataforma web funcional; Sucesso do projeto É quem vai usufruir do produto final, sendo este que define qual os requisitos do projeto. Reuniões quinzenais para apresentar o estado do atual do projeto, recebendo assim feedback importante para a continuação do projeto; contacto constante, de maneira a esclarecer pequenas dúvidas que possam surgir. Líder da equipa Sucesso do projeto Fazer a coordenação da equipa de trabalho, de modo a realizar uma gestão de recursos eficaz. Reuniões semanais para coordenação do trabalho a ser desenvolvido pela equipa. Restante equipa Sucesso do projeto Desenvolvimento do projeto. Reuniões semanais para o desenvolvimento do projeto. Utilizadores da plataforma Uso da plataforma É quem irá usar a plataforma Construir uma plataforma apelativa e dinâmica que faça o utilizador a usar. 119 ANEXO IV – MATRIZ DE PERSPETIVA TEMPORAL DOS STAKEHOLDERS Tabela 28: Matriz de perspetiva temporal dos stakeholders do projeto HELP PME PROJECTS Semanas de trabalho Stakeholders 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Administração da PTSI Consulting x x Assessoria de Gestão de Projetos x x x x x x x x x x x x x x x Direção Comercial e Financeira x x x x x x x Direção de Gestão de Projetos x x x x x x x x Interlocutor do Cliente x x x x x x x x Cliente Final x x x x x x x x Líder da Equipa x x x x x x x x x x x x x x x Equipa de trabalho x x x x x x x x x x x x x x x 120 ANEXO V – STAKEHOLDERS VS WORK PACKAGE Tabela 29: Matriz stakeholders vs work-package do projeto HELP PME PROJECTS Semanas de Trabalho Stakeholders Iniciação Planificação Conceção Finalização Administração da PTSI Consulting X X Assessoria de Gestão de Projetos X X X Direção Comercial e Financeira X X X Direção de Gestão de Projetos X X X X Interlocutor do Cliente X X X X Cliente Final X X X X Líder da Equipa X X X X Equipa de trabalho X X X X Utilizadores da plataforma X 121 ANEXO VI – CRONOGRAMA Figura 32: Cronograma geral do projeto HELP PME PROJECTS Figura 33: Cronograma - iniciação do projeto HELP PME PROJECTS Figura 34: Cronograma - planeamento do projeto HELP PME PROJECTS 128 Nome da Tarefa M1 M2 M3 M4 M5 M6 Cliente Sponsor Proponente Administrador Perspetiva Work-package stakehokders R Gestão Temporal Elaborar lista de atividades do projeto R C C Criação do cronograma Elaborar o diagrama de Gantt R R R Definição de milestones R R Definição de dependências entre atividades R R Descrição do cálculo de estimativas R R Descrição do cálculo de reservas R Realizar a gestão do caminho crítico R R Gestão de custo Construção da lista de recursos R R Cálculo estimativo da lista de recursos R R Descrição de reservas R Construção do plano de orçamento R R Perspetiva temporal do custo R Perspetivas work-package do custo R Elaboração do RBS R Entrega da 1ª Versão do plano de projeto R R R R R R Desenvolvimento do Projeto Sprint 1 Planeamento R R R R R R Reunião de planeamento do sprint R R R R R R Distribuição de tarefas R Execução Preparar o layout do website R R Criação de um slide de conteúdo R R Criação da base de dados R R R C C Solicitação de um servidor web R R C C Revisão do sprint R R R R R R Sprint 2 Planeamento Reunião de planeamento do sprint R R R R R R C C Distribuição de tarefas R Execução Criação da funcionalidade login e registar R R Criação do logotipo R R Criação do layout do administrador R R Criação das funcionalidades de administrador R R Revisão do sprint R R R R R R Sprint 3 Planeamento Reunião de planeamento do sprint R R R R R R A C Distribuição de tarefas R A Execução A 129 Nome da Tarefa M1 M2 M3 M4 M5 M6 Cliente Sponsor Proponente Administrador Criação da funcionalidade de criar pergunta R R R A Criação da funcionalidade de criar resposta R R R A Revisão do sprint R R R R R R Sprint 4 A Planeamento Reunião de planeamento do sprint R R R R R R C Distribuição de tarefas R Execução Criação da funcionalidade de adicionar relatórios por utilizador R R Funcionalidade de criar eventos R R Disponibilizar o site em duas versões: Portuguesa e Inglesa R R Revisão do sprint R R R R R R Sprint 5 Planeamento Reunião de planeamento do sprint R R R R R R C C Distribuição de tarefas R Execução Adicionar informação estática R Moldar o layout de maneira a poder ser adaptado a vários ecrãs R R Funcionalidades de restrição a utilizadores sem registo R R Realizar testes às funcionalidades desenvolvidas R Revisão do sprint R R R R R R Finalização do Projeto Rever todo o trabalho desenvolvido R R R R R R Elaboração do Manual de Utilizador R Construção da documentação necessária R R R R R R Entrega dos deliverables ao Cliente R R R R R R C Elaborar Poster final do projeto R A A A A Entrega do Relatório Final R R R R R R A A A A Apresentação do trabalho Final R R R R R R A A A A 130 ANEXO XII – TABELA MAPEAMENTO DOS REQUISITOS Tabela 32: Tabela de mapeamento dos requisitos da HELP PME PROJECTS Funcionalidade Administrador Voluntário Estado Ter o Layout de cores azul, vermelho, laranja ou cinza x 100% Ter a Localização do logotipo no canto superior esquerdo x x 100% Ter a Localização do login/inscrição no canto superior direito x x 100% Ter o Cabeçalho centrado, com as componentes: Página Inicial, Relatórios, Eventos, Sobre Nós, Aba de pesquisa x x 100% Ser adaptável para Tablet e Telemóvel x x 100% Ter versão Inglesa x x 100% Consulta restrita para não inscritos x x 100% Ter um perfil de administrador x x 100% Ter habilitação para a inscrição de vários utilizadores x x 100% Ter a possibilidade de alteração de todos os campos do perfil do utilizador x 100% Possibilidade de escolha por parte do utilizador de acesso à informação não sensível x 100% Dados necessários aquando da inscrição x x 100% Substituição do login pelo nome de utilizador x 100% Ter opção “esqueci a minha palavra-passe” – recuperação por email x x 100% Manutenção e atualização fácil x x 100% Ter links para Normas ISO x x 100% Ter organizações que se debruçam sobre a GP x x 100% Ter informações sobre Projetos financiados pela ANI x x 100% Ter cursos, Pós-graduações e certificações em GP x x 100% Ter informações básicas de GP x x 100% Ter uma página Sobre Nós x x 100% Ter um link para página UE x x 100% Ter contador de temas mais falados x x 100% Ter observatório de sucesso dos projetos das PME x x 100% Ter uma Introdução de eventos por parte de utilizadores e administrador x x 100% Ter um Help-desk automático x x 100% Alertar a notícias relativas a palavras-chave x x 100% Conter um fórum x x 100% Conter ranking dos utilizadores mais participativos x x 100% Ter botão fórum no cabeçalho x x 100% 131 Funcionalidade Administrador Voluntário Estado Ter troca da ordem do carrossel com fórum x x 100% Ter templates base x 100% Ter a possibilidade de enviar mensagem privada para o administrador x 100% Ter perfil específico da organização com livre acesso ao anúncio de eventos x 100% Ter a possibilidade de solicitação pelos utilizadores para anúncio de eventos x x 100% Ter botão no fórum de encaminhamento para inscrição x x 100% Ter forma de criar ou apagar eventos x 100% Ter forma de editar eventos x 100% Ter forma de ver utilizadores x 100% Ter forma de apagar ou editar utilizadores x 100% Ter forma de ver relatórios x 100% Ter forma de apagar ou editar relatórios x 132 ANEXO XIII – TESTES DE CONFORMIDADE Figura 40: Teste de conformidade da plataforma HELP PME PROJECTS 133 ANEXO XIV – LISTA DE RISCOS Tabela 33: Lista de riscos do projeto HELP PME PROJETS Riscos Impacto Probabilidade Seriedade ( P * I ) Potencial Impacto Planeamento do projeto mal efetuado 7 5 35 Atraso no desenvolvimento das etapas seguintes e má coordenação das tarefas na equipa de trabalho Avaria de alguma das máquinas disponíveis ao projeto 8 2 16 Atraso no desenvolvimento das etapas seguintes Atrasos nos prazos de entregas definidos 10 1 10 Atraso na realização das etapas seguintes Falta de conhecimentos para realizar tarefas 9 5 45 Tempo perdido na aprendizagem das tarefas o que pode levar ao insucesso do projecto Má relação com o cliente 9 2 18 Má comunicação entre aquilo que é pretendido pelo cliente o que pode levar ao insucesso do trabalho Sobrecarga de trabalho devido outras unidades curriculares 5 5 25 Insucesso no desenvolvimento das tarefas pedidas e na realização do trabalho. Falta de informação ou informação mal interpretada segundo os requisitos do cliente 7 6 36 Má comunicação entre aquilo que é pretendido pelo cliente o que pode levar ao insucesso do trabalho Desistência de algum elemento da equipa 10 1 10 Sobrecarga de trabalho por parte dos outros elementos da equipa Má coordenação do trabalho desenvolvido pela equipa 8 3 24 Insucesso e atrasos no desenvolvimento do projecto Impossibilidade de reunir pessoalmente 7 1 7 Maior dificuldade em reunir com todos os membros da equipa de trabalho 134 ANEXO XV – RISCOS PERSPETIVA TEMPORAL Tabela 34: Distribuição semanal dos riscos do projeto HELP PME PROJECTS Semanas Atividades 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Planeamento do projeto mal efetuado x x x x x x x x x x x x x x x Avaria de alguma das máquinas disponíveis ao projeto x x x x x x x x x x x Atrasos nos prazos de entrega definidos x x x x x x x x x x x Falta de conhecimentos para realizar tarefas x x x x x x x x x x x x x x x Má relação com o cliente x x x x x x x x x x x x x x x Sobrecarga de trabalho devido outras unidades curriculares x x x x Desistência de algum elemento da equipa x x x x x x x x x x x x x x 135 ANEXO XVI – RISCOS PERSPETIVA WORK-PACKAGE Tabela 35: Perspetiva work package dos riscos do projeto HELP PME PROJECTS Atividades Riscos Iniciação Planeamento Conceção Finalização Planeamento do projeto mal efetuado x x x x Avaria de alguma das máquinas disponíveis ao projeto x x x Atrasos nos prazos de entrega definidos x x x Falta de conhecimentos para realizar tarefas x x x Má relação com o cliente x x x x Sobrecarga de trabalho devido outras unidades curriculares x x x x Desistência de algum elemento da equipa x x x x Impossibilidade de reunir pessoalmente x x x x Falta de informação ou informação mal interpretada segundo os requisitos do cliente x x x Má coordenação do trabalho desenvolvido pela equipa x x x x 136 ANEXO XVII – MATRIZ DE DISTRIBUIÇÃO DO RISCO Figura 41: Matriz de distribuição do risco do projeto HELP PME PROJECTS Impacto Muito baixa Baixa Média Alta Muito alta Probabilidade 0.1 0.25 0.5 0.75 0.9 Muito baixa 0.1 (1) Avaria de alguma das máquinas disponíveis ao projeto; (2) Impossibilidade de reunir pessoalmente; (1) Atrasos nos prazos de entregas definidos; (2) Má relação com o cliente; (3) Desistência de algum elemento da equipa; Baixa 0.25 Má coordenação do trabalho desenvolvido pela equipa; Média 0.5 Sobrecarga de trabalho devido outras unidades curriculares; Planeamento do projeto mal efetuado; Falta de conhecimentos para realizar tarefas; Alta 0.75 Falta de informação ou informação mal interpretada segundo os requisitos do cliente; Muito alta 0.9 137 ANEXO XVIII – AVALIAÇÃO QUANTITATIVA DO RISCO: PERSPETIVA WORK-PACKAGE Tabela 36: Perspetiva work-package do risco do projeto HELP PME PROJECTS ID Nível 1 Risco Momento do Projeto Duração Prevista (horas) Custo Previsto (euros) Impacto Dias Impacto Custo 1 Planeamento do projeto mal efetuado 0.375 Iniciação; Planificação; Conceção e Finalização 5 210 6.875 288.75 2 Avaria de alguma das máquinas disponíveis ao projeto 0.075 Planificação; Conceção e Finalização 72 - 77.4 - 3 Atrasos nos prazos de entregas definidos 0.09 Iniciação; Planificação; Conceção e Finalização 5 210 5.45 228.9 4 Falta de conhecimentos para realizar tarefas 0.45 Iniciação; Planificação; Conceção e Finalização 3 126 4.35 182.7 5 Má relação com o cliente 0.09 Iniciação; Planificação; Conceção e Finalização 4 168 4.36 183.12 6 Sobrecarga de trabalho devido outras unidades curriculares 0.25 Conceção e Finalização 3 126 3.75 157.5 7 Falta de informação ou informação mal interpretada segundo os requisitos do cliente 0.375 Iniciação; Planificação; Conceção e Finalização 4 168 5.5 231 8 Desistência de algum elemento da equipa 0.09 Iniciação; Planificação; Conceção e Finalização - 112,5 - 122.625 9 Má coordenação do trabalho desenvolvido pela equipa 0.1875 Iniciação; Planificação; Conceção e Finalização 3 126 3.5625 149.625 10 Impossibilidade de reunir pessoalmente 0.075 Iniciação; Planificação; Conceção e Finalização 1 42 1,075 45.15