Escolar Documentos
Profissional Documentos
Cultura Documentos
Aplicada Web
Professor
Introduo !
Histria da Gerncia de Projeto !
4
5
6 7
8
8 8
9
9 9 9
Caminho crtico !
Relacionamento entre tarefas!
10
10
Plano de contingncia !
Princpio de Pareto!
11
12
Etapas de um projeto !
Ciclo de monitoramento e controle!
12
13
13
13 15 15 16
17 17 17 18
18 18
Tecnologias disponveis !
Para uso no computador!
Microsoft Project! Serena Open Project!
20
20
20 20
20
20 20
Tecnologias auxiliares !
Mindmeister!
20
20
Introduo
Gerncia de projetos ou gesto de projetos a aplicao de conhecimentos, habilidades e tcnicas na elaborao de atividades relacionadas para atingir um conjunto de objetivos pr-denidos. O conhecimento e as prticas da gerncia de projetos so mais bem descritos em termos de seus processos componentes. Esses processos podem ser classicados em cinco grupos de processo (iniciao, planejamento, execuo, controle e encerramento) e nove reas de conhecimento (gerncia de integrao de projetos, gerncia de escopo de projetos, gerncia de tempo de projetos, gerncia de custo de projetos, gerncia de qualidade de projetos, gerncia de recursos humanos de projetos, gerncia de comunicaes de projetos, gerncia de riscos de projetos e gerncia de aquisies de projetos). Reduzida sua forma mais simples, a gerncia de projetos a disciplina de manter os riscos de fracasso em um nvel to baixo quanto necessrio durante o ciclo de vida do projeto. O risco de fracasso aumenta de acordo com a presena de incerteza durante todos os estgios do projeto. Um ponto-de-vista alternativo diz que gerenciamento de projetos a disciplina de denir e alcanar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espao, etc). A gerncia de projetos freqentemente a responsabilidade de um indivduo intitulado gerente de projeto. Idealmente, esse indivduo raramente participa diretamente nas atividades que produzem o resultado nal. Ao invs disso, o gerente de projeto trabalha para manter o progresso e a interao mtua progressiva dos diversos participantes do empreendimento, de modo a reduzir o risco de fracasso do projeto.
pgina 4
Grco de Gantt
Os anos 50 marcam o comeo da era moderna da gerncia de projeto. Outra vez, nos Estados Unidos, antes dos anos 50, os projetos foram controlados basicamente se utilizando os grcos de Gantt, tcnicas informais e ferramentas. Nesse tempo, dois modelos programando do projeto matemtico foram desenvolvidos: 1) de 'Program Evaluation and Review Technique' ou o PERT 2, desenvolvido como a parte programa do mssil do submarino Polaris da marinha dos Estados Unidos' (conjuntamente com o Lockheed Corporation); e o 2) 'Critical Path Method' (CPM) desenvolvido em conjunto por DuPont Corporation e Remington Rand Corporation para projetos da manuteno de planta. Estas tcnicas matemticas espalharam-se rapidamente em muitas empresas. Em 1969, o Project Management Institute (PMI3) foi dando forma para servir ao interesse da indstria da gerncia de projeto. A premissa de PMI que as ferramentas e as tcnicas da gerncia de projeto so terra comum mesmo entre a aplicao difundida dos projetos da indstria do software indstria de construo. Em 1981, os diretores do PMI autorizaram o desenvolvimento de o que se transformou em um guia de projetos o 'Project Management Body of Knowledge'4, contendo os padres e as linhas mestras das prticas que so usados extensamente durante toda a prosso.
1 2 3 4
pgina 6
Anatomia de um projeto
Para explicar um pouco mais sobre projetos e gesto de projetos, vamos fazer uma analogia didtica usando como exemplo a atividade de pegar nibus. Responda algumas perguntas: Voc pega qualquer nibus? Se o nibus estiver lotado voc esperar o prximo? O dinheiro esta trocado? Separado? Onde existe mais chance de ter um lugar livre? Meu ponto esta chegando, preciso me dirigir saida? Provavelmente voc no pega qualquer nibus, decide o nibus a pegar em funo de diversas variveis como por exemplo: Qual nibus pegar depende do trajeto, pode ser para onde voc deseja ir s tenha uma linha de nibus ou pode ser que praticamente todos passem no seu destino. Se voc for uma pessoa com hbitos prativos5, deve estar com tempo suciente para ch e g a r a o s e u d e s t i n o a t o h o r r i o programado e pode se dar ao luxo de aguardar o nibus mais vazio passar. Quem utiliza dinheiro para pagar a passagem, costuma ter mo dinheiro trocado, e separado para pagar a passagem, assim evita que a la que engarrafada esperando voc pagar, e no costuma chamar ateno para o dinheiro que tem em sua carteira.
Ao entrar no nibus, caso ele esteja cheio, voc costuma se deslocar para o fundo 6, prximo sada de forma que que mais fcil para descer, e onde existe maior probabilidade de algum levantar e voc conseguir sentar. Estas variveis dependem de diversos fatores, inclusive caractersticas fsicas do nibus e o fato de conhecer as pessoas que pegam diariamente, assim ca mais fcil saber quem desce onde e quando, e se posicionar com preciso prximo pessoa onde existe maior chance de voc sentar. Isto se aprende no ciclo de projetos, no caso andar de nibus, e onde os conhecimentos so transformados e registrados, conrmando a mxima de que a prtica leva perfeio.
5 6
pr-ativo aquele que toma as iniciativas, que procura formas de resolver um problema de forma positiva No Rio de janeiro a maioria dos nibus possui a sua sada na parte traseira. pgina 7
planejamento. O que seria imprevisvel neste caso por exemplo seria o roubo ou danicao de materiais. Controlar todas as variveis em todas as atividades de um projeto extremamente trabalhoso, prev-las muito mais difcil, por mais experiente que o gestor de projetos seja, ele sempre encontrar novas variveis em novos projetos.
pgina 9
Caminho crtico
Existem atividades em um projeto que so mais importantes que as outras, muitas dependem de outras de alguma forma e precisam ser executadas porque afetam sensivelmente a execuo do projeto, estas tarefas so as chamadas tarefas do caminho crtico. Relacionamento entre tarefas Estas dependncias entre as tarefas pode se dar entre uma tarefa e outra, ou entre vrias tarefas e uma unica tarefa sucessora, ou entre diversas tarefas. Usando a lgica booleana, as relaes entre as tarefas podem ser de uma para uma, muitas para muitas, uma para muitas e muitas para uma. Basicamente existem quatro tipos de relacionamento entre tarefas: Termino para Inicio (TI) - O inicio de uma tarefa depende da concluso de outra, ou seja, para que a tarefa inicie, preciso que a outra seja concluda. Inicio para Inicio (II) - O inicio de uma tarefa esta relacionada ao inicio de outra, ou seja, para iniciar a tarefa precisamos que outra inicie tambm. Termino para Trmino (TT) - O trmino de uma tarefa depende do trmino de outra. Ou seja as duas tarefas precisam terminar juntas. Incio para Trmino (IT) - Esta a relao mais rara, mas possvel de acontecer, ou seja, uma tarefa s pode terminar se outra for iniciada. Existe ainda a chamada latncia, que signica um tempo adicional nos relacionamentos de tarefa acima. Por exemplo, na pintura de uma parede, existem trs tarefas: Aplicao da massa, lixamento da massa e pintura, entretanto existe a necessidade da massa secar, por exemplo ela precisa de 48 horas para secar completamente a ponto de ser lixada. Ento o relacionamento entre aplicao da massa e o lixamento da massa uma relao TI com latncia de 48 horas, ou seja aps terminar a aplicao da massa preciso esperar 48 horas para lixa-la. Voc pode aplicar a latncia em todos os tipos de relacionamento de tarefas, por exemplo pode usar uma relao II com uma latncia de 24 horas, de forma a que uma tarefa deve iniciar no dia seguinte ao inicio de sua predecessora. No nosso exemplo do nibus, supondo que tenhamos de pegar dois nibus para completar o trajeto, pegar o primeiro nibus uma tarefa predecessora para pegar o segundo, ou seja, a relao e n t r e p e ga r o p r i m e i r o Pegar o primeiro nibus Pegar o segundo nibus nibus e o segundo uma relao TI (trmino para incio). As tarefas que no possuem nenhum relacionamento, e isto normal de acontecer, no fazem parte do caminho crtico e podem ser executadas no momento que for mais conveniente para o gestor de projetos, em geral so programadas para serem
pgina 10
Plano de contingncia
Seria timo se tudo na vida acontecesse como planejado, viveramos num mundo perfeito, onde tudo daria certo, tudo aconteceria no tempo programado, utilizaria os recursos alocados, e dentro do custo previsto... Que saco ! A vida seria um tdio, que graa teria? Muitas vezes sonhamos com um mundo perfeito, mas nos esquecemos que so as imperfeies do mundo que o torna interessante, que torna a vida desaadora, dando o seu tempero. Em gesto de projetos no poderia ser diferente, existe a famosa Lei de Murphi7 que quer dizer o seguinte: Se algo tiver de dar errado, vai dar errado!
Lembre-se das variveis incontrolveis ou imprevisveis, elas esto ai para dar o tempero do seu projeto. Gestores de projetos costumam considerar margens de segurana denidas com o apoio de gestores tcnicos que iro executar o projeto. Por exemplo, aplica-se uma margem de segurana na mo de obra, para cobrir eventuais faltas e atrasos, e para prover o projeto uma certa margem de manobra para que atividades de emergncia sejam executadas sem um impacto muito grande no prazo nal do projeto. Aplica-se uma margem de segurana nos recursos materiais prevendo desperdcios e eventuais danos ou extravios, mas as margens neste caso devem ser aplicadas com critrio para que a excessiva margem de segurana em materiais no seja um prejuzo no projeto. Um projeto bem planejado leva em conta o imprevisto, se alguma coisa der errado, o projeto vai parar? Pode-se executar outra tarefa enquanto resolvemos o problema que impede o andamento do projeto? E este problema pode ser simplesmente uma etapa de aprovao do cliente por exemplo. Neste caso as tarefas que no fazem parte do caminho crtico podem ser executadas para que a equipe no que parada por exemplo.
http://pt.wikipedia.org/wiki/Lei_de_Murphy pgina 11
Princpio de Pareto O principio de Pareto 8, tambm conhecida pela regra 80-20 se resume em que 80% dos efeitos so provenientes de 20% das causas. O estudioso de Administrao Joseph M. Juran identicou o principio que ganhou este nome aps o economista Italiano Vilfredo Pareto ter observado que 80% da renda Italiana proveniente de 20% da populao. Esta uma regra comum nos negcios, em geral 80% das suas vendas so provenientes de 20% de seus clientes. O princpio de Pareto um bom critrio para voc usar no planejamento e anlise do seu projeto. No estamos falando que a relao ser precisamente 80-20, pode-se variar entre 90-10 e 70-30, mas geral ca nesta faixa. Por exemplo 80% do custo do seu projeto esta relacionado 20% das tarefas, ou 80% do prazo esta relacionado 20% das tarefas, e por ai vai. O importante mesmo identicar no seu projeto quais as tarefas que fazem parte destes 20% e dedicar uma ateno especial elas.
Etapas de um projeto
Todo projeto desenvolvido em cinco etapas: Iniciao, planejamento, execuo, controle e concluso Iniciao a etapa onde tomamos conhecimento do projeto a ser feito, o momento da confeco do brieng, ou de sua leitura equipe, nesta hora onde surgem diversas dvidas do projeto. Em geral uma etapa que deve ser desenvolvida em uma reunio de brainstorm. Planejamento onde o projeto detalhado, se aplicarmos o principio de Pareto, onde investimos 80% do nosso tempo. o momento em que detalhamos as atividades, pesquisamos, determinamos prazos, alocamos recursos e custos. O resultado do planejamento uma lista de tarefas e/ou um grco de Gantt. Execuo o objetivo do projeto, a hora da verdade, quem executa o gestor tcnico, a hora de colocar o projeto em prtica. Controle, o gestor do projeto faz o controle da execuo, registrando tempo e recursos, e gerenciando as possveis mudanas. Concluso, bom concluso dispensa mais comentrios, a hora em que o projeto termina.
http://en.wikipedia.org/wiki/Pareto_principle pgina 12
Ciclo de monitoramento e controle Na verdade as cinco etapas do projeto no acontecem como uma seqncia linear, anal como j vimos existem problemas no previstos, existem ajustes serem feitos. E estes ajustes so feitos on the y, ou seja, durante a execuo do projeto, congurando um ciclo claro que passa por execuo, controle e planejamento.
Iniciao
planejamento
execuo
controle
concluso
Geralmente na hora da execuo que o planejamento posto a prova, o controle o acompanhamento que o gestor de projetos faz junto ao gestor tcnico, ele registra os tempos e uso de recursos. Este controle pode apontar tanto uma tendncia economia de recursos quando necessidade de utilizar recursos alem do planejado. atribuio do gestor de projetos revisar seu planejamento para avaliar os impactos destas variaes e tomar as devidas providncias.
Abordagem tradicional
Na abordagem tradicional, a que vimos at agora, distinguimos cinco grupos de processos no desenvolvimento de um projeto: 1. 2.
9
Iniciao Planejamento
http://en.wikipedia.org/wiki/Agile_Project_Management pgina 13
3. 4. 5.
Nem todos os projetos vo seguir todos estes estgios, j que projetos podem ser encerrados antes de sua concluso. Alguns projetos passaro pelos estgios 2, 3 e 4 mltiplas vezes. O projeto ou empreendimento visa a satisfao de uma necessidade ou oportunidade, denida no texto acima como fase inicial na qual existem muitas reas e/ ou pessoas envolvidas. Em geral sempre existe mais que uma soluo ou alternativas para atender s mesmas necessidades. A tcnica usada para denir a soluo nal passa pelo desenvolvimento de alternativas extremas. A primeira de baixo custo que atende as necessidades mnimas para ser funcional. A segunda tenta atender a maior parte das as exigncias das diversas reas envolvidas no escopo que resulta num projeto com custo muito maior e pouco competitivo. A partir de ambas as alternativas desenvolvida uma soluo intermediria entre as mesmas, que atende a uma boa parte das exigncias com um custo competitivo. Vrios setores utilizam variaes destes estgios. Por exemplo, na construo civil, os projetos tipicamente progridem de estgios como Pr-planejamento para Design Conceitual, Design esquemtico, Design de desenvolvimento, construo de desenhos (ou documentos de contrato), e administrao de construo. Embora os nomes diram de indstria para indstria, os estgios reais tipicamente seguem os passos comuns resoluo de problemas (problem solving): denir o problema, balancear opes, escolher um caminho, implementao e avaliao. O gerenciamento de projetos tenta adquirir controle sobre trs variveis: tempo custo escopo Algumas literaturas denem como quatro variveis, sendo qualidade a quarta varivel, contudo a qualidade uma das principais componentes do escopo. Estas variveis podem ser dadas por clientes externos ou internos. O(s) valor(es) das variveis remanescentes est/esto a cargo do gerente do projeto, idealmente baseado em slidas tcnicas de estimativa. Os resultados nais devem ser acordados em um processo de negociao entre a gerncia do projeto e o cliente. Geralmente, os valores em termos de tempo, custo, qualidade e escopo so denidos por contrato. Para manter o controle sobre o projeto do incio ao m, um gerente de projetos utiliza vrias tcnicas, dentre as quais se destacam: Planejamento de projeto Anlise de valor agregado Gerenciamento de riscos de projeto Cronograma Melhoria de processo
pgina 14
SCRUM
um dos mtodos da metodologia gil para gerenciamento de Projetos. Scrum vem sendo amplamente adotado por empresas como o porta Terra e a Globo.com, justamente por atender com preciso s necessidades do desenvolvimento de software e sites. Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente ecazes formao Scrum do Rugby (utilizada para reincio do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a denio de Scrum e ajudou a implant-lo em desenvolvimento de software em todo o mundo. Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka. A funo primria do Scrum ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porm, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa cientca, ou at mesmo o planejamento de um casamento. Mesmo que o Scrum tenha sido idealizado para ser usado em gesto de projetos de desenvolvimento de software, ele tambm pode ser usado para gerenciar equipes de
pgina 15
Caractersticas de Scrum
Cada sprint uma iterao que segue o ciclo PDCA e entrega um incremento de software pronto. Um backlog um conjunto de requisitos, priorizado pelo Product Owner (cliente); H entrega de um conjunto xo de itens do backlog em uma srie de iteraes curtas ou sprints; Uma breve reunio diria ou scrum, onde cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de Standup Meeting, j que os membros do time geralmente cam em p). Uma breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so denidos; Uma retrospectiva, na qual todos os membros da equipe reetem sobre a sprint passada. O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas) mas atua como um rewall entre a equipe e qualquer inuncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint. Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao verbal entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto. Um princpio chave do Scr um o reconhecimento de que desaos fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma
pgina 16
abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou denido, focando na maximizao da habilidade da equipe de responder de forma gil aos desaos emergentes. Um dos grandes defeitos do Scrum, porm, a abordagem de "receita de bolo" do gerenciamento de projetos exemplicado no Project Management Body of Knowledge ou Prince2, que tem como objetivos atingir qualidade atravs da aplicao de uma srie de processos prescritos. Backlog de produto e backlog de sprint Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto mantido pelo Proprietrio do Produto e uma lista de requisitos que tipicamente vm do cliente. O backlog de sprint uma interpretao do backlog do produto e contm tarefas concretas que sero realizadas durante o prximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint so, ento, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo contendo informaes sobre como a equipe ir implementar os requisitos. Planejamento de sprint Antes de todo sprint, o Proprietrio do Produto, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar durante o prximo sprint. O Proprietrio do Produto mantm uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe ento planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint. Scrum simplicado Muitas organizaes tm sido resistentes s metodologias introduzidas em baixos nveis da organizao. Porm, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisvel ("stealth"), usando os trs passos: 3. 4. 5. Agende uma demonstrao do software com seu cliente em um ms a partir de agora; Como equipe, tome um ms para deixar o software pronto para uma demo, com funcionalidades prontas, no simplesmente telas; Na demonstrao, obtenha feedback e use-o para guiar o seu prximo ms de trabalho de desenvolvimento.
pgina 17
Algumas caractersticas de Scrum Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na sada); Entregas freqentes e intermedirias de funcionalidades 100% desenvolvidas; Planos freqentes de mitigao de riscos desenvolvidos pela equipe; Discusses dirias de status com a equipe; A discusso diria na qual cada membro da equipe responde s seguintes perguntas: O que z desde ontem? O que estou planejando fazer at amanh? Existe algo me impedindo de atingir minha meta? Transparncia no planejamento e desenvolvimento; Reunies freqentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso; Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer problema no visto; Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" no necessariamente signica "produzir mais". Agendando discusses dirias Um momento bom para as discusses dirias depois do almoo. Durante a manh pode ser complicado. Estas discusses de status no demoram e uma forma eciente de fazer estas reunies seria car em p e em frente a um quadro negro. Como as pessoas tendem a car cansadas depois do almoo, ter uma viva reunio em p nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manh, suas mentes esto focadas no trabalho e no em questes pessoais. Scrum Solo Scrum baseado em pequenas equipes. Ele permite a comunicao entre os membros da equipe. Entretanto, h uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um s programador pode ainda se beneciar de alguns princpios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo uma verso adaptada para uso de programadores solo.
pgina 18
Mapa mental, mind map ou mapa semntico o nome dado para um tipo de diagrama, sistematizado pelo ingls Tony Buzan, voltado para a gesto de informaes, de conhecimento e de capital intelectual; para a compreenso e soluo de problemas; na memorizao e aprendizado; na criao de manuais, livros e palestras; como ferramenta de brainstorming (tempestade cerebral); e no auxlio da gesto estratgica de uma empresa ou negcio. Os desenhos feitos em um mapa mental partem de um nico centro, a partir do qual so irradiadas as informaes relacionadas. Eles podem ser feitos com um programa de computador adequado ou com canetas coloridas e um bloco de papel, e podem ser usados por todos os prossionais para gerenciar qualquer tipo de informao. Este mtodo de registro cada vez mais usado por uma srie de prossionais de todas as reas de conhecimento humano. Existem diversos programas para construo de mind maps, e inclusive um online e colaborativo, o Mind Meister em http://www.mindmeister.com. Em nosso curso utilizaremos mind maps para o planejamento de projeto, construo de brieng e organizao de idias.
pgina 19
Tecnologias disponveis
Existem diversas tecnologias disponveis on e ofine para gesto de projetos, a grande maioria esta disponvel gratuitamente. So elas:
Tecnologias auxiliares
Mindmeister http://www.mindmeister.com/ O Mindmeister uma ferramenta online para criao de mapas mentais, muito til na organizao de idias para o planejamento do projeto.
pgina 20