Tcc Nathan Peixoto Oliveira

Transcript

15 Burndown Chart Tasks Remaining UNIVERSIDADE FEDERAL FLUMINENSE ESCOLA DE ENGENHARIA DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO NATHAN PEIXOTO OLIVEIRA MELHORES PRÁTICAS EM GERENCIAMENTO DE PROJETOS PARA A CRIAÇÃO DE UM APLICATIVO PARA VENDA DE LUBRIFICANTES Niterói 2014 nATHAN PEIXOTO OLIVEIRA MELHORES PRÁTICAS EM GERENCIAMENTO DE PROJETOS PARA A CRIAÇÃO DE UM APLICATIVO PARA VENDA DE LUBRIFICANTES Trabalho de Conclusão de Curso apresentado à Univeridade Federal Fluminense como requisito parcial para obtenção do título de bacharel em Engenharia de Produção. Orientador: Prof. Dr. RUBEN HUAMANCHUMO GUTIERREZ Niterói 2014 nathan peixoto oliveira MELHORES PRÁTICAS EM GERENCIAMENTO DE PROJETOS PARA A CRIAÇÃO DE UM APLICATIVO PARA VENDA DE LUBRIFICANTES Trabalho de Conclusão de Curso apresentado à Univeridade Federal Fluminense como requisito parcial para obtenção do título de bacharel em Engenharia de Produção. Aprovada em ____/____/ 2014. BANCA EXAMINADORA _____________________________________ Prof. Dr. Ruben Huamanchumo Gutierrez Universidade Federal Fluminense Orientador _____________________________________ Prof. Dr. Ricardo Bordeaux Rêgo Universidade Federal Fluminense _____________________________________ Prof.ª Dra. Michele Cristina Silva Melo Universidade Federal Fluminense Dedico este trabalho a minha família, que me deu todo suporte e incentivo que precisei durante minha caminhada. AGRADECIMENTOS Dedico este trabalho ao meu orientador, Prof. Dr. Ruben Huamanchumo Gutierrez, pelo compartilhamento sempre paciente e benevolente de sua experiência como acadêmico. À então coordenadora do curso de Engenharia de Produção, Prof. M.ª Maria Helena Campos Soares de Mello, por nos mostrar, enquanto alunos, o caminho para o sucesso acadêmico e profissional com dedicação e por estar sempre presente, no amplo sentido da palavra. A minha colega e supervisora de estágio, Katia da Costa Wendownik, pelo constante compartilhamento de conhecimentos que me ajudou a crescer como pessoa e profissional durante minha formação em engenharia de produção. À Daima Rosa Cabral, por ter confiado indubitavelmente na minha capacidade e potencial, quando cético fui para visualizar. A minha família, por conceder todos os insumos fundamentais a minha formação acadêmica e como cidadão. Obstáculos são essas coisas assustadoras que você vê quando tira os olhos do seu objetivo.  Henry Ford RESUMO O sistema globalizado competitivo demanda uma crescente eficiência dos modelos e ferramentas de gestão. Projetos devem ser executados como frações próprias do tempo utilizado outrora. Adjunto, há uma vasta quantidade de padrões de gestão, muitas vezes mal interpretados, acababando por onerar em tempo, gastos e mão-de-obra. Este trabalho tem, portanto, o objetivo de compilar o que há de melhor nas mais bem conceituadas práticas em gerenciamento de projetos, a fim de: unificar, descomplicar e fazer um diligenciamento mais eficiente. Foram utilizadas bases conceituadas, como: PMBOK® e a gestão ágil da metodologia SCRUM. O estudo de caso foi o desenvolvimento de um projeto para criação de um aplicativo para melhorar a negociação de lubrificantes. Esta, realizada por representantes de uma marca que se posiciona na vanguarda do mercado de óleo e gás internacional: a Shell. Como resultado, ao compará-las frente a onze assuntos, constatou-se que ao fazer uso da primeira metodologia, esta se sobressai em temáticas como grupos de processos e gestão do tempo. Já a segunda, em gestão da integração, do escopo, da qualidade e da comunicação. Por fim, ambas se equipararam em gestão de custos, de RH, de risco, de aquisição e conclusão. Palavras-chave: Gerenciamento de Projetos; PMBOK®; Gestão Ágil; SCRUM; Aplicativo; Lubrificantes; Óleo e Gás; Shell. ABSTRACT The competitive globalized system requires increasing efficiency of the models and management tools. Projects must run as proper fractions of the time erstwhile used. Adjunct, there is a vast amount of management standards, often misinterpreted, ending up burdening time, expense and manpower. This study, therefore, aims to link the very best in the most reputable practices in project management in order to: unify, uncomplicate and make more efficient diligencing. Reputable bases were used, such as PMBOK® and Agile SCRUM management methodology. The case study was the development of a project to create an application to improve the negotiation of lubrificants. This, performed by representatives of a brand that stands in the vanguard of the international oil and gas market: Shell. As a result, by comparing them face to eleven subjects, it was found that by making use of the first methodology, this excels on issues such as groups of processes and time management. The second, in integration management, scope, quality and communication. Finally, both were equivalent in cost management, HR, risk, procurement and conclusion. Keywords: Project Management; PMBOK®; Agile Management; SCRUM; Application; Lubricants; Oil and Gas; Shell. LISTA DE FIGURAS FIGURA 1 – O Ciclo de Vida de Projeto 23 FIGURA 2 - Stakeholders 25 FIGURA 3 – Mapeamento do Fluxo de Projeto 31 FIGURA 4 – Agrupamento do PMBOK® por Assuntos 33 FIGURA 5 – Visão Geral dos Processos de Integração 34 FIGURA 6 – Visão Geral dos Processos de Escopo 35 FIGURA 7 – Estrutura Analítica de Projeto para Software 36 FIGURA 8 – Visão Geral dos Processos de Tempo 37 FIGURA 9 – Visão Geral dos Processos de Custo 39 FIGURA 10 – Visão Geral dos Processos de Qualidade 40 FIGURA 11 – Visão Geral dos Processos de RH 42 FIGURA 12 – Visão Geral dos Processos de Comunicação 43 FIGURA 13 – Visão Geral dos Processos de Risco 44 FIGURA 14 – Visão Geral dos Processos de Aquisição 46 FIGURA 15 – Etapas da Gestão Ágil - SCRUM 50 FIGURA 16 – Reuniões da Gestão Ágil - SCRUM 55 FIGURA 17 – Grupos de Processo da Metodologia do PMI®. 58 FIGURA 18 – Metodologia de pesquisa 65 FIGURA 19 – Ferramenta de Gerenciamento do Estudo de Caso 70 FIGURA 20 – EAP do Estudo de Caso 73 FIGURA 21 – Stakeholders do Estudo de Caso 76 FIGURA 22 – Análise SWOT do Estudo de Caso 78 FIGURA 23 – Reuniões do SCRUM – Estudo de Caso 81 FIGURA 24 – Diagrama dos Processos de Integração – Estudo de Caso 83 FIGURA 25 – Diagrama dos Processos de Escopo – Estudo de Caso 85 FIGURA 26 – Cronograma – Estudo de Caso 86 FIGURA 27 – Diagrama dos Processos de Risco – Estudo de Caso 88 LISTA DE GRÁFICOS GRÁFICO 1 – Grau de Acerto em Projetos 27 GRÁFICO 2 – Nº de Profissionais Ligados ao PMBOK® 28 GRÁFICO 3 – Descrição das Características Pessoais por Grupo de Processo 41 GRÁFICO 4 – Nº de Horas Incompletas - Sprint 54 GRÁFICO 5 – Grupos de Processos do Estudo de Caso 67 GRÁFICO 6 – Burndown Chart do Estudo de Caso 72 GRÁFICO 7 – Interação de Grupos de Processos em um Projeto 82 LISTA DE TABELAS TABELA 1 – Descrição dos Stakeholders 24 TABELA 2 – Escopo Prioritário do SCRUM 53 TABELA 3 – Análise de Metodologias de Gerenciamento de Projeto 57 TABELA 4 – Processos de Integração – Estudo de Caso 82 TABELA 5 – Processos de Escopo – Estudo de Caso 84 TABELA 6 – Processos de Risco – Estudo de Caso 88 LISTA DE ABREVIATURAS E SIGLAS ANSI American National Standard Institute EAP Estrutura Analítica de Projetos HR Human Resources ICAM Indirect Channel Account Manager LTD Limited LTDA Limitada PLC Public Limited Company PMBOK® Project Management Body of Knowledge® PMI® Project Management Institute® PMO® Project Management Office® PMP® Project Management Professional® RH Recursos Humanos ROI Return of Investment SWOT Strengths, Weaknesses, Opportunities and Threats SUMÁRIO 1 INTRODUÇÃO 15 1.1 CONTEXTUALIZAÇÃO 15 1.2 SITUAÇÃO-PROBLEMA 15 1.3 OBJETIVOS 16 1.3.1 Objetivo geral 16 1.3.2 Objetivo específico 16 1.4 DELIMITAÇÃO DO ESTUDO 16 1.5 RELEVÂNCIA DO ESTUDO 17 1.6 QUESTÕES DO ESTUDO 17 1.7 HIPÓTESES 18 1.8 ORGANIZAÇÃO DO ESTUDO 18 2 REVISÃO DA LITERATURA 20 2.1 O PROJETO 20 2.1.1 Definição 20 2.1.2 Gerenciando projetos 21 2.1.3 Stakeholders 23 2.1.4 Características do project owner 25 2.1.5 Facilidades da gestão de projetos 26 2.2 O GUIA DE GERENCIAMENTO DE PROJETOS DO PMI® 28 2.2.1 Definição 28 2.2.2 Como é organizado? 30 2.2.3 Divisão por áreas 32 2.2.4 Visão geral dos processos de integração 33 2.2.5 Visão geral dos processos de escopo 35 2.2.6 Visão geral dos processos de tempo 37 2.2.7 Visão geral dos processos de custo 38 2.2.8 Visão geral dos processos de qualidade 39 2.2.9 Visão geral dos processos de RH 40 2.2.10 Visão geral dos processos de comunicação 42 2.2.11 Visão geral dos processos de risco 44 2.2.12 Visão geral dos processos de aquisição 45 2.3 SCRUM: ORIGEM 47 2.4 SCRUM: O QUE É? 48 2.4.1 SCRUM: etapas 50 2.4.2 SCRUM team: responsabilidades 51 2.4.3 SCRUM: documentação 53 2.4.4 SCRUM: reuniões 55 2.5 COMPARAÇÃO ENTRE AS METODOLOGIAS 56 2.5.1 Quanto aos grupos de processos 58 2.5.2 Quanto à integração 59 2.5.3 Quanto ao escopo 59 2.5.4 Quanto ao tempo 59 2.5.5 Quanto ao custo 60 2.5.6 Quanto à qualidade 60 2.5.7 Quanto ao RH 61 2.5.8 Quanto à comunicação 61 2.5.9 Quanto ao risco 62 2.5.10 Quanto à aquisição 62 2.5.11 Quanto à conclusão 62 3 METODOLOGIA 64 4 ESTUDO DE CASO 66 4.1 A ROYAL DUTCH SHELL PLC 66 4.2 A SHELL BRASIL PETRÓLEO LTDA 66 4.3 O PROJETO: PMBOK® X SCRUM 66 4.3.1 Quanto aos grupos de processos 67 4.3.2 Quanto à integração 69 4.3.3 Quanto ao escopo 73 4.3.4 Quanto ao tempo 74 4.3.5 Quanto ao custo 74 4.3.6 Quanto à qualidade 74 4.3.7 Quanto ao RH 75 4.3.8 Quanto à comunicação 75 4.3.9 Quanto ao risco 78 4.3.10 Quanto à aquisição 79 4.3.11 Quanto à conclusão 80 5. RESULTADOS 81 6. CONCLUSÃO E RECOMENDAÇÕES 90 6.1 CONCLUSÃO 90 6.2 TRABALHOS FUTUROS 90 7. REFERÊNCIAS BIBLIOGRÁFICAS 92 8. ANEXOS 95 INTRODUÇÃO CONTEXTUALIZAÇÃO Com ciclos de vida cada vez mais curtos, a arquitetura, os serviços, os produtos e principalmente a tecnologia se renovam cada vez mais rápido. Desta forma, a gestão de projetos deve ser cada vez mais dinâmica e enxuta. Todavia, há uma grande quantidade de conteúdos, ferramentais e metodologias sobre como diligenciar de forma otimizada. Aliado a isso, a falsa compreensão pode se posicionar como um entrave para o gestor de projetos. Tem-se proposições notáveis de como gerenciar projetos de diferentes graus de complexidade. A exemplo, o PMI® apresenta um metódico guia conhecido mundialmente: o PMBOK®. E com o mesmo intuito de facilitar, à medida que prioriza a velocidade das decisões, surge o manifesto ágil em 2001 com diversas metodologias (MARÇAL et al. , 2007), sendo o SCRUM a escolhida para compor o estudo, em função da sua também difusão e facilidade de uso. Desta forma, se faz necessário entender, comparar, testar e comprovar o que há de melhor em ambas, de forma a gerar processos mais produtivos. SITUAÇÃO-PROBLEMA De forma mais específica, pode-se notar a existência de metodologias mais amplas, todavia, com uma grande quantidade de paradigmas, e outras mais dinâmicas e ágeis, porém, com baixa quantidade de registros ou documentos comprobatórios a título de possível auditoria. Para compor o primeiro caso, pode-se citar a terceira edição do PMBOK®, onde existem 44 processos documentados em meio a cinco grupos de processos (PMI®, 2004). Sua vasta gama de ferramentais quando seguida à risca, sem a devida noção de particularidade para cada projeto, pode onerar em tempo a equipe do projeto. Já modelos ágeis como o SCRUM, objetivam tomar decisões em poucos instantes, reduzem drásticamente a quantidade de material produzido durante um projeto, sendo considerados mais enxutos. É o que os criadores do SCRUM chamam de processo simples para gerenciar projetos complexos (SCHWABER, 2004).Todavia, existe uma diminuição na quantidade de registros a fim de obter uma maior velocidade, o que pode dificultar processos comprobatórios futuros. Ainda que não sejam excludentes e que ambos possam ser seguidos de forma simultânea, uma das maiores dificuldades para administradores de pessoas, bens e serviços, reside na deficiência de como compreender as metodologias supracitadas, guiar-se e adaptar o melhor de ambas aos seus projetos, sem que estes tenham seus tempos de execução comprometidos. OBJETIVOS Objetivo geral O intuito deste trabalho consiste em comparar duas das principais metodologias de gerenciamento, auxiliando equipes a melhor compreender e selecionar o que de melhor cada uma tem a oferecer para que se adapte a cada cenário que se possa encontrar. Objetivo específico O presente trabalho pretende, através de um estudo de caso, atestar que, ao ter um maior conhecimento sobre as metodologias aqui apresentadas e ao fazer um uso otimizado de seus recursos, é possível economizar uma série de insumos, tais como: tempo, capital e mão-de-obra. DELIMITAÇÃO DO ESTUDO Guiou-se e restringiu-se a analisar duas metodologias: o PMBOK®, umas das mais difundidas no mundo e o SCRUM, que abriu portas para os demais modelos de gestão ágil de projetos. Além disso, a fase experimental do trabalho limitou-se ao estilo generalista brasileiro de trabalhar. Podendo não ser adaptável a certas culturas laborais, como por exemplo, caso haja inflexibilidade por tradicionalidade organizacional, reatividade a melhorias e mudanças, como as propostas nesta pesquisa e outras possíveis particularidades atípicas que possam ir de encontro a práticas aqui fomentadas. RELEVÂNCIA DO ESTUDO A confecção deste trabalho é principalmente destinada a alunos de engenharia de produção e áreas afins, profissionais da área e aos que fazem o uso deste apenas como incremento de cultura. A leitura deste, permite uma melhor compreensão crítica e analítica das metodologias de gerenciamento aqui presentes, além de um melhor discernimento de suas utilidades e limitações, para que se possa fazer um melhor uso das mesmas. Além disso, será possível ter uma melhor gestão do tempo, de maneira producente e otimizada. Espera-se que processos e recursos sejam melhor utilizados e que desperdícios sejam amplamente minimizados. QUESTÕES DO ESTUDO Este material pretende responder as seguintes questôes: como é feita uma gestão pelo PMBOK®? como é feita uma gestão pelo SCRUM? quais as diferenças entre as metodologias PMBOK® e SCRUM? quais as vantagens e desvantagens em ambas metodologias? como deveria ser feita uma gestão de forma otimizada? quais vantagens são possíveis de se obter através da forma otimizada de gestão de projetos? HIPÓTESES Este material assume como pressuposto que, ao conhecer melhor as metodologias de projeto aqui apresentadas e ao se guiar por elas de forma consciente, adotando as melhores práticas de ambas, pode-se reduzir desperdícios. ORGANIZAÇÃO DO ESTUDO O presente trabalho será dividido em seis capítulos, conforme descrito abaixo. No primeiro capítulo, introdução, é feita a contextualização, define-se a situação-problema, os objetivos gerais e específicos, a delimitação, relevância, questões que serão respondidas e hipótese adotadas. Já no segundo capítulo, revisão da literatura, é feita a familiarização com o conhecimento dentro da área de estudo, procedimentos adotados em outras pesquisas, bibliografias principais e secundárias utilizadas e serão confrontadas as principais teorias a cerca de uma gestão eficiente de projetos. É nesta fase também em que é construída a primeira moldura conceitual para a interpretação dos resultados da investigação. O terceiro capítulo apresentará a metodologia, onde estarão presentes as seguintes etapas: seleção de um modelo teórico: escolha de um modelo pertinente; definição das etapas a serem seguidas: definição de um sequenciamento de etapas a ser adotado e detalhamento das etapas previstas: descrição analítica do modelo racional escolhido O quarto capítulo consistirá em um estudo de caso, que será realizado em uma empresa de óleo e gás que será devidamente apresentada: a Shell Brasil Petroleo LTDA. Serão postos a prova diversos recursos do PMBOK® e SCRUM de forma a validar a sua eficiência durante a gestão de um projeto de criação de um aplicativo que melhora a negociação durante a venda de lubrificantes para veículos automotores. Já no quinto capítulo, resultados, estes são levantados em função do uso de ambas metodologias no estudo de caso apresentado. Assim como o levantamento daquela de maior aderência para diferentes temáticas que serão abordadas. Por fim, no sexto capítulo, conclusão, serão feitas as considerações finais sobre o trabalho e a análise das questões inicialmente expostas no primeiro capítulo. Propostas de trabalhos futuros também serão feitas, indicando objetos de estudo através de problemas identificados, mas não explorados neste trabalho por não ser a sua proposta. REVISÃO DA LITERATURA O PROJETO Irão ser tratados preceitos básicos de projetos, tal como sua definição etimológica, o conceito de gestão de projetos e suas facilidade e o significado de stakeholders e project owner. Definição Conforme é relatado no PMBOK® (2004), projeto é um esforço temporário para gerar um produto, serviço ou resultado exclusivo. Braga (2003) diz que o projeto é um produto realizado por uma equipe e que o mesmo possui início, meio e fim. Além disso, possui aspectos únicos, tais como seus objetivos, alvos, despesas e processos de qualidade. Stanleigh (2005) diz que o projeto é um conjunto de etapas programadas e monitoradas por prazos, requisitos e limitações para alcançar um fim específico. Diz também que aquele se trata de um processo não cíclico, ou seja, possuirá uma etapa de encerramento bem especificada. Kerzner (2007) relata que o projeto é um esforço que é gerido sobre parâmetros, tais como qualidade, tempo e gastos. Aquele, por sua vez, necessita de insumos para alcançar um objetivo que foi identificado em seu princípio. O autor afirma também que a etapa de definição de suas características define assuntos como atividades a serem desempenhadas, como funcionará, processos a serem realizados, a missão e objetivo do projeto e, esses assuntos, variam de projeto para projeto. Martins (2003) define projeto como o intuito de se realizar algo através de operações temporárias e diferenciáveis a cada um. Isto é dito, pois possuem aspectos e condições nas quais são conduzidos de caráter univalente, o que os diferem de processos cíclicos e permanentes. Para Vargas (2009), nada mais é do que um empreendimento que não se repete, com eventos em linha de forma lógica. Todos eles com início, meio e fim, para que se alcance uma finalidade. É gerenciado por um capital humano que o conduz dentro de parâmetros pré-estabelecidos, a exemplo do custo, qualidade, tempo e insumos pertinentes à realização do mesmo. Cleland e Ireland (2007) escrevem que o projeto se constitui pelo arranjo de insumos, que em conjunto e em harmonia, possibilitada por um bom planejamento, consegue não só criar e desenvolver algo alcançando um fim préviamente inexistente, mas contribuem para atingir um melhor desempenho. Para gerar-se um projeto, é necessário que haja insumos fazendo o papel de inputs, limitações como controladores de qualidade e pessoas trabalhando em conjunto. Todavia, é necessário mais do que isso, tais como inovações, inteligência emocional para o tabalho em grupo e a personificação do project owner. Este por sua vez, deve ser responsável pelo arranjo, coordenação do projeto e otimização não apenas dos processos, mas da equipe em sí. Deve, portanto, identificar qualidades individuais e extrair o melhor de cada membro do time de projeto. A competência profissional do time incubido das atividades do projeto é um outro aspecto bastante relevante para o alcance dos objetivos. Pois contribuem para melhorias e novas técnicas mais eficazes. Uma forma de tornar o meio mais fértil e propenso a aperfeiçoamentos, é estimular o comprometimento e geração de novas ideias. Não se pode coibir opiniões e a criatividade humana, mas sim fomentá-las e concectá-las ao negócio e a estratégia da empresa. Gerenciando projetos Claramente é definido e dividido o gerenciamento de projetos no PMBOK® da seguinte forma: O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento (PMI®, 2004, p.8). Já Braga (2003), relata o gerenciar projetos como diligenciar os seguintes temas: qualidade, custo, escopo e tempo; expectativas e exigências dos stakeholders (partes interessadas) e atender aos requisitos identificados ou não. Martins (2003) diz que gerir projeto se trata de aplicar know-how (conhecimento), know-why (técnica) e meios (ferramentas) para operar de forma ótima processos de projeto. O conhecimento é gerado por materiais ou pela prática e faz com que se otimizem as etapas de projeto. Para Vargas (2009), trata-se de um ferramental gerencial permissivo de desenvolvimento de técnicas, conhecimento e capacidades para cada membro da equipe de projeto. Aquele, por sua vez, volta-se a controlar etapas não repetitivas, univalentes e com grau de complexidade, aderindo-se a restrições de custo, tempo e qualidade estabelecidos previamente. As fases do projeto são estipuladas para delimitar atividades pertinentes a determinadas finalidades dentro do projeto. O PMI® (2004) estipula um ciclo de vida para o projeto, definindo seu início e seu fim, descrevendo e agrupando atividades por fase de projeto para melhor gerencia-lo. O ciclo de vida existe também para, além de melhor acompanha-lo, definir para cada etapa, um conjunto de processos que controlem a qualidade do projeto. Desta forma, reduz sua chance de erros e fracassos. Vargas (2007) lista alguns benefícios reconhecidos pelo uso do ciclo de vida de um projeto, tais como: conhecimento das atividades realizadas e não realizadas; compreensão do progresso do projeto e entendimento da posição exata do projeto. Atribui-se a cada projeto a necessidade de um maior ou menor detalhamento de seu ciclo de vida. Na primeira hipótese, são criados documentos, gráficos e checklists – documentos de conferência – para maior controle. O ciclo de vida do projeto, segundo o PMI® (2004) e conforme a Figura 1 pode ser dividido em três fases: inicial, intermediária e final. A primeira caracteriza-se pela entrada de ideias e da equipe de projeto, criação do termo de abertura e declaração de escopo. Já a segunda, pelo plano, definição de uma linha base de diligenciamento de projeto , progresso e aceitação do mesmo. Por fim, a ultima fase corresponde a aprovação do fato gerado e a sua entrega. Figura 1: O Ciclo de Vida de Projeto. Fonte: PMBOK®, 2004. Stakeholders Stakeholders, também entitulados como partes interessadas; segundo o PMI® (2004), são indivíduos e entidades envolvidos no projeto e cujo interesse pode ser afetado com o resultado do projeto. Com base no PMBOK® (2004), cria-se a Tabela 1, descrevendo-se cada integrante participante do grupo de stakeholders do projeto. Tabela 1: Descrição dos Stakeholders Fonte: PMBOK®, 2004. As partes interessadas de um projeto incluem todos os participantes, inclusive o seu gerente. O patrocinador, por sua vez, possui participação de suma importância, chegando a ser, na sua ausência, impeditiva. A sua relevância consiste no financiamento e apoio a criação do projeto dentro da empresa. O time de gestão necessita apontar os stakeholders, atribuindo a cada, suas exigências e necessidades. Além de monitorar sua importância para atender os requerimentos do projeto para que tenha sucesso. Na Figura 2, são descritas as partes interessas enquanto integrantes do projeto. Figura 2: Stakeholders. Fonte: PMBOK®, 2004, p. 25. Stakeholders podem influenciar o projeto de forma positiva ou negativa. No primeiro caso, servem de benefício ao resultado do projeto, enquanto, no segundo, tem um papel crítico, com observância de consequências negativas no êxito do mesmo (PMI®, 2004). Características do project owner Ao project owner, também conhecido como gerente de projetos, é atribuída a função de assegurar os objetivos do projeto. Dentre suas características, as marcantes que pode-se destacar é o senso de líder, trabalho em conjunto com uma ampla diversidade de indivíduos (tecnicamente e comportamentalmente), aplicação de conhecimentos e boa comunicação interpessoal. Para Martins (2003), as características mínimas para se adequar ao cargo de gerente de projetos consistem em dominar conceitos de gerência, aplicabilidade dos mesmos e boa prática. Seu papel é cada vez mais importante à medida que gerenciar processos, pessoas e recursos ganha espaço nas organizações. Sendo este cargo e suas disponibilidades de vaga bastante promissoras dentro do cenário moderno atual, vindo cada vez mais a valorizá-lo. Martins (2003) diz que ao escolher pessoas capacitadas a ocupar cargos, associa-se diretamente ao sucesso do projeto, sendo este passo fundamental. A escolha errada de profissionais para ocupar a cadeira de gerentes de projeto onera em custo, as fases são entregues fora do tempo determinado e diminui-se a qualidade dos processos devido às lacunas de conhecimento e prática não preenchidas. Facilidades da gestão de projetos Para Martins (2003), gerir projetos com eficácia fez com que este papel fosse destacado no meio corporativo. Atingir metas, prazos e orçamentos foram determinantes para tal e, hoje, sabe-se que é possível ter aderência a vários tipos de negócio e grau de complexidade. Segundo Martins (2003), as facilidades propiciadas pela gestão eficiente de projetos são: gestão de custos, insumos e prazos, elencando previamente riscos e determinando planos contigenciais mitigantes. Desta forma, correções são feitas a tempo e fracassos são severamente reduzidos; integridade da equipe e boa fluência de informações, ideias, documentos etc; o risco é controlado e a qualidade é assegurada e o projeto é executado conforme requisitos e pode-se esperar geração de capital em detrimento àquele que foi investido. A Standish Group realizou uma pesquisa que diz que em 2008, 24% dos projetos resultam em fracasso, 44% resultam em algum tipo de atraso ou prejuízo e 32% resultam em sucesso. O Gráfico 1 mostra a evolução dos percentuais de sucesso, atraso e falhas desde 1994 até 2008. Gráfico 1: Grau de acerto em projetos Fonte: Standish Group, CHAOS Summary for 2010 e Extreme CHAOS. Sotille (2014) diz que o projeto, para resultar em sucesso, deve agir conforme o planejamento. Mesmo a utilização de recursos aquém do previsto, que pode até mesmo soar como economia, significa que os insumos foram superavaliados, logo, houve uma falha no planejamento. Sendo assim, o bom conhecimento de gestão é cada vez mais bem apreciado e o uso de certificados que comprovem esta habilidade em projetos é cada vez mais requisitado. PMP® (Project Management Professional) é a certificação comprobatória de qualificação segundo a metodologia do PMBOK®, impostas pelo PMI® a fim de atuar como gerente de projetos. No Gráfico 2, pode-se observar a evolução de associados ao PMI® no mundo desde 1984 até o ano de 2006. Gráfico 2: Nº de Profissionais ligados ao PMBOK® Fonte: http://www.ietecnet.com.br/pmp/credenciados.asp Objetivos como prazo, orçamento, grau de desempenho e gestão de incertezas do escopo são preponderantes para o sucesso de um projeto. Tais como feedback do cliente e adequação à cultura da empresa (TORREÃO, 2005). Uma das grandes vantagens do gerenciamento de projetos diz respeito ao grau de complexidade do mesmo. Vargas (2007) conta que se faz indiferente com relação ao tamanho do projeto. Sendo grande ou não, a metodologia a ser seguida é prevalecida e pode ser aplicada a empreendimentos de ampla diversidade. O GUIA DE GERENCIAMENTO DE PROJETOS DO PMI® Será abordado nesta parte do trabalho o guia de gerenciamento de projetos desenvolvido pelo PMI® entitulado PMBOK®. Irá ser abordada sua definição, seus procesos e suas áreas de conhecimento. Definição O guia de gerenciamento de projetos PMBOK® é a reunião de conhecimentos e práticas publicadas pelo Project Management Institute®, preponderante referência para companhias em aperfeiçoamento de processos e certificado pela ANSI - American National Standard Institute (NARDI, 2009). O PMBOK® aponta, na referência abaixo, seu objetivo central: O principal objetivo do Guia PMBOK® é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. "Identificar" significa fornecer uma visão geral, e não uma descrição completa. "Amplamente reconhecido" significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. "Boa prática" significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico.(PMI®, 2004, p.3). A história do PMBOK® tem início no ano de 1987. Com inúmeras citações positivas deferidas ao PMI®, foi realizada uma nova publicação. Com melhorias no esqueleto da metodologia, inclusões em cada processo, terminologias, aumento do limite de abordagem e portfólio, foi criada a terceira edição no ano de 2004. Atualmente, está na sua quinta versão, publicada em 2013 onde pequenas alterações foram concebidas, apenas de forma incremental e não mais nos seus fundamentos principais. Tornou-se até então um guia adotado em diversas partes todo mudo, notóriamente um dos mais completos e mais versáteis. A metodologia PMBOK® deve ser empregada como um acompanhador, aprovisionando gerentes de diversas possibilidades para realizar um projeto bem sucedido. Não deve ser interpretado como um roteiro de mão única, mas sim interpretado e adequado a diferentes tipos de projetos. O PMBOK® (2004) é segmentado em três seções: estrutura, normas e áreas de conhecimento. Seção 1: trata de como é a estrutura de gerenciamento de projetos. É dado uma estrutura fundamental a fim de compreender o gerenciamento de projetos. Seção 2: trata da norma para gerenciar projetos. Detalha quais são os processos para gerenciar projetos e como são usados pela equipe. Seção 3: trata das áreas de conhecimento ao gerenciar projetos. São apresentados 44 processos de como gerenciar projetos através de grupos bem definidos de processos. O PMBOK® (2004) delimitas seus processos em grupos principais. São eles: iniciação, planejamento, execução, monitoramento e controle, e por fim, encerramento. São definidas também áreas de conhecimento: integração, escopo, tempo, custo, qualidade, RH, comunicação, risco e aquisição. Como é organizado? São definidos 44 processos, presentes em cinco grupos e nove áreas de conhecimento de gerenciamento de projetos conforme consta no PMBOK® (2004). De acordo com o mesmo, pode-se descrever processo como sendo "um conjunto de ações e atividades inter-relacionadas(...)para obter um conjunto pré-estabelecido de produtos, resultados ou serviços" (PMI®, 2004, p. 38). Na Figura 3, pode-se observar de forma abreviada, os cinco grupos de processo que fazem parte da metodologia PMBOK®, assim como as nove áreas de forma concomitante, a fim de gerar uma visão estratégica dos assuntos. Deve-se salientar que a forma de fluxograma não traduz necessáriamente a obrigação em seguir etapas de forma consecutiva. Ordens podem ser reformuladas, assim como pode haver simultaneidade de ações a serem tomadas. Trata-se apenas de um diagrama ilustrativo para facilitar a compreensão dos processos. Figura 3: Mapeamento do Fluxo de Projeto. Fonte: elaborada pelo próprio autor. A metodologia no PMBOK® (2004) descreve os processos e seus grupos da seguinte forma: grupo de iniciação: são descritas as etapas pertinentes ao projeto e permite-se a execução do mesmo; grupo de planejamento: é definido o escopo e como seguirá o roteiro do mesmo, além dos objetivos e seus respectivos meios para alcança-los selecionando as melhores alternativas disponíveis; grupo de execução: gerencia-se insumos e pessoas para a realização do projeto em questão; grupo de monitoramento e controle: garante o cumprimento de objetivos, regula o progresso e as distorções com relação ao plano de gerenciamento de projeto estabelecido previamente. E, a tempo, realiza os devidos acertos para o bom andamento do projeto e grupo de encerramento: São documentados os resultados, o aceite e diligencia-se o projeto a um fim organizado. Divisão por áreas O gerenciamento de projetos se divide em nove áreas de conhecimento que são retratadas em síntese, conforme a Figura 4. Em cada uma daquelas são agrupados processos corretamente correlacionados, segundo consta no PMBOK® (2004). O entendimento das nove áreas do PMBOK® é fundamental para acarretar em um desfecho positivo para o projeto. Desta forma, relatam-se a seguir as mesmas e seus grupos de processos. Figura 4: Agrupamento do PMBOK® por Assuntos. Fonte: PMBOK®, 2004, p. 11. Visão geral dos processos de integração Os processos de integração são encarregados de atestar que cada elemento do projeto esteja sendo gerenciado da forma correta. Neles identificam-se, definiem-se, combinam-se, unificam-se e coordenam-se as atividades de gerenciamento de projetos (PMI®, 2004). Processos de integração intuitam-se prepoderantemente em atestar que as oito demais áreas estejam conjuntas, para que o projeto como um todo permita atender seus stakeholders (VARGAS, 2009). Na Figura 5, apresenta-se uma visão sintética dos processos que compõem a área de integração. Figura 5: Visão Geral dos Processos de Integração. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 22. Desenvolver o termo de abertura do projeto: trata-se de um documento que aprova categoricamente o projeto. Possibilita também gerentes de projetos a usar insumos da companhia para assegurar o andamento do projeto. Nele é relatado preponderantemente as necessidades das partes interessadas e a justificativa do projeto (PMI®, 2004); Escopo preliminar: é a descrição macro do escopo do projeto; Plano de gerenciamento: são inseridas as atividades necessárias para gerir todos os planos auxiliares de gerenciamento do projeto; Orientar e gerenciar a execução: refere-se a executar as atividades definidas pelo plano de gerenciamento. Este processo sofre grande influência da área de aplicação do projeto; Monitorar e controlar o trabalho: monitora e controla os diversos processos de início, planejamento, execução e encerramento. Aderindo-se a objetivos estipulados pelo plano de gerenciamento; Controle integrado de mudanças: identifica, controla, revisa, gerencia e faz o diligenciamento das mudanças, permitindo-as de fazerem parte do projeto ou reprimindo-as. Este processo é realizado do princípio ao fim do projeto e Encerrar o projeto: consiste na finalização de todas as atividades e grupos de processos de gerenciamento de projetos, e posteriormente o encerramento formal do projeto por completo. Visão geral dos processos de escopo Os processos de escopo referem-se ao conjunto de atividades imprescindíveis para que o projeto se conclua. Neles serão definidas atividades incorporadas ou não no projeto, tal qual sua administração (PMI®, 2004). A gestão do escopo intuita-se preponderantemente na definição e fiscalização das atividades do projeto (VARGAS, 2007). Na Figura 6, ilustram-se os processos desta área. Figura 6: Visão Geral dos Processos de Escopo. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 26. Planejamento do escopo: trata-se da geração do plano de gestão do escopo do projeto, com o intuito de subdividi-lo e organizá-lo. Analisa-se também sobre a criação da estrutura analítica do projeto, também denominada EAP; Definição do escopo: trata-se do detalhamento de todas as atividades principais para entregar o projeto segundo seus requisitos e aspirações. Este documento, por sua vez, fornece um panorama dos esforços necessários dentro do tempo estimado a todas as partes interessadas, orientando o time executor; Estrutura analítica do projeto: trata-se da divisão do esforço que será executado durante o projeto de forma organizada a fim de garantir um melhor gerenciamento do mesmo. Da mesma forma que subdivide-se, o escopo é passível de ser visto na íntegra através do EAP (Figura 7); Figura 7: Estrutura Analítica de Projeto para Software. Fonte: PMBOK®, 2004, p. 116. Verificação do escopo: trata-se de um documento formal onde serão encontradas as entregas que foram confirmadas e não confirmadas, adjunto ao motivo do segundo caso e Controle do escopo: trata-se da gestão de mudança no escopo, com o objetivo de manipular o reflexo que as mesmas possam gerar no projeto. Visão geral dos processos de tempo Segundo Vargas (2007), o custo e o tempo são os fatores mais destacáveis e observados em um gerenciamento de projeto. Isso se deve ao fato de iniciantes que queiram adentrar neste universo, quererem reduzir aqueles 2 gatilhos de sucesso ou fracasso de projetos. A Figura 8 relata os processos de gerenciamento do tempo, denomidados: definição da atividade, sequenciamento de atividades, estimativa de recursos da atividades, estimativa de duração, desenvolvimento do cronograma e controle do cronograma. Figura 8: Visão Geral dos Processos de Tempo. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 29. Definição da atividade: trata-se da identificação e documentação das atividades do cronograma, produzindo as entregas do projeto; Sequenciamento de atividades: trata-se da identificação e documentação da subordinação das atividades do cronograma; Estimativa de recursos da atividade: trata-se da aproximação da quantidade e tipificação dos insumos necessários ao cronograma; Estimativa de duração da atividade: trata-se da aproximação das horas requeridas para conclusão de atividades do cronograma, a estimativa da quantidade de insumos requeridos para sua finalização e a quantidade de períodos de ofício que irá se requerer; Desenvolvimento do cronograma: trata-se da verificação dos insumos requeridos, limitações no cronograma, tempo utilizado e a continuidade de atividades necessárias para gerar-se o cronograma de projeto. É definido também o começo e fim das atividades, com possível realocamento de tempo e insumo e constituindo um cronograma que irá ser levado para aprovação e irá ser constituido como um guia para o projeto e Controle do cronograma: trata-se da gestão de mudança no cronograma do projeto. Visão geral dos processos de custo O intuito dos processos de custo é atestar que o projeto seja encerrado dentro do limitante de orçamento. Estipulações do orçamento do projeto devem ser produzidas pelos realizadores do projeto. Este, por sua vez, só irá ser iniciado quando a orçamentação for aprovada, conforme relata o PMI® (2004). Vargas (2007) diz que o gerenciamento de custo tem como intuito preponderante atestar capital acessível e considerável para que as tarefas do projeto tenham insumos suficientes. Na Figura 9, pode-se observar os processos de gestão de custo. Figura 9: Visão Geral dos Processos de Custo. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 33. Estimativa de custos: trata-se da produção de aproximação de custos para que se encerre cada atividade de projeto; Orçamentação: trata-se da agregação dos custos aproximados das atividades para definição do custo total de projeto e Controle de custos: trata-se da contenção de aspectos variantes no custo e das alterações de orçamento de projeto. Visão geral dos processos de qualidade Segundo o PMI® (2004), os processos de qualidade intuitam-se preponderantemente em atender o cliente, precaver-se de falhas e garantir o aperfeiçoamento contínuo dos processos. Na figura 10, ilustram-se os processos de qualidade. Figura 10: Visão Geral dos Processos de Qualidade. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 36. Planejamento da qualidade: objetiva assinalar modelos de qualidade expressivos para o projeto e como realizá-los; Realizar a garantia da qualidade: trata-se do deferimento de atividades de qualidade premeditadas para assegurar que o projeto detém processos suficientes para atender as exigências e Realizar o controle da qualidade: trata-se da gestão de resultados de projeto com o objetivo de definir se estão condizentes com os modelos de qualidade e retirar as causas do mau desempenho. Visão geral dos processos de RH Vargas (2007) afirma que ao gerenciar o RH, objetiva-se preponderantemente em fazer com que indivíduos participantes do projeto, tenham o melhor desempenho possível. O time de projetos deve ter grande contribuição nas escolhas durante o mesmo, pois ativa um maior comprometimento, confome é dito no PMBOK® (2004). Levando em conta que custos variam bastante durante os cinco grupos de processo de projeto, recursos humanos são demandados em diferentes especialidades de acordo com cada um. Dependerá da tipagem de trabalho a ser desempenho e do grau de senhoridade da equipe de projeto. No Gráfico 3, apresentam-se os diferentes tipos de especialidades demandadas em função dos cinco grupos de processo de projeto. Gráfico 3: Descrição das Características Pessoais por Grupo de Processo Fonte: Manual Prático do Plano Do Projeto, 2007, p. 38. A administração do RH contém quatro processos preponderantes, como por exemplo, o planejamento de RH, controle e mobilização de equipe de projeto, desenvolvimento de equipe e gerenciamento dessa. Na figura 11 é possível observar os processos de RH de um projeto. Figura 11: Visão Geral dos Processos de RH. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 39. Planejamento de RH: trata da enumeração e registro da atribuição, incubência e relações de hierarquia de projeto, adjunto a um plano de gerência; Contratar ou mobilizar a equipe do projeto: intuita-se em garantir capital humano suficiente até o término de um projeto; Desenvolver a equipe do projeto: trata de assegurar um aperfeiçoamento das competências e interação do time de projeto para garantir melhor aproveitamento e desempenho e Gerenciar a equipe do projeto: trata de acompanhar a performance do time de projeto, garantindo feedback, solução de conflitos e gestão de mudança. Visão geral dos processos de comunicação Diz-se no PMBOK® (2004) que estes processos são imprescindíveis para que se assegure que as informações sejam produzidas, capturadas, transmitidas, armazenadas, reavidas e que tenham destino dentro de um projeto. Esta administração de comunicação é importante para atestar que pessoas e informações formem um par perfeito. Sendo também importante para que o gerente de projeto garanta a integridade de sua equipe quanto ao seu trabalho e para que se possa dissolver qualquer tipo de problema durante a execução das fases de projeto. De acordo com Vargas (2007), nas companhias a comunicação tem de ser visualizada como ferramental de crescimento. O escoamento de informações requer comunicações rápidas e assertivas, sendo um dos aspectos dominantes para o resultado positivo do projeto. Segundo o PMI® (2004), o gerenciamento da comunicação é dividido em quatro processos fundamentais, tais como, o planejamento, distribuição, relatório de desempenho e gerenciamento das partes interessadas. A Figura 12 apresenta aqueles processos referidos. Figura 12: Visão Geral dos Processos de Comunicação. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 43. Planejamento das comunicações: o objetivo consiste em definir as carências de comunicação e informação dos stakeholders; Distribuição das informações: trata-se da disposição de informações importantes às partes interessadas participantes do projeto em questão em um momento oportuno para as mesmas; Relatório de desempenho: seu intuito predominante consiste em capturar e transmitir informações a respeito da performance do projeto. Isto é feito através de relatórios de acompanhamento com mensuração do progresso e de sua predição. Nesses documentos podem ser computados os insumos utilizados para obtenção dos objetivos, o escopo do projeto e suas considerações, o cronograma e as informações de custo e de qualidade do projeto e Gerenciar as partes interessadas: trata-se da administração de informações para garantir o atendimento às exigências das partes interessadas, além de solucionar os problemas destas. Este trabalho ajuda o projeto a perseguir seus objetivos sem desencaminhamentos por razão de problemas com os stakeholders. Visão geral dos processos de risco VARGAS (2007) afirma que a gestão de riscos permite que se compreenda melhor o tipo de projeto, atraindo membros do time a escalonar riscos que possam surgir e que estão comumente ligados à qualidade, custo e tempo. Já o PMI® (2004), diz que a administração de riscos tem como finalidade determinante o alargamento das chances de eventos positivos ocorrerem, assim como reduzir as chances de eventos negativos no projeto. Riscos são gerados por diferentes origens, sendo por exemplo, motivados pela falta de indivíduos habilitados a realizar alguma atividade específica do projeto. O PMBOK® divide a área de gestão de riscos por meio de seis processos mostrados na Figura 13. Figura 13: Visão Geral dos Processos de Risco. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 46. Planejamento do gerenciamento de riscos: defini-se pela decisão de abordagem, planejamento e execução das tarefas de gestão de riscos; Identificação de riscos: trata-se da identificação e registro das características dos riscos passíveis de prejudicar o projeto; Análise qualitativa dos riscos: trata-se da priorização e análise das chances de ocorrer riscos e de seus reflexos. É realizada através de modelos de priorização de riscos apontados por análise qualitativa; Análise quantitativa dos riscos: trata-se da atribuição numérica a riscos elencados nos objetivos gerais do projeto; Planejamento de respostas a riscos: trata-se da produção de alternativas e atividades de acréscimo de oportunidades e de redução de ameaça a objetivos do projeto e Monitoramento e controle dos riscos: trata-se da assistência a riscos levantados e da execução de outras análises de novos riscos que possam prejudicar os objetivos do projeto. Visão geral dos processos de aquisição Para o PMI® (2004), os processos de aquisição são aqueles essenciais para que se possa obter produtos, serviços ou resultados extrínsecos a equipe de projeto para o bom funcionamento das atividades. Os processos de aquisição apresentam técnicas que permitem que se compre produtos ou certo serviço característico de forma que o projeto se prossiga. O gerenciamento daqueles necessita de diligenciamento de contratos e de suas alterações. Além de ser necessário que se faça a gestão de pedidos de compra emitidos pelo time de projeto. Na Figura 14, pode-se verificar um quadro ilustrativo dos processos de aquisição. Figura 14: Visão Geral dos Processos de Aquisição. Fonte: Manual Prático do Plano Do Projeto, 2007, p. 50. Planejar compras e aquisições: refere-se a identificação de elementos para compra, além da temporalidade para a mesma e de como será feita. O estudo de compra aponta que elementos de projeto são atendidos com uma determinada aquisição. Nele também se faz a inclusão de fornecedores, em especial se o indivíduo da compra queira influenciar ou controlar a contratação; Planejar contratações: refere-se ao registro de exigências de produtos e serviços, com a finalidade de elencar fornecedores potenciais e requerer respostas deles. O ferramental e as técnicas usadas no processo tem, por exemplo, o uso de descrição padronizada de itens, checklist para avaliar propostas, consultoria técnica especializada, contratos, além de documentos de licitação e Solicitar respostas de fornecedores: se refere ao processo de retirar cotação, informação, propostas e ofertas de fornecedores cadastrados ou potenciais. Incluem-se reuniões com fornecedores reais ou potenciais e licitantes, para que todas as partes tenham clareza dos requisitos do projeto e para que haja comum acordo sobre a aquisição do bem ou serviço. SCRUM: ORIGEM A história do desenvolvimento ágil começa nos anos 90, quando um time de dezessete profissionais experientes em processos para se desenvolver software se encontram nos Estados Unidos da América, em uma estação de esqui. A reunião teve como objetivo possibilitar a produção e desenvolvimento de métodos que permitam uma melhoria de desempenho de projetos (SOARES, 2008). A reunião ficou conhecida como "Aliança Ágil" e, a partir da mesma, o manifesto ágil teve começo, tendo como preceitos: indivíduos e interações em detrimento de ferramentas e processos; contribuição do cliente em detrimento de transação de contratos e respostar rápidas a alterações em detrimento de planos. Soares (2008) relata que os modelos ágeis são novas possibilidades frente a metodologias tradicionais. Estas devem ser aplicadas unicamente a projetos com exigências atuais estáveis e futuras que possam ser previsíveis. Já em projetos de mudanças de requisitos contínuas e times consideravelmente pequenos de projetos, a gestão ágil é mais indicada. Agilidade, para Soares (2008), se trata de uma resposta a problemas e situações de maneira expressa e consistente, unindo-se time de projeto e clientes. Desta forma, estes acabam por participar constantemente da geração do projeto. A gestão ágil, compôs doze fundamentos para quem deseja trabalhar com este tipo de metodologia, tais quais: a prioridade é satisfazer ao cliente através de entregas de software de valor contínuas e freqüentes; entregar softwares em funcionamento com freqüência de algumas semanas ou meses, sempre na menor escala de tempo; ter o software funcionando é a melhor medida de progresso; receber bem as mudanças de requisitos, mesmo em uma fase avançada, dando aos clientes vantagens competitivas; as equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente durante todo o projeto; manter uma equipe motivada fornecendo ambiente, apoio e confiança necessário para a realização do trabalho; a maneira mais eficiente da informação circular dentro da equipe é através de uma conversa face a face; as melhores arquiteturas, requisitos e projetos provêm de equipes organizadas; atenção contínua à excelência técnica e um bom projeto aumentam a agilidade; processos ágeis promovem o desenvolvimento sustentável. Todos envolvidos devem ser capazes de manter um ritmo de desenvolvimento constante; simplicidade é essencial e em intervalos regulares, a equipe deve refletir sobre como se tornarem mais eficazes e então se ajustar e adaptar seu comportamento. (Reinert, 2008, p.3). Através dos fundamentos acima, metodologias existentes deram início a expansão. O estudo aqui desenvolvido tem como objetivo analisar uma em especial, o SCRUM. Assim como sua compreensão, aspectos e técnicas utilizadas. SCRUM: O QUE É? O modelo ágil para gerenciar projetos desenvolvido por Ken Schwaber e Jeff Sutherland é denominado SCRUM. Esta metodologia tem como preceito criar processos de repetição incremental para fazer a gestão de qualquer operação. Desenvolver com base na equipe e nas iterações cíclicas de curta duração é o foco do SCRUM (SCHWABER, 2004). Marçal et al. (2007) afirma que o SCRUM pode ser definido como um modelo que se destina a cenários inconstantes, ou seja, sujeitos a mudanças repentinas. Ele se sobressai pelo enfoque dado a gerenciamento de projetos. Além disso, adota processos de controle, feedback e encontros dinâmicos com o time de projetos para possíveis correções de processos. O SCRUM é usado em projetos de diferentes dimensões, tanto de pequeno quanto de grande porte, sendo conveniente o uso em projetos complexos. É bastante usado naqueles com requisitos mutáveis ao seu decorrer (SCHWABER, 2004). É apresentado no SCRUM, uma série de técnicas e normas que quando aplicadas, servem para atestar êxito a um projeto. Aquelas são voltas para que haja um time integrado com boa comunicação, onde a performance de cada indivíduo é potencializada (SCHWABER, 2004). Existe uma nomenclatura característica usada na gestão ágil SCRUM, conforme destaca Schwaber (2004): product backlog: conjunto de atividades a serem desempenhadas ao longo do projeto; sprint: período relativo a um mês ou menos onde são realizadas atividades de incremento ao produto final; sprint planning meeting: reunião na qual é feito o planejamento da sprint; sprint review meeting: reunião onde é feito a revisão do que foi realizado na sprint; sprint retrospective: reunião de inspeção própria e de proposta de melhorias; sprint backlog: conjunto de tarefas a serem feitas durante a sprint para criar um resultado; daily SCRUM: reunião diária; development team: time responsável pelo incremento no produto final em cada término da sprint; SCRUM team: reunião do product owner, development team e SCRUM master; SCRUM master: gerente do projeto, sem que haja uma hierarquia sobre os demais membros da equipe e product owner: dono do produto (ou serviço). O SCRUM segundo Pereira et al. (2007), é utilizado em casos imprevisíveis, com grau elevado de complexidade, fornecendo um quadro de trabalho como um modelo de melhores práticas de gestão de projetos. SCRUM: etapas Na Figura 15, mostra-se o ciclo de vida do SCRUM. Figura 15: Etapas da Gestão Ágil – SCRUM. Fonte: Elaborada pelo próprio autor. Na sprint planning Meeting, que precede o acontecimento da sprint, é realizada uma reunião de planejamento, na qual desenvolvedores interagem com clientes, que neste caso são os product owners e definem o trabalho e as atividades a serem executadas durante a sprint com a presença do SCRUM master (PEREIRA et al., 2007). Na próxima etapa, a de execução da sprint, o time de desenvolvimento coordena o percurso de desenrolamento do projeto, com cumprimento de reuniões diárias (daily SCRUM meeting), prolongadas a extremos quinze minutos. O SCRUM master remove qualquer empecilho que possa haver, tornando a equipe autogerenciável. O andamento do projeto é acompanhado no gráfico burndown chart que será mostrado mais a frente. No término da sprint é feita uma reunião de reavaliação, a sprint review, onde são apresentados resultados de acordo com o que foi requerido e listado no product backlog, contando com a participação de todo o SCRUM team, afirma Pereira et al. (2007). A sprint retrospective é realizada em seguida e se trata de uma reunião para retomar o que foi feito na sprint e o que pôde ser tomado como aprendizado para melhorar na próxima sprint, não contando com a presença do product owner (PERREIRA et al., 2007). SCRUM team: responsabilidades Pereira et al. (2007) diz que o SCRUM elabora um processo repetitivo e de incremento, onde as partes interessadas são subdivididas em grupos (três): development team, SCRUM master e product owner, com atribuições e senso de integração para contribuirem com o sucesso do projeto. É conferido à figura do product owner os interesses dos participantes do projeto, esse não precisa ter total entendimento da metodologia de gestão, mas sim do esforço a ser desempenhado durante o projeto. Aquele tem de participar do time e estar presente nas reuniões de planejamento e revisão (sprint planning meeting e sprint review), objetivando cooperar com a escolha das tarefas que serão antepostas na sprint. Pereira et al. (2007) diz que, além de subdividir o trabalho a ser realizado e ordenar e priorizar as tarefas do product backlog, o product owner tem outras funções, dentre elas, pode-se citar a: definição das exigências do produto, definindo quando será a entrega e suas caracterísitcas finais; garantia de ROI (Return of Investment – Retorno sobre investimento); priorização das exigências conforme cenário e valor de mercado; alteração das exigências e preferências por sprint e confirmar ou reavaliar entregas da sprint. Adjunto, temos outra peça chave do SCRUM, conhecida como SCRUM master. Define-se como o indivíduo que desempenha sua função exclusivamente com o time de projetos. Sendo fundamental que esse garanta que o SCRUM esteja sendo bem aplicado no projeto. O time enxerga-o como o grande conhecedor sobre a metodologia, que resolve qualquer dubiedade ou contratempo na aplicação do modelo de gestão com a equipe, conforme relata Magno (2008). Magno (2008) diz que suas principais funções são: possibilidar a independência de gerência do time; permear uma boa troca de informação dentro do time garantindo que o canal esteja aberto e fluido; auxiliar o time na condução das práticas da metodologia SCRUM; retirar todo tipo de contratempo que possa ocorrer e defender o time de interferências vindas de fora que comprometam a sua eficiência no projeto. O development team é o grupo responsável pela execução do projeto, com no máximo, nove profissionais trabalhando conjuntamente para que se atendam os requisitos do product backlog. Pereira et al. (2007) diz que as responsabilidade do development team são: definir dentre as prioridades, as que participarão da sprint; autoridade plena de mudança para atender aos objetivos, organizar o trabalho desempenhado pelo time e apresentar os resultados ao final de cada sprint. SCRUM: documentação Os documentos gerados pelo SCRUM são artefatos para melhorar o entendimento do projeto, assim como seus prazos e modo de execução. Dentre eles, podemos citar o product backlog, a sprint backlog e o burndown chart. Pereira et al. (2007) diz que o product backlog é a chave do SCRUM. Tratando-se de uma sequência de tarefas por ordem de prioridade que traduz tudo o que deve ser feito no projeto de valor de negócio ao cliente. Essa priorização é feita antes do início da sprint pelo product owner. O product backlog não necessita ser preciso e inteiro antes que o projeto se inicie, pois há uma constante mudança em seu percurso (PEREIRA et al. , 2007). Na Tabela 2 em seguida, pode-se observar uma amostra de um product backlog. Onde, como forma de classificar cada tarefa que compõe sua respectiva sprint, indicou-se por "S" que a mesma foi satisfeita, "NS" que não foi satisfeita e "PS" que foi parcialmente satisfeita. Além disso, para cada iteração foi definido um objetivo principal que sintetizasse o lugar em que se queria alcançar após concluir as atividades enumeradas. Tabela 2: Escopo prioritário do SCRUM Fonte: Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI, 2007, p. 6. O sprint backlog é outro documento importante na metodologia SCRUM. É nada menos do que a reunião das atividades que serão realizadas na sprint. O development team e o product owner definem quais tarefas do product backlog devem ser elencadas para fazerem parte do sprint backlog. Pereira at al. (2007) observa que para cada atividade da sprint, a equipe define o tempo de duração estimado, sem que transpasse o valor máximo de dezesseis horas. Pereira et al. (2007) diz também que o time se auto-questiona diversas vezes quanto a garantia da atividade a ser cumprida e, se a sprint como um todo poderá ser conduzida da forma estabelecida. Este questionamento é realizado até todas as atividades da sprint backlog serem revisadas. Encerrando, tem-se o burndown chart, descrito como um gráfico representativo contendo o número de horas incompletas para que se encerre a sprint. Seu objetivo principal é demonstrar o progresso e velocidade na qual os esforços são realizados. Deste modo, pode-se apontar uma queda no ritmo na sprint e indicar uma possível solução para o problema. Na sequência, está representado no Gráfico 4 o burndown chart. Gráfico 4: Nº de Horas Incompletas – Sprint. Fonte: Entendendo o SCRUM para Gerenciar Projetos de forma Ágil, 2007. SCRUM: reuniões As reuniões, também conhecidas como cerimônias do SCRUM, são realizadas durante todo o projeto. A finalidade é permitir acompanhamento, gestão e boa performance do time, encontrando possíveis problemas. Existem vários tipos de reuniões, totalizando um número de quatro, são elas: sprint planning meeting, daily SCRUM meeting, sprint review e sprint retrospective. Cada cerimônia possui uma intenção característica, assim como o momento em que deve ser executada (PEREIRA et al., 2007). Na Figura 16 são representadas as reuniões do SCRUM. Figura 16: Reuniões da Gestão Ágil – SCRUM. Fonte: elaborado pelo próprio autor. A sprint planning - reunião de planejamento – é aquela feita no começo da sprint, seu tempo de duração é cerca de 8 horas, tendo como propósito definir o que será realizado, podendo ser subdividida em sprint planning 1 e 2 (4 horas cada). Devem se apresentar na mesma o product owner, SCRUM master e development team. A daily SCRUM meeting por sua vez, é uma cerimônia realizada todo dia (em seu início ou término). Sua finaldiade é integrar e difundir o que foi feito aos participantes, assim como as dificuldades encontradas e as que estarão por vir (PEREIRA et al., 2007). Pereira et al. (2007) diz que é ideal que a daily SCRUM seja feita no mesmo período do dia, preferencialmente de manhã para que se possa organizar as tarefas do dia de trabalho. Nesta cerimônia, deve constar a presença de todos do time responsáveis pelo incremento no produto, sem que seja usada como solucionadora de problemas - o que extenderia deveras sua duração - , pois é preferível que seja feito por um composto de pessoas reduzido. No daily SCRUM, os participantes devem responder três perguntas: o que você fez ontem? o que você fará hoje? há algum impedimento no seu caminho? A sprint review é uma outra reunião do SCRUM que é realizada no término da sprint, onde é mostrado o que foi feito durante essa etapa. Expressam-se os resultados do projeto obtidos até então, contando com a presença do development team, SCRUM master e product owner. A sprint retrospective, reunião realizada também no término da sprint, é uma cerimônia responsável por relatar fragilidades e pontos fortes encontrados na sprint. Assim como são apontadas as medidas de melhoria. COMPARAÇÃO ENTRE AS METODOLOGIAS O capítulo faz uma panorama entre os modelos abordados neste estudo: o tradicional e o ágil, representados respectivamente pelo PMBOK® e pelo SCRUM. Serão apontadas diferenças e similaridades entre ambos. Na Tabela 3 seguinte, são representadas as principais disparidades entre as metodologia tradicional e ágil. Tabela 3: Análise de Metodologias de Gerenciamento de Projetos ABORDAGEM TRADICIONAL ABORDAGEM ÁGIL Preditivo: detalhar o que ainda não é bem conhecido. Adaptativo: Conhecer o problema, resolver antes questões críticas. Rígido: seguir especificação predefinida a qualquer custo. Flexível: adaptar-se a requisitos atuais, que podem mudar. Burocrático: controlar sempre para alcançar o objetivo. Simplista: fazer algo simples agora e alterar se necessário. Orientado a processos: podem garantir a qualidade. Orientado a pessoas: motivadas e comprometidas. Documentação gera confiança. Comunicação gera confiança. Sucesso corresponde a entregar o planejado. Sucesso corresponde a entregar o desejado. Gerenciamento no estilo comando e controle voltado para o trabalho em massa. Gerenciamento no estilo liderança/orientação, voltada para trabalhadores do conhecimento. Ênfase: papel do gerente, planejamento e disciplina fortes. Ênfase: criatividade/flexibilidade e atenção às pessoas. Desenvolvedor hábil (variedade). Desenvolvedor ágil (colaborador). Cliente pouco envolvido. Cliente comprometido (com autonomia para decidir). Requisitos conhecidos e estáveis. Requisitos emergentes e mutáveis. Retrabalho / reestruturação caros. Retrabalho / reestruturação baratos. Planejamento direciona resultados (incentiva controlar). Resultados direcionam planejamento (incentiva mudar). Conjunto de processos com metodologia definida. Conjunto de valores com atitudes e princípios definidos. Premia a garantia da qualidade. Premia o valor rápido obtido. Foco: projetos grandes ou que envolvam restrição de confiabilidade (exigem mais formalismo). Foco: projetos de natureza exploratória e inovadores, com equipes pequenas / médias (exigem maior adaptação). Objetivo: controlar em busca de alcançar o objetivo planejado (em termos de tempo,custo e escopo). Objetivo: simplificar processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos. Responsabilidade recai Sobre o processo da organização (menos suscetível a falhas) Responsabilidade recai sobre o envolvimento e a experiência dos membros da equipe. Foco na maturidade, decorrente da definição e uso de processos e modelos de maturidade. Foco na disciplina, seguindo valores, princípios e boas práticas documentados na literatura. Foca em questões ligadas ao gerenciamento, tanto de projeto quanto de processo. Foca em questões ligadas ao trabalho técnico e valor agregado ao produto (resultado). Institucionalização de processos é crucial: definidos, escritos, treinados, praticados, controlados e cobrados. Utilização das práticas é crucial: princípios e boas práticas devem ser levadas ao extremo. Abordagem mais profunda para gerência de projetos. Abordagem ainda superficial para gerência de projetos. Fonte: elaborada pelo próprio autor. Irão ser analisadas nas seguintes seções as principais comparações entre o PMBOK® e o SCRUM: análise dos ciclos de vida, de suas particularidades à luz das 9 áreas de conhecimento do PMBOK® (2004) e quanto as suas condição de encerramento do projeto. Quanto aos grupos de processos O PMBOK® possui cinco grupos de processos concomitantes (iniciação, planejamento, execução, monitoramento e controle e encerramento) e é o time de projeto que indica as técnicas e o ferramental que serão usados no projeto. Além também das atividades, participantes, controle e aprovação de condições (PMI®, 2004). Já no SCRUM, o projeto começa com um planejamento (sprint planning 1 e 2), onde são definidos o product backlog e sprint backlog, logo após, é realizado o desenvolvimento do projeto, divido em várias sprints com constante monitoramento e controle (daily SCRUM, sprint review e sprint retrospective). Após as iterações da sprint o produto é entregue. Desta forma, embora os grupos de processos do SCRUM não sejam bem esclarecido pelos criadores do mesmo e vários autores enumerem de forma diferente, pôde-se encontrar quatro bem definidos na metodologia: o de planejamento, monitoramento e controle, execução ou desenvolvimento e entrega. Na figura 17, pode-se observar os grupos de processos do PMBOK® (2004). Figura 17: Grupos de Processo da Metodologia do PMI®. Fonte: PMBOK®, 2004, p. 40. Quanto à integração Na metodologia PMBOK®, integração refere-se a todo esforço necessário para estabelecer, executar, controlar e integrar todos os processos durante a gestão de um projeto, sendo de total responsabilidade do gerente (PMI®, 2004). Quanto ao SCRUM, a forma de criar, executar, monitorar e integrar todas as atividades de projeto é através das reuniões. Elas não só definem, garantem e integram todos os processos, mas os atestam, já que nesta metodologia comunicação em detrimento de documentação, gera confiança. O gerente é o SCRUM master, que apenas facilita e diminui o número de obstáculos do projeto, sendo esse de responsabilidade de todo SCRUM team. Quanto ao escopo No PMBOK®, o escopo é detalhado no início do projeto para que o esforço seja compatível exatamente às atividades elencadas. Sua gestão é feita através de ferramentas padrão e processos, com documentação registrada que servirá de base para a gestão de mudanças durante o projeto (PMBOK®, 2004) No SCRUM, o escopo também é detalhado, mas é constantemente reavaliado durante todo o projeto. Sua função é a de melhorar o entendimento do projeto por parte de todas as partes interessadas, inclusive o cliente (product owner), que também o define, discute e aprova o mesmo. Quanto ao tempo O tempo e sua gestão é semelhante para ambos, tanto para o PMBOK®, quanto para o SCRUM. No primeiro, é realizado através de um cronograma detalhado, com suas estimativas de duração, participantes e atividades (PMI®, 2004). No caso do SCRUM, também existe acompanhamento temporal, todavia, orientado ao produto resultante de uma iteração, com presença do product owner que dita a ordem de preferência das atividades de cada repetição (SCHWABER, 2004). Quanto ao custo No PMBOK®, a gestão de custos tem o intuito de atestar que o projeto conclua conforme o orçamento definido. As mudanças manifestadas ao longo da etapa de desenvolvimento do projeto são decisivas e abalam-o por inteiro, desta forma, há uma aproximação de custos de insumos suficientes para concluir as tarefas do projeto. O ponto está no controle, monitoramento e documentação das alterações de modo que não impliquem no custo planejado no começo do projeto (PMI®, 2004). Já no SCRUM, mudanças podem ser feitas independente da etapa do projeto, desde que aprovadas pelo cliente. Pois nessa metodologia há uma grande preocupação em atender as expectativas daqueles. Desta forma, pode sofrer intensas mudanças para que se atendam os requisitos estabelecidos, até mesmo onerando o valor previamente estabelecido, desde que todas as partes estejam de acordo com o custo adicional. Quanto à qualidade Neste tema, ambas metodologias são parecidas, o SCRUM e o PMBOK® concordam com a relevância no planejamento da qualidade, com o intuito de atestar satisfação ao cliente. A diferença está em como assegurar e gerir a qualidade. No caso do PMBOK®, a gestão da qualidade é concentrada na geração de um plano em função de requisitos pré-estabelecidos e na sua averiguação e aprovação. Processos de gestão da qualidade objetivam preponderantemente monitorar e controlar a qualidade e os proventos do projeto e atestar que estes condizam com exigências do cliente, dentro do padrão de qualidade. Referindo-se ao SCRUM, a gestão da qualidade também é feita em todo o projeto, isso porque este é gerado de forma incremental por repetição e provas são realizadas a todo momento. A cada sprint review, os clientes verificam as entregas conforme especificações e, a cada sprint retrospective, melhoram os processos usados na sprint, onde boas práticas são mantidas e as demais aperfeiçoadas. Quanto ao RH Nesta temática, ambas metodologias são similares, todavia, com especificidades. No PMBOK® responsabilidades dos indivíduos devem ser bem definidas, além de serem cruciais pois cada indivíduo é orientado por processos para executar suas funções. A gestão de recursos humanos diligencia e organiza o time, elencando e registrando suas responsabilidades, além de ter uma hierarquia bem definida. O planejamento de recursos humanos no PMBOK® visa organizar e gerenciar a equipe, identificando e documentando as funções, responsabilidades e as relações hierárquicas entre seus integrantes, proporcionando o melhoramento da interação e a performance dos membros do time. Na metodologia SCRUM, a co-participação dos membros do time é primordial no projeto. Planejar e decidir são em conjunto, é comum a todos, tudo é compartilhado e qualidades podem ser complementadas pelos demais membros, todos podem fazer um pouco de tudo e não há restrição para que toda equipe tenha o mesmo grau de conhecimento. Basta apenas que se tenha habilidades suficientes para cumprir as tarefas do product backlog que foram estabelecidas. Quanto à comunicação Neste campo, o PMBOK® e o SCRUM são discordantes. No primeiro, gerenciar comunicação é formal e deve ser registrado, anunciado e acompanhado conforme transcorre o projeto. O intuito preponderante para essa metodologia, é a documentação com fim comprobatório, evitando conflitos entre o time de projeto. Já no caso do SCRUM, a gestão ágil traz aperfeiçoamentos na comunicação, assim como no convívio entre participantes. O feedback é contínuo, aberto e direto durante toda a geração do projeto e é menos formal. A comunicação participativa está presente nas reuniões diárias, nas de divulgação do produto incremental, nas de revisões e melhorias e em todo projeto. No SCRUM, pela falta de formalimos e diferente do que se observa na metodologia PMBOK®, há um maior tangenciamento e envolvimento das partes do projeto, todavia, deve haver inteligência emocional como uma habilidade que evite conflitos. O ponto de convergência das metodologias reside no fato de ambas registrarem assuntos discutidos de importância para definição de atividades, melhorias ou para prosseguimento no fluxo do projeto. Quanto ao risco Neste quesito, ambos modelos são próximos, tanto no PMBOK® como no SCRUM, as etapas do projeto referentes a riscos são comuns. No PMBOK®, realiza-se um plano formal, assegurando identificar, analisar qualitativamente e quantitativamente, planejar respostas, monitorar e controlar aqueles no decorrer do projeto. No SCRUM, os mesmos processos são feitos constantemente ao longo das reuniões. Durante a sprint planning é feito o planejamento do gerenciamento e das respostas aos riscos, sua identificação e análise; na daily SCRUM e sprint review os riscos são monitorados; já na sprint retrospective acontece o monitoramento e controle daqueles. Quanto à aquisição No PMBOK®, aquisições partem do escopo e documentos minunciosamente detalhados e definidos, para que haja um controle dos processos. Há então contratos entre fornecedores e o time de projeto registrando o que foi acordado. Já no SCRUM, em função de alterações contínuas no escopo, as aquisições por contrato não são mencionadas. Não há detalhamento, portanto, do processo de aquisição de mercadorias e serviços em função do dinamismo de uma gestão ágil. Quanto à conclusão No PMBOK®, projetos são finalizados somente quando todas as entregas são concluídas e devidamente documentadas. Já no caso do SCRUM, o encerramento do projeto acontece quando todos os requisitos do product backlog forem atendidos . METODOLOGIA A metodologia desenvolvida está baseada na análise de informações que comprovem a hipótese previamente apontada neste estudo. A opção adotada foi o estudo de caso, devido ao interesse em analisar dados reais e trabalhar uma situação-problema em que fosse possível sugerir melhorias para implementação prática. Segundo Bressan (2000), o estudo de caso é "uma inquirição empírica que investiga um fenômeno contemporâneo dentro de um contexto da vida real", no qual os comportamentos relevantes não podem ser manipulados, mas onde é possível se fazer observações diretas e entrevistas sistemáticas. O autor diz ainda que esta metodologia se caracteriza pela "capacidade de lidar com uma completa variedade de evidências – documentos, artefatos, entrevistas e observações". Segundo Yin (1994), o estudo de caso é uma abordagem metodológica de investigação especialmente adequada quando procuramos compreender, explorar ou descrever acontecimentos e contextos complexos, nos quais estão simultaneamente envolvidos diversos fatores. Para o autor, é permissivo compreender melhor através da verificação/transposição para o mundo real. E é realizado de acordo com as seguintes fases: preparação do trabalho; escolha da informação; seleção e tratamento da informação e análise dos resultados. Levando em consideração a distribuição acima apresentada este trabalho obedeceu às fases abaixo relacionadas. Elaborou-se a contextualização (justificativa para o trabalho), situação-problema, objetivos (geral e específico), delimitação, relevância, questões a serem respondidas hipóteses e metodologia do estudo. Foi feita uma revisão de literatura, abordando as boas práticas de gerenciamento de projetos, clarificando e confrontando a metodologia PMBOK® com a gestão ágil SCRUM. De posse da revisão de literatura feita e estipulou-se e justificou-se a metodologia de pesquisa. Por se tratar de um estudo de caso, a pesquisa teve por objetivo levantar situações reais e gerar conhecimento de forma a responder a questões específicas levantadas. Buscou-se ratificar as melhores práticas levantadas das duas metodologias supracitadas, objetivando otimização dos processos e redução de desperdícios no projeto. Após fase de testes foram apresentados os resultados da análise feita e suas conclusões. A Figura 18 abaixo ilustra a proposta metodológica adotada. Figura 18: Metodologia de Pesquisa. Fonte: elaborada pelo próprio autor. ESTUDO DE CASO A ROYAL DUTCH SHELL PLC O grupo Anglo-holandês de atuação global foi formado pela fusão entre a Royal Dutch Petroleum Company e a Shell Transport and Trading Company Ltd em 1907. Seu campo de atuação é o setor de energia e petroquímica com cerca de 92.000 empregados em mais de 70 países e territórios. Fonte: http://www.shell.com. A SHELL BRASIL PETRÓLEO LTDA Presente no Brasil desde 1913 – mais de 100 anos – emprega cerca de mil pessoas e atua no ramo de upstream (exploração e produção) e downstream (distribuição), sendo este último feito em parceria com a Raízen, empresa formada pela joint-venture entre a Shell e a brasileira Cosan. Fonte: http://www.shell.com. O PROJETO: PMBOK® X SCRUM O projeto pode ser definido como a criação de um aplicativo para facilitar a negociação e diligenciamento da venda de lubrificantes. O mesmo pretende servir como ferramenta a representantes de venda da Shell Brasil Petróleo - na figura de distribuidores - para que possam: ter informação de venda na palma da mão; acelerar os processos e reduzir a zero desistências de compra motivadas pela demora. Teve-se como intuito realizar o diligenciamento do projeto através das duas metodologias - PMBOK® e SCRUM a fim de comparar e testar suas performances ao longo de um caso real. A programação e as demais questões técnicas do aplicativo não foram relatadas por não se tratarem de assuntos relevantes para o tema do trabalho. Adjunto, toda essa abordagem foi tercerrizada na figura da empresa parceira, responsável pela criação da ferramenta. Quanto aos grupos de processos Levando em consideração os cinco grupos do PMBOK®, organizou-se da seguinte forma: Gráfico 5 : Grupos de Processos do Estudo de Caso Fonte: PMBOK®, 2004. iníciação: coincidiu com a escolha e abertura do projeto a ser gerenciado, além da escolha das partes interessadas. planejamento: nesse momento, detalhou-se o escopo, cronograma, objetivos, entregáveis, template das atas de reunião – conforme ANEXO 6 - e dos questionários, estimou-se o orçamento, criou-se a EAP (estrutura analítica de projeto) e gerenciou-se os riscos com base na análise SWOT. execução: foram criados junto com a equipe do projeto, os processos atuais e ideais para a venda de lubrificantes de acordo com as expectativas das partes interessadas. monitoramento e controle: foram acompanhadas através de reuniões de feedback a qualidade e a performance do projeto. Além disso, através de questionários, obtiveram-se insumos para que fosse possível realinhar o escopo e melhorar a elaboração do processo ideal. encerramento: o projeto foi formalmente encerrado, assim como registraram-se as lições aprendidas com o mesmo. Já seguindo na metodologia SCRUM, os seguintes grupos foram criados: planejamento: durante a reunião de sprint planning foram criados o product backlog, com escopo de todo projeto e os sprint backlogs, com o escopos referente a um mês de trabalho cada, conforme ANEXO 3; execução (ou desenvolvimento): neste, os diversos sprint backlogs foram executados com reuniões semanais até a extinção de todo o product backlog. monitoramento e controle: o acompanhamento da execução do projeto era feito através de reuniões semanais (o daily SCRUM passou a ser weekly SCRUM), onde era atribuído um "feito" ou "não feito" para cada tarefa restante do sprint backlog. Além disso, a quantidade de tarefas faltantes eram acompanhadas pelo burndown chart (Gráfico 6). Foram realizadas ao final de cada sprint uma única reunião onde eram contempladas a sprint reviews e a sprint retrospective. O objetivo era avaliar o que foi feito, principais dificuldades, assim como pontos de sucesso. entrega: realizou-se uma reunião de apresentação dos resultados. Diferente das reuniões de controle, esta teve como objetivo, relatar de modo sintético o projeto como um todo. Nela, comentou-se sobre o desenvolvimento das atividades ao longo das diversas sprints, e com teor conclusivo, apresentaram-se os entregáveis frente ao que era esperado, assim como os pontos fortes e a melhorar encontrados no projeto. Quanto à integração Seguindo os preceitos do PMI®, o desenvolvimento do termo de abertura do projeto conforme (anexo 1) teve como objetivo formalizar a existência do mesmo para que pudesse ser alocado recursos para seu desenvolvimento. Além disso, foram elencados dentre outros: sponsor (representado na figura do mentor e do supervisor): responsáveis por arcarem com os custos possíveis do projeto em seu centro de custo e aprovar o mesmo. O processo de aprovação se deu conforme análise de possíveis projetos (anexo 2); ponto focal de RH (representado na figuro do HR contact); tempo de duração do projeto (project duration); entregáveis (project deliverables) e relevância (relevance to business). Como forma de auxiliar o termo de abertura, todavia, desta vez de maneira mais detalhada, foi criado o documento de Identidade do Projeto (ANEXO 5), onde eram descritas suas informações básicas e eram listados o conjunto de artefatos (documentos) que o compõe. O plano de gerenciamento do projeto envolveu uma ferramenta em excel que garantia a execução, monitoramento e controle de dez assuntos julgados essenciais em gerenciamento de projetos, conforme Figura 19. Figura 19: Ferramenta de Gerenciamento do Estudo de Caso. Fonte: elaborada pelo próprio autor. A ferramenta serviu para gerenciar o conjunto de informações relativas ao projeto em uma única plataforma. Desta forma, foi possível ter a gestão integrada dos seguintes documentos: propostas do projeto; identidade do projeto; cronograma do projeto; apresentações do projeto; escopo do projeto; orçamento do projeto; processos do projeto; questionário do projeto; análise SWOT do projeto e atas de reunião do projeto. O encerramento do projeto se deu por meio de uma apresentação em video-conferência com os stakeholders, ressaltando os principais pontos ao longo daquele e seus apontamentos finais de caráter conclusivo. Já com base no modelo SCRUM, a abertura do projeto, assim como a criação do escopo preliminar e o plano de gerenciamento se deram durante a reunião de sprint planning. A execução, monitoramento e controle do plano de gerenciamento, assim como o controle de mudanças foram garantidos durante as reuniões de weekly SCRUM, sprint review e sprint retrospective. A primeira era feita semanalmente com duração de 30 minutos, onde eram anotadadas as tarefas realizadas e as perspectivas para a próxima semana de trabalho. A gestão se deu principalmente pelo documento de product & sprint backlog (Anexo 3) e pelo burndown chart, conforme pode ser observado no Gráfico 6. Gráfico 6 : Burndown Chart do Estudo de Caso Fonte: elaborado pelo próprio autor. Nele, foram relatadas o número de tarefas a serem realizadas (eixo y) em função dos meses (eixo x). Onde cada mês representava sua respectiva sprint. A linha em vermelho mede o desempenho real do projeto, enquanto a azul, o desempenho ideal. Embora seja muito comum na prática de modelos ágeis, a linha base (azul) consistir na ligação entre os pontos inicial e final, adotou-se neste trabalho uma nova formatação. De modo que, a quantidade de tarefas faltantes esperada para uma sprint n, deva ser igual ao número de atividades restantes ao se iniciar a sprint n+1. Ou seja, o término esperado para cada ciclo mensal é igual ao início do período subsequente. Vale ressaltar a existência de um lapso de atividades entre outubro e fevereiro, pois conforme definido na empresa de estudo, a etapa de definição do projeto não foi contínua com relação ao início do mesmo. A conclusão do projeto, assim como na primeira metodologia, foi realizada em meio a uma videoconferência com todos os participantes, onde foram apresentados o product & sprint backlog, burndown chart , comentários a respeito de como se deu o andamento do projeto de forma menos detalhada, pontos positivos e negativos e o que foi entregue com relação ao escopo. Quanto ao escopo Seguindo a metodologia que consta no PMBOK®, o planejamento do escopo foi feito de forma a atribuir, para cada um dos cinco grupos de processos de projeto, um conjunto de tarefas documentadas que, de forma macro, iria compôr a estrutura analítica de projeto, conforme é visto na Figura 20. Figura 20: EAP do Estudo de Caso. Fonte: PMBOK®, 2004. A verificação das entregas e a justificativa pela não confirmação das mesmas foram realizadas no documento formal nomeado verificação do escopo. Pela gestão ágil, o escopo foi planejado e definido durante a sprint planning. Sua criação foi realizada baseando-se no conjunto máximo de atividades que poderiam ser desempenhadas em cada sprint, ou seja, dentro de um mês. A partir daí, se concebeu o documento de product & sprint backlog. A aprovação ou rejeição dos entregáveis foi feita na sprint review com a presença do cliente, para que se gerasse incremento de produto. Além disso, propostas de mudança no escopo foram definidas após uma autoanálise durante a sprint retrospective. Quanto ao tempo A gestão do Tempo segundo a gestão mais tradicional se deu por um cronograma, conforme ANEXO 4. O cronograma foi dividido em semanas em detrimento de dias, pois as reuniões de acompanhamento tinham a mesma duração. A ferramenta na gestão ágil com carater cronológico que se baseou para a gestão temporal foi o burndown chart. Nele, era possível ver de forma rápida e linear como estava o andamento do projeto. Quanto ao custo Houve um estudo de mercado para averiguar o custo médio para a criação de um aplicativo de baixa complexidade. A produção desse foi desempenhada por uma empresa parceira da Shell que atualmente é responsável por diversos projetos na área de gestão da informação. Após a apresentação do escopo do projeto à empresa responsável pelo aplicativo, o mesmo foi caracterizado como um projeto de baixo custo. O orçamento apresentado se tornou muito aquém do orçado em pesquisas de mercado e a quantia simbólica foi alocada no centro de custo da área de controle de informações da Shell. Quanto à qualidade Durante o planejamento da qualidade e, segundo a metodologia considerada mais burocrática, a busca pela qualidade foi dita como o grau de atingimento dos objetivos e entregáveis genéricos do projeto, tais como o atendimento às especificações que constam na versão ideal do aplicativo. Para registro e comprovação, tais parâmetros foram descritos em documentos como o termo de abertura, identidade e processos do projeto. A garantia da mesma foi realizada através de questionários realizados com as partes interessadas para apontamento das especificações do aplicativo, por meio de reuniões de acompanhamento e pelo acompanhamento do escopo e cronograma. Segundo a metodologia considerada mais dinâmica, a qualidade foi definida pelo cumprimento do product backlog no tempo prescrito, uma vez que este representa os requisitos previamente acordados entre as partes interessadas. A garantia da qualidade se deu através das reuniões de acompanhamento de projeto: weekly SCRUM, sprint reviews e sprint retrospective. O gráfico de burndown chart também desempenhou importante função durante as referidas reuniões para acompanhamento numérico do nível de execução do escopo. Quanto ao RH Independente da metodologia adotada, conforme requisito da Shell, projetos executados por estagiários possuem um corpo de recursos humanos previamente definido, assim como o ponto focal responsável por dirimir quaisquer dúvidas possíveis. A contratação de equipe não foi necessária. Visto que não foram utilizados recursos que não os próprios empregados da Shell e da empresa que já desempenha de forma ordinária projetos dedicados por meio de contratos de prestação de serviços previamente assinados. O desenvolvimento da equipe não se fez necessário, visto que todos os stakeholders já possuíam o conjunto de requisitos necessários para a execução do projeto, salvo o gerente do mesmo (estagiário da Shell) que foi munido de informações e ensinamentos pelo seu orientador acadêmico e pelos seus respectivos supervisor e mentor de estágio. Quanto à comunicação A comunicação com os stakeholders, para ambas metodologias, se deu através de reuniões presenciais de acompanhamento das metodologias adotadas. A única exceção se tratava dos distribuidores da Shell que são alocados em diversas regiões representando os diversos estados brasileiros, estando estes presentes nas referidas reuniões por videoconferência. Com relação a formalização das partes interessadas, o PMBOK® exige documentação e o SCRUM não necessita de registro, sendo o acordado verbal válido a fim de comprovação. É possível observar o diagrama de stakeholders da primeira metodologia na Figura 21. Figura 21: Stakeholders do Estudo de Caso. Fonte: PMBOK®, 2004. As partes interessadas, seguindo a metodologia tradicional, foram configuradas por ordem de proximidade com a área gestora do projeto (pricing). Desta forma, definem-se: pricing: área responsável pela gestão do projeto; excelência operacional: área cujo centro de custo cobrirá a despesa com o projeto, além de deter grande experiência de projetos de gestão da informação dentro da Shell, se tornando principal referência; Blink: empresa terceira responsável pela criação do aplicativo; distribuidores: responsáveis a nível nacional apenas, pela venda indireta de lubrificantes, atuando como ponte entre Shell e pontos de venda. São eles os responsáveis pelo uso do aplicativo no processo de negociação dos produtos Shell; ICAM: conhecidos como Indirect Channel Account Managers, são os responsáveis na Shell pelas boas vendas dos diversos distribuidores; consultores do projeto: pessoal com experiência a serem compartilhadas nas áreas tangíveis ao projeto (como vendas, precificação, comercial etc) e icolub: fábrica de lubrificantes da Shell, localizada na Ilha do Governador, que deve estar a par do andamento do projeto, já que o mesmo resultará num incremento de venda de lubrificantes, o que aumenta a demanda de produtos lubrificantes. Já no caso do SCRUM as partes interessadas são resumidas em três partes: development team: é a equipe do projeto, aqui caracterizada na área de pricing e excelência operacional da Shell, a empresa terceira - Blink - , os ICAM e os consultores do projeto; SCRUM master: o gerente do projeto e product owner: são os donos do artefato gerado com o fim do projeto, que no caso é o aplicativo de negociação. Neste projeto a figura representativa é o distribuidor. É importante observar que a icolub, fábrica de lubrificantes, que age como ouvinte para que possa acompanhar o projeto e possível leve incremento no volume de lubrificantes produzido, não faz parte do SCRUM Team, já que não gerencia, não é dona do produto final, nem sequer agrega valor ao entregável final. Quanto ao risco Os riscos do projeto, para ambas formas de gestão de projetos, foram identificados, conforme Figura 22, com o auxílio da ferramente de análise SWOT a seguir. Esta por sua vez contempla: fatores internos: forças e fraquezas fatores externos: oportunidades e ameaças Figura 22: Análise SWOT do Estudo de Caso. Fonte: elaborada pelo próprio autor. Foram ditos como forças, o aumento de rentabilidade que o aplicativo traria a Shell. Já que um processo eficaz de venda de lubrificantes sem delegação de aprovação para margens de pedido boas reduz o tempo para realizar uma venda e diminui a ocorrência de penetração da concorrência. Além disso foi considerada também a autonomia dada aos vendedores, já que poderiam simular no aplicativo preços passíveis de aprovação imediata (desde que atendam a um piso de margem limítrofe). A exemplo de fraqueza, foi citado a falta de familiaridade com aplicativos, principalmente na figura do gerente de projetos. E como um segundo exemplo, a dependência da criação do aplicativo nas mãos de uma empresa terceira. A título de oportunidade, foi elencado o aumento de conhecimento em precificação que a ferramente traz ao vendedor, dando noções de margens e pedidos prósperos que previamente não eram possíveis. Além disso, a informação do quão lucrativo é a venda simulada, tornou possível trazer margens melhores ao distribuidor e ao ponto de venda (postos de gasolina ou lojas de autopeças). No campo das ameaças, foram contemplados a dificuldade de aderência de alguns distribuidores à novidade, assim como uma possível demora na entrega do aplicativo visto que a empresa terceira realiza em paralelo inúmeros projetos para a Shell. Como observação, vale ressaltar que o risco de stock-out na fábrica de lubrificantes (icolub) é inexistente, devido ao baixo adicional de vendas resultante da conclusão do projeto. Com base no volume médio perdido pela lentidão na aprovação de pedidos por vendedor e na quantidade de vendedores, chega-se a um total de litros por mês irrisório comparados ao produzido ordináriamente. Os processos de risco, segundo a metodologia do PMI®, foram devidamente registrados, todavia, segundo o SCRUM, não houve qualquer tipo de documentação. O planejamento do gerenciamento e da resposta a riscos, assim como sua identificação, análise, monitoramento e controle foram feitos através das suas cerimônias, já que a comunicação gera comprovação. Quanto à aquisição Independente da metodologia adotada, não houve qualquer tipo de aquisição de mão-de-obra extraordinária, treinamentos ou qualquer tipo de desenvolvimento do capital humano do projeto, tal qual qualquer compra de bens materiais. A única despesa se tratou da aquisição do projeto, que foi alocada no centro de custo da área responsável pela gestão das informações na Shell. Isto posto, pois o projeto foi considerado de baixo custo e sua quantificação monetária ficou posicionada muito abaixo da cotação do mercado. Quanto à conclusão Tanto no PMBOK® quanto no SCRUM, o projeto foi dado como concluído durante a reunião de apresentação dos seus resultados para todos os stakeholders. Isto somente foi possível após o cumprimento das demais etapas. RESULTADOS Buscando mensurar o desempenho de ambas metodologias segundo 11 assuntos relevantes em projetos, foi possível a construção de uma tabela comparativa conforme ANEXO 7. Na diferenciação dos dois métodos, pôde-se constatar: quanto aos grupos de processo: no SCRUM, em função da sprint planning, reunião de planejamento, estar disposta em linha com as iterações da sprint, qualquer replanejamento se tornou viável apenas no término da segunda (1 mês após essa ter sido iniciada). Mudanças no que foi definido no product e sprint backlog não foram realizadas a qualquer momento, conforme ratifica a Figura 23. Figura 23: Reuniões do SCRUM – Estudo de Caso. Fonte: elaborado pelo próprio autor. Já de acordo com o guia PMBOK®, há grupo de processo de planejamento se permeando ao longo do projeto (conforme Gráfico 7), sendo passível de mudança. Desta forma, o melhor desempenho foi encontrado na segunda metodologia; Gráfico 7: Interação de Grupos de Processos em um Projeto. Fonte: PMBOK®, 2004, p. 68. quanto à integração: embora existam estreitas relações, podendo-se realizar analogias entre os métodos, conforme Tabela 4 e Figura24, a gestão de projetos segundo o modelo do PMI® é feita de forma lenta e com processos de certa forma repetitivos. Enquanto na metodologia ágil, esses eram realizado de forma dinâmica em reuniões de curta duração. Tabela 4: Processos de Integração – Estudo de Caso Processos de Integração   PMBOK®   SCRUM 1) Termo de abertura formalizado Justificativa do projeto e Necessidade dos stakeholders 2) Declaração de escopo preliminar 3) Definição do plano de gerenciamento (documento diretriz de todos os planos auxiliares) 4) Executação do plano de gerenciamento 5) Monitoramento e controle do trabalho do projeto 6) Controle de mudanças 7) Encerramento do projeto I) Sprint planning (4h) Abertura do projeto; Criação do escopo e Criação do plano de gerenciamento II) Weekly SCRUM (30min) Garantia da execução e Monitoramento do trabalho do projeto III) Sprint review e retrospective (3h) Monitoramento e controle do trabalho do projeto; Controle de mudanças e Encerramento do projeto Fonte: elaborada pelo próprio autor. Figura 24: Diagrama dos Processos de Integração – Estudo de Caso Fonte: elaborado pelo próprio autor. A abertura de projeto pela comunicação em substituição aos documentos formais foi capaz de reduzir o tempo de elaboração dos mesmos. De forma que o project form (Anexo 1) e o project identity (Anexo 5), levaram juntos, cerca de 2 horas para serem planejados e produzidos. Na metodologia tradicional é fundamental a criação do escopo preliminar, onde foi gasto cerca de 1 hora para sua criação. Já na gestão ágil, não se faz necessário, já que o escopo é criado integralmente durante a sprint planning, sendo economizado portanto, o mesmo espaço de tempo. Em suma, foi possível verificar que a criação de artefatos obrigatórios além de serem demorados, se tornaram, como no caso do escopo preliminar, redundantes. A economia de tempo, capital humano e mão-de-obra por hora se mostrou mais proveitosa na metodologia ágil, tendo essa a preferência de escolha para o referido quesito; quanto ao escopo: embora as metodologias tenham processos similares, conforme podem ser correlacionados na Tabela 5 e Figura 25, na metodologia tradicional o escopo busca principalmente seguir conforme o planejamento e qualquer alteração é feita para que se cumpram as premissas do projeto. Já no método de Schwaber, busca-se seguir conforme conversado, e como parte integrante deste diálogo, está o cliente. Este acompanha o projeto, seus resultados em cada etapa, sugere melhorias e garante um melhor alinhamento com a equipe de desenvolvimento. No modelo do PMI®, durante o planejamento, definição, verificação e controle do escopo, não há comunicação com o cliente final, este vindo a ser notificado apenas após a conclusão do projeto. Além disso, qualquer alteração dos requisitos que aquele possa solicitar, não é corrigida a tempo, podendo gerar retrabalho, aumento de gastos com mão-de-obra, necessidade de recursos adionais etc. Sendo assim, essa metodologia não foi preferida; Tabela 5: Processos de Escopo – Estudo de Caso Processos de Escopo   PMBOK®   SCRUM 1) Planejamento do escopo 2) Definição do escopo 3) EAP 4) Verificação do escopo 5) Controle do escopo I) Sprint Planning Planejamento do escopo Definição do escopo II) Weekly SCRUM III) Sprint Review Verificação do escopo IV) Sprint Retrospective Controle do escopo Fonte: elaborada pelo próprio autor. Figura 25: Diagrama dos Processos de Escopo – Estudo de Caso Fonte: elaborado pelo próprio autor. quanto ao tempo: na metodologia SCRUM, foram encontrados alguns empecilhos, como por exemplo, o detalhamento das atividades unicamente em meses, que corresponde a periodicidade da sprint. Além disso, houve uma difícil visualização das tarefas no tempo pelo formato de tabela do product & sprint backlog. Não sendo superior ao cronograma usado na metodologia opositora. Este permite não só a percepção cronológica detalhada a nível de semana, como simplifica a visualização do status das atividades por cor, suas interdependências e garante um melhor gerenciamento do tempo, conforme sua versão abreviada na Figura 26. Tais características não foram possíveis de serem encontradas também no burndown chart, desta forma, esse método foi eleito em detrimento do primeiro por ser mais acertivo neste assunto; Figura 26: Cronograma – Estudo de Caso Fonte: elaborado pelo próprio autor. quanto ao custo: em ambos métodos foi possível encontrar processos de estimativa, orçamentação e controle de custos. Contudo, aqueles diferem pela existência de registro em documentos formais em apenas uma deles. A metodologia ágil embora não possua, não impede sua realização para fins de auditoria e comprovação. Logo, ambas são equiparáveis. quanto à qualidade: a fim de garantir a qualidade, foi necessário que houvesse coerência entre o desenvolvimento do projeto e os vários documentos formais confecionados, nos quais estavam presentes diretrizes do projeto (a exemplo: objetivos, entregáveis, especificações da versão ideal do aplicativo). Enquanto isso, no SCRUM bastou-se apenas estar de acordo com o product & sprint backlog, pois esses reúnem os requisitos do product owner com relação ao incremento de produto gerado. Pelo simplicidade e facilidade de gestão, o segundo foi optado como melhor nessa temática; quanto ao RH: a etapa de contratação e treinamento não sofreu diferença entre as metodologias neste projeto. Todavia, em projetos adversos, pode-se observar uma maior adequação destas atividades para o bom funcionamento das fases do PMBOK®, enquanto o SCRUM busca maior aderência aos desejos do product owner. Sendo relativa a percepção de bom desempennho para este quesito, pois depende do objetivo buscado (boa execução do que foi planejado ou atingimento das especificações do cliente), ambos metódos são considerados válidos para esse quesito; quanto à comunicação: a gestão ágil foi considerada como a de rápida comunicação, através de reuniões simplistas e menos sucetíveis a discussões pela sua objetividade. O número reduzido de documentos reduziu a complexidade de discernimento do projeto pelas partes interessadas. Além de reduzir o fluxo de informações com as alterações e atualizações dos mesmos. Já na metodologia do PMI®, grande empenho foi dado para redigir e distribuir as atas de reunião (Anexo 6) e relatórios de acompanhamento. Além do tempo gasto de confeção (cerca de 30 minutos para os relatórios), o tempo de leitura e resposta em comparação a comunicação verbal dinâmica durante as weekly SCRUM foram decisivos para o primeiro não ser adotado com relação a este tema abordado; quanto ao risco: para a sua identificação, foi utilizada a ferramenta da análise SWOT de forma homogênea para ambos os métodos. Para os demais processos - avaliação, monitoramento e controle de risco - foi percebido grande semelhança conforme é possível observar na Tabela 6 e Figura 27. Tabela 6: Processos de Risco – Estudo de Caso Processos de Risco   PMBOK®   SCRUM 1) Planejamento do gerenciamento de riscos 2) Identificação de riscos 3) Análise qualitativa de riscos 4) Análise quantitativa de riscos 5) Planejamento de respostas a riscos 6) Monitoramento e controle de riscos I) Sprint planning Planejamento do gerenciamento de riscos Identificação de riscos Análise qualitativa e quantitativa de riscos Planejamento de respostas a riscos II) Weekly SCRUM Monitoramento de riscos III) Sprint review Monitoramento de riscos IV) Sprint retrospective Monitoramento e controle de riscos Fonte: elaborada pelo próprio autor. Figura 27: Diagrama dos Processos de Risco – Estudo de Caso Fonte: elaborado pelo próprio autor. No SCRUM, por não haver a cultura de registro em documentos formais, a consolidação da informação correta, sem margem para desorientação ou imprecisão é garantida pela constante comunicação entre todos os stakeholders durante as cerimônias. Logo, ambas metodologias são equivalentes neste tema; quanto à aquisição: embora nada se relate a respeito do registro de aquisições no modelo SCRUM, nada impede a sua elaboração, sendo desta forma, equiparada a metodologia mais tradicional e quanto à conclusão: em ambas metodologias, a conclusão se deve ao término das demais etapas, com percepção de aprendizados e pontos a desenvolver pela equipe do projeto, sendo portanto, de igual valia. CONCLUSÃO E RECOMENDAÇÕES CONCLUSÃO O presente trabalho buscou trazer uma melhor compreensão das metodologias de gerenciamento de projetos. Em especial duas de grande importância, para que se pudesse compará-las a fim de obter um método otimizado de gestão. A princípio, foram conceituadas noções básicas sobre projeto, gestão de projeto, a equipe, suas partes interessadas, o cliente e as facilidades encontradas no seu uso. Em seguida, aspectos do PMBOK® e SCRUM foram desbravados, tais quais suas diferenças, vantagens e desvantagens. Foi possível, através de um estudo de caso em uma empresa do segmento de petróleo, observar que nenhuma se sobressaiu preponderantemente sobre a outra. Aspectos positivos de cada devem, por conseguinte, andar juntos, haja vista que a preferência por um modelo varia de acordo com o quesito em pauta. Através deste trabalho, observou-se que o PMBOK® é escolhido em assuntos como: grupos de processo e gestão do tempo. Um total de duas temáticas. Já o SCRUM, é preferível em: gestão da integração, gestão do escopo, gestão da qualidade e comunicação. Totalizando quatro assuntos. São aceitas ambas metodologias para: a gestão de custos, de RH, risco, aquisição e conclusão. Somando cinco abordagens. Portanto, uma forma otimizada de gestão deve levar em consideração os méritos e deméritos de ambas levantados neste trabalho, já que foi possível notar uma economia de diversos fatores como tempo, insumos, mão-de-obra etc ao se optar por determinado modelo ao longo dos onze temas levantados, justificando a relevância do estudo. TRABALHOS FUTUROS Durante o estudo de caso, trabalhou-se pela ótica da realidade brasileira, em um companhia com possibilidade de flexibilizar sua gestão de projetos, sem amarras ou qualquer empecilho gerado pela sua tradição, todavia, como proposta de estudo futuro, é possível considerar casos excepcionais. Como recomendação de trabalho, é possível analisar casos esporádicos e distintos, a fim de observar quais metodologias melhor se encaixam para cada um dos 11 assuntos levantados no capítulo 5. REFERÊNCIAS BIBLIOGRÁFICAS BRAGA, A. R. Gerência de Projetos: Preparação para a Certificação PMP. 2003. Disponível em: . Acesso em: 09 set. 2014. BRESSAN, F. O Método do Estudo de Caso. v. 1, n. 1. São Paulo: FEA/USP, 2000. Disponível em: . Acesso em: 07 set. 2014. CLELAND, D. I. ; IRELAND, L. R. Gerenciamento de Projetos. 2. Ed. Rio de Janeiro: LTC, 2007. KERZNER, H. Gestão de Projetos: as melhores práticas. 2. ed. São Paulo: Bookman, 2007. MAGNO, A. Revista Visão Ágil – SCRUM Master por Ele Mesmo. 4. ed. 2008. Disponível em: < http://www.visaoagil.com/static/downloads/edicoes/VA_04.pdf>. Acesso em: 02 nov. 2014. MARÇAL, A. S. et al. Estendendo o SCRUM Segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI. 2007. MARTINS, L. V. Gestão Profissional de Projetos. 2003. Disponível em: . Acesso em: 12 out. 2014. NARDI, K. PMBOK x SCRUM: Como Gerenciar um Projeto de Software? 2009. PMI® - Project Management Institute ®. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. Guia PMBOK. 3. ed. 2004. PEREIRA, P.; TORREÃO,P.; MARÇAL, A. S. Entendendo o SCRUM para Gerenciar Projetos de Forma Ágil. Mundo PM. 2007. Disponível em: . Acesso em: 22 set. 2014. REINERT, J. D.; LUDVIG, D.. Estudo do uso de Metodologias Ágeis no Desenvolvimento de Uma Aplicação de Governo Eletrônico. Departamento de Informática e Estatística – Universidade Federal de Santa Catarina. 2007. Disponível em: . Acesso em: 18 ago. 2014. ROYAL DUTCH SHELL. Disponível em: . Acesso em: 09 set. 2014. SOARES, M. S. Comparação Entre Metodologias Ágeis e Tradicionais para Desenvolvimento de Software. Disponível em: . Acesso em: 08 jul. 2014. SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. Disponível em: . Acesso em: 05 out. 2014. STANLEIGH, M. Combinando a Norma ISO 10006 e o Guia PMBOK para Garantir Sucesso em Projetos. 2005. SCHWABER, K. Agile Project Management with SCRUM. Washington: Microsoft Press, 2004. THE STANDISH GROUP. The Chaos Report. Disponível em: . Acesso em: 05 jul. 2014. TORREÃO, P. Ambiente Inteligente de Aprendizado para Educação em Gerenciamento de Projetos. Dissertação (Pós-Graduação em Ciência da Computação) – Universidade Federal de Pernambuco, Recife. 2005. VARGAS, R. Manual prático do plano do projeto. 3. ed. rev. Rio de Janeiro: Brasport, 2007. Disponível em: . Acesso em 07 set. 2014. VARGAS, R. Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 3. ed. Rio de Janeiro: Brasport, 2009. YIN, R. Case Study Research: Design and Methods. 2. ed. Thousand Oaks, CA: SAGE Publications, 1994. ANEXOS ANEXO 1 - TERMO DE ABERTURA DO PROJETO project FORM Intern Name nathan peixoto oliveira Supervisor Name katia wendrownik Supervisor's job title & reference indicator pricing coordinator, diu/9d Department of Internship Marketing Mgmt HR contact Carolina Tavares Mentor & reference indicator debora purwin, diu/9d Project Duration FROM FEBRUARY TO AUGUST From (date) 03/02/14 To (date) 31/08/14 Location of Internship B2c pricing Project Title(s) Vendor's tool for negotiations Brief overview of project(s) Provide a tool that will assist vendor's distrubutors in close lubrificants negotiations As he knows better business profitability Intern competencies/ skills required organization, endeavor, planning, good team relationship and creativity Project deliverables (please continue on separate sheet in necessary): Deliverable one A TOOL THAT WILL HELP VENDOR'S DISTRIBUTORS TO HAVE A BETTER KNOWLEDGE OF THE PROFITABILITY OF THE BUSINESS. Relevance to business THE TOOL WILL HELP VENDOR'S DISTRIBUTORS TO GET BETTER PRICING EXPERTISE WHILST THEY MADE BETTER PROFITABLE NEGOTIATIONS. Estimated time to complete UNTIL THE END OF THE INTERNSHIP Deliverable two - Relevance to business - Estimated time to complete - Please indicate how the project(s) will: Allow interns to independently manage their own area of responsibility in their preferred way of working, whilst still receiving management support THE INTERN WILL BE ENTIRELY RESPONSABLE FOR THE DELIVERY OF THE PROJECT, AS HE IS THE COORDINATOR OF THE WHOLE TEAM PARTICIPANT. ORGANAZING THIS TEAM FUNCTIONS TO WORK IN GOOD TIME AND QUALITY WILL BE INTERN'S CHARGE. Allow interns sufficient exposure to the Shell environment by meeting and working with a variety of people THE INTERN WILL HAVE TO SHOW A LOT OF GOOD RELATIONSHIP TO DEAL WITH THE WHOLE PROJECT TEAM. ORGANIZE, RECEIVE FEEDBACKS AND IMPROVEMENTS WHILST HE PUT THOSE ENHANCEMENTS IN PRACTICE. Allow interns freedom to incorporate their own ideas into their work THE INTERN WILL HAVE THE FLEXIBILITY TO BRING AS MANY NEW IDEAS AS HE WANT OR THINK THAT ARE RELEVANT AND APPROPRIATE. Enable interns to put into practice and develop skills that they currently have as well as those important in an organisational environment THE PROJECT WILL SIMULATE EMPLOYEE'S DIFICULTIES FACED DURING REGULAR PROJECTS AT SHELL. AS WELL, THE INTERN WILL HAVE TO SHOW THE SAME VALUES, CAPACITY AND SKILLS DURING HIS OWN PROJECT. ANEXO 2 – PROPOSTAS DE PROJETOS ANEXO 3 – PRODUCT & SPRINT BACKLOG ANEXO 4 – CRONOGRAMA ANEXO 5 – PROJECT IDENTITY   Project Identity Project Description Department Marketing Management Area B2C Pricing Project Vendors' Tool for Negotiations Mentor Debora Purwin - Pricing Manager Supervisor Katia Wendrownik - Pricing Coordinator Project Leader Nathan Oliveira HR Contact Carolina Tavares Estimated Duration Feb 14 until Aug 14 Project Details Objectives Provide a tool that will assist vendors distributors in close lubrificants negotiations as he knows better business profitability. Deliverables A tool that will help vendors distributors to have a better knowledge of the profitability of the business. Summarized Scope Confection of the current (Blink Mobile) and ideal process of margin obtaining Creation of vendors and AIs surveys for ideal process of margin obtaining Estimated Deadline 29/08/2014 Stakeholders Name 1 Flavio Costa Department B2C Sales Mgmt Brazil Name 2 Roberta Nogueira Department Marketing Mgmt Name 3 Marcos Location Blink Name 4 Cinéia Location Blink Name 5 Vendors Distributors Location Shell's Distributors Name 6 AIs Distributors Location Shell's Distributors Name 6 Shell's ICAM Location Shell's Distributors Project Documents (Artifacts) Document 1 Project Proposals Document 1 Project Description Document 2 Project Identity Document 3 Project Schedule Document 4 Kick-off Presentation Document 5 Project Scope Document 6 Project Budget Document 7 Project SWOT Document 8 Tool Current Process Document 9 Tool Current Procedure Document 10 Tool Final Process Document 11 Tool Final Procedure Document 12 Vendors Survey Document 13 AIs Survey Document 14 Shell Survey Document 15 Feedback Survey Document 16 Final Presentation Document 17 Project Minutes ANEXO 6 – PROJECT MINUTES ANEXO 7 – TABELA DE COMPARAÇÃO Quanto Metodologia Melhor desempenho à(ao) PMBOK® SCRUM Grupos de processo Fases simultâneas Fases em linha PMBOK® Integração Gestão lenta e repetitiva Gestão dinâmica SCRUM Escopo Ausência do cliente Participação do cliente SCRUM Tempo Cronograma Product & sprint backlog e burndown chart PMBOK® Custo Orçamento documentado Sem obrigatoriedade de documentação Ambos Qualidade Parametrização complexa Parametrização simples SCRUM RH Voltada aos processos Voltado ao produto Ambos Comunicação Lenta Dinâmica SCRUM Risco Documentado Comunicado Ambos Aquisição Documentada Comunicada Ambos Conclusão Após conclusão das demais fases Após conclusão das demais fases Ambos