1 / 38

Gerenciamento de Projetos

Gerenciamento de Projetos. Motivação. Por que estudar Gerenciamento de Projetos?. As habilidades mais valorizadas pelas organizações são Liderança (89%) Comunicação (78%) Conhecimento em Gerenciamento de Projetos (75%).

krista
Télécharger la présentation

Gerenciamento de Projetos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gerenciamento de Projetos

  2. Motivação Por que estudar Gerenciamento de Projetos? • As habilidades mais valorizadas pelas organizações são • Liderança (89%) • Comunicação (78%) • Conhecimento em Gerenciamento de Projetos (75%). Fonte: Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2007 | 2

  3. Esforço temporário com um começo e fim Cria um único produto, serviço ou resultado É elaborado progressivamente [Mulcahy, 2003] O que é um projeto? “Um esforço temporário com a finalidade de criar um produto/serviço/resultado único” PMBOK GUIDE | 3

  4. O que é um projeto? | 4 • Temporário não significa de curta duração! • Muitos projetos duram vários anos • Em todos os casos a duração de um projeto é finita • Projetos não são esforços contínuos • O termo temporário não se aplica ao produto, serviço ou resultado criado pelo projeto • A maioria dos projetos cria um resultado duradouro • Ex: erguer um monumento nacional – resultado dura séculos • Projetos podem ter impactos sociais, econômicos e ambientais com duração muito longa

  5. Escopo Custo Tempo Dimensões de um projeto? | 5

  6. Dimensões de um projeto? • Triple Constraint: Custo, Tempo e Escopo. • Triple Constraint Expanded: Qualidade, Risco e Satisfação do Cliente. • Para cada componente é atribuida uma prioridade, de acordo com os objetivos do projeto. O que vale é: Custo, Tempo, Escopo, Qualidade, Risco e Satisfação do Cliente | 6

  7. Grupos de Processos para Gerenciamento | 7

  8. Ciclo de Vida do Gerenciamento de Projeto Apesar desta distinção formal entre as atividades dos grupos de processos, na prática estas atividades se sobrepõem e interagem ao longo de todo ciclo de vida do projeto | 8

  9. Gerenciamento de projetosde software • Estárelacionadoàsatividadesenvolvidasemassegurarqueo software seráentregue • dentro do prazodefinido no crongrama • de acordo com osrequisitos das organizaçõesquedesenvolvemeadquiremo software • Gerenciamento de projetoénecessárioporqueodesenvolvimento de software estásempresujeito a restrições de orçamentoe de cronograma • Nãoabordaremosoutrostipos de projetoquepodem ser conduzidos | 9

  10. Distinções de gerenciamentode software • O produto é intangível • O produto é flexível • A engenharia de software não tem a maturidade das outras disciplinas da engenharia • O processo de desenvolvimento de software não é padronizado • Muitos projetos de software são projetos ‘únicos’ | 10

  11. Algumas atividades de gerenciamento • Elaboração de proposta • Planejamento e desenvolvimento do cronograma do projeto • Estimativa de custo do projeto • Monitoração e revisões de projeto • Elaboração de relatórios e apresentações | 11

  12. Características comuns do gerenciamento • Essasatividadesnãosãopeculiaresaogerenciamento de software • Muitastécnicas de gerenciamento de projeto de engenhariasãoigualmenteaplicáveisaogerenciamento de projeto de software • Tecnicamente, sistemas de engenhariacomplexostendem a sofrer dos mesmosproblemasqueossistemas de software • Menososrequisitosmutantes | 12

  13. Planejamento de projeto • Provavelmente a atividade de gerenciamento de projetoquetomamais tempo • É umaatividadecontínuaquevai do conceitoinicialaté a entrega do sistema • Os planossãoregularmenterevisados, àmedidaqueinformações novas se tornamdisponíveis • Vários tipos diferentes de plano podem ser desenvolvidos para apoiar o plano principal • Este último é particulamente focado no cronograma e no orçamento do projeto | 13

  14. Tipos de plano de projeto | 14

  15. Processo de planejamento de projeto • Isso é apenas uma idéia geral. Na prática, as coisas são bem mais complicadas | 15

  16. Estrutura do plano de projeto • Introdução • Organização de projeto • Recursos do projeto • Análise de riscos • Requisitos de recursos de hardware e de software • Estrutura analítica • Cronograma do projeto • Mecanismos de monitoramento e elaboração de relatórios | 16

  17. Organização de atividades • Em um projeto, as atividades devem ser organizadas para produzir saídas tangíveis • Marcos são o ponto final de uma atividade de processo • Produtos a ser entregues são resultados do projeto • Disponibilizados para os clientes • O processo cascata é orientado pela definição dos marcos do projeto | 17

  18. Desenvolvimento do cronograma do projeto • Dividir o projeto em tarefas e estimar tempo e recursos necessários para completar cada tarefa • Organizar tarefas simultâneas para fazer uso otimizado da força de trabalho • Minimizar dependências entre tarefas para evitar atrasos devido a uma tarefa ter de aguardar a conclusão de outra • Normalmente lança mão de redes de atividades PERT (Program Evaluation and Review Technique )/CPM (Critical Path Method) • Desenvolvimento de software normalmente usa prioridades | 18

  19. Problemas no desenvolvimento do cronograma • É difícil estimar dificuldades e problemas • Logo, é difícil estimar o tempo total de uma atividade • A produtividade não é proporcional ao número de pessoas que trabalham em uma tarefa • A inclusão de pessoas em um projeto atrasado tende a atrasar ainda mais devido aos overheads de comunicação • O inesperado sempre ocorre. Deve-se sempre considerar a contingência no planejamento • Margem mínima de 10% | 19

  20. Diagramas de barras e redes de atividades • São notações gráficas usadas para ilustrar o cronograma de projeto • Mostram a quebra do projeto em tarefas • Depende da duração do projeto • Redes de atividades mostram as dependências entre as tarefas e o caminho crítico • Os diagramas de barras mostram o cronograma em contraste com tempo do calendário | 20

  21. Durações e dependências de tarefas | 21

  22. Rede de atividades | 22

  23. Rede de atividades Caminho Crítico | 23

  24. Diagrama de barras de atividades | 24

  25. Alocação de pessoal | 25

  26. Gerenciamento de riscos • O gerenciamento de riscos está relacionado à identificaçãode riscos e à elaboração de planos para minimizaresses efeitos em um projeto • Risco é a probabilidade de que alguma circunstância adversa ocorra • Os riscos de projeto afetam o cronograma ou os recursos • Os riscos de produto afetam a qualidade ou o desempenho do software que está sendo desenvolvido • Riscos de negócio afetam a organização que desenvolve ou adquire o software | 26

  27. Riscos de software | 27

  28. O processo de gerenciamento de riscos • Identificação de riscos • Levanta os riscos de projeto, de produto e de negócio • Análise de riscos • Avalia a probabilidade e as conseqüências desses riscos • Planejamento de riscos • Elabora planos para evitar ou minimizar os efeitos do riscos • Monitoramento de riscos • Monitora os riscos ao longo do projeto | 28

  29. O processo de gerenciamento de riscos | 29

  30. Identificação de riscos • Classificação de riscos em termos de suas possíveis fontes • Riscos de tecnologia • Riscos de pessoal • Riscos organizacionais • Riscos de ferramentas • Riscos de requisitos • Riscos de estimativas | 30

  31. Riscos e tipos de risco | 31

  32. Análise de riscos • Avaliar a probabilidade e a severidade de cada risco • A probabilidade pode ser baixa, média ou alta • Os efeitos de risco poderiam ser catastróficos, sérios, toleráveis ou insignificantes • A classificação deve deixar clara a severidade!!! | 32

  33. Análise de riscos

  34. Planejamento de riscos • Considerar cada risco e desenvolver uma estratégia para gerenciar esse risco • Estratégias de prevenção • A probabilidade de o risco ocorrer é reduzida • Estratégias de minimização • O impacto do risco sobre o projeto ou produto será reduzido • Planos de contingência • São planos para lidar com os riscos, caso eles ocorram | 34

  35. Estratégias de gerenciamento de riscos

  36. Monitoramento de riscos • Avaliar, regularmente, cada um dos riscos identificados para decidir se está ou não se tornando menos ou mais provável • Avaliar também se os efeitos do risco mudaram • Cada risco-chave deve ser discutido nas reuniões de gerenciamento de progresso | 36

  37. | 37

  38. Referências | 38 • Project Management Institute (2004) “A Guide to the Project Management Body of Knowledge”. 3ª edição. Project Management Institute, USA.http://www.pmi.org • Mulcahy, R. (2003) “PMP Exam Prep”. 5ª edição. Ed. RMC Publications, USA. • Ian Sommerville (2007) Engenharia de Software. 8ª edição, Pearson. • Pinto, A. (2007) “Estudo de Benchmarking em Gerenciamento de Projetos Brasil”

More Related