Gerenciamento de Projetos

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”