Pmi Global 2008 Portfolio

1.583 visualizações

Publicada em

Apresentação sobre elementos característicos entre projetos para uma adequada gestão de portfólios.

Publicada em: Negócios
  • Seja o primeiro a comentar

Pmi Global 2008 Portfolio

  1. 1. Project Management Tools for Modern Project and Portfolio Management Vladimir Liberzon, PMP Peter Souza Mello, PMP Victoria Shavyrina, PMP (Spider Project Team) Session n# PMT01 Ferramentas de Gerenciamento de Projeto para uma Gestão Moderna de Projetos e Portfólios
  2. 2. Introdução <ul><li>Nesta apresentação iremos discutir o uso de técnicas e ferramentas que são utilizadas em gerenciamento corporativo de projetos ao redor do mundo. </li></ul><ul><li>Questões durante a apresentação são bem vindas! </li></ul>
  3. 3.
  4. 4.
  5. 5.
  6. 6.
  7. 7.
  8. 8.
  9. 9.
  10. 10.
  11. 11.
  12. 12.
  13. 13. Cálculo de Desperdício: recurso ativo x ocioso R$ 154.560 28 dias
  14. 14. Otimização de Cronograma = Redução do Desperdício R$ 138.000 25 dias
  15. 15. Economia de 11% ao tratar dados de custo adequadamente
  16. 16.
  17. 17. Múltiplas EAPs (WBS) <ul><li>Atividades sem atribuição de pacotes: </li></ul>
  18. 18. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “entregáveis” </li></ul>
  19. 19. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “responsabilidade” </li></ul>
  20. 20.
  21. 21.
  22. 22.
  23. 23. P a s s o s <ul><li>Identificação, seqüenciamento e estimativas sem restrições de recursos (PERT/CPM) </li></ul><ul><li>Detalhamento baseado em restrições de recursos (nivelamento por recursos // corrente crítica) </li></ul><ul><li>Identificação do caminho crítico real (task-critical-path / resource-critical-path) e folgas adequadas para atividades de projetos. </li></ul>
  24. 24. P a s s o s <ul><li>Identificação de requisitos financeiros, materiais e equipamentos para qualquer período de tempo </li></ul><ul><li>Identificação de recursos renováveis e seus tempos de aplicação </li></ul><ul><li>Análise de riscos e desenvolvimento de cronograma compatível com a parametrização dos riscos </li></ul>
  25. 25. P a s s o s <ul><li>Criação de mecanismos de medida de performance </li></ul><ul><li>“ Forecasting” de análise de performance para os parâmetros principais </li></ul><ul><li>Registro de alternativas de projeto (aceitar e respeitar o acaso) </li></ul>
  26. 26. CPM x CRR <ul><li>O método do Caminho Crítico é idêntico em todos os pacotes de gerenciamento de software e todos devem propiciar os mesmos resultados se garantidos a mesma data de início, durações e calendários (CPM) </li></ul><ul><li>Cronogramas por Restrição de Recursos (CRR) possuem diferentes mecanismos e aquele pacote que oferece o melhor resultado na otimização de um cronograma pode representar ganhos e economias aos seus usuários. </li></ul>
  27. 27. Cronogramas por Restrição de Recursos (CRR) <ul><li>O pacote Spider Project Professional explora alternativas matemáticas com restrições de materiais, recursos e finanças para cumprir diferentes objetivos de projeto: redução de custo, garantia de prazo, utilização de recursos compartilhados, estabilidade de datas e reservas, entre outros. </li></ul>
  28. 28. Cronograma sem restrições <ul><li>Para uma correta aplicação de CPM sem o detalhamento de recursos é necessário que se tenha recursos ilimitados. </li></ul><ul><li>Exemplo: O recurso R1 realiza atividades em paralelo (atividades 2 e 5) </li></ul>
  29. 29. Cronograma com restrições <ul><li>Com este mesmo cronograma baseado em restrições, a atividade 3 deixa de ser crítica e a atividade 5 passa a pertencer ao caminho crítico, denominado Caminho Crítico do Recurso ou “corrente crítica”. </li></ul>
  30. 30. CRR e Corrente Crítica <ul><li>Embora muito similar, Cronogramas por Restrição de Recursos diferem da tradicional “Corrente Crítica” por que também considera fluxo financeiro e produção de recursos renováveis e não renováveis como fatores determinante do seu resultado. </li></ul><ul><li>CRR são usados na Rússia desde os tempos da guerra fria e só se tornaram públicos na década de 90. </li></ul>
  31. 31.
  32. 32. Critérios de Sucesso em Projetos <ul><li>Tradicionalmente se estabelece com meta de projeto a sua entrega no prazo e abaixo do orçamento. </li></ul><ul><li>Projetos orientados ao negócio podem desenvolver o “foco no lucro” e não o “foco no custo” </li></ul>
  33. 33. Critérios de Sucesso em Projetos <ul><li>Trump Tower em Chicago é uma demonstração de “foco no lucro”: </li></ul><ul><ul><li>Projeto + LONGO </li></ul></ul><ul><ul><li>Projeto + CARO </li></ul></ul><ul><ul><li>Projeto + LUCRATIVO* </li></ul></ul><ul><li>* A opção é ter negócios já funcionando durante sua construção. </li></ul>http://en.wikipedia.org/wiki/Trump_International_Hotel_and_Tower_(Chicago)
  34. 34. Critérios de Sucesso em Projetos <ul><li>A análise e otimização de um cronograma em um projeto assim leva em conta os mecanismos de financiamento e também as previsões de faturamento com entregas parciais. </li></ul>http://en.wikipedia.org/wiki/Trump_International_Hotel_and_Tower_(Chicago)
  35. 35. Critérios de Sucesso em Projetos <ul><li>O caixa deste projeto é insuficiente para aproveitar os recursos disponíveis. </li></ul>
  36. 36. Critérios de Sucesso em Projetos <ul><li>A falta de dinheiro em caixa pode obrigar atrasar o projeto. </li></ul><ul><li>O lucro esperado é de USD 219.077,00 </li></ul>
  37. 37. Critérios de Sucesso em Projetos <ul><li>Um empréstimo pode garantir o cumprimento da meta inicial. </li></ul><ul><li>Sem caixa, o projeto atrasa até ter novas receitas. </li></ul>
  38. 38. Critérios de Sucesso em Projetos <ul><li>O desempenho cai de: USD 219.077,00 para USD 193.724,96 </li></ul>
  39. 39. Critérios de Sucesso em Projetos Realizar um empréstimo ou desperdiçar USD 25.000,00 ? A decisão apropriada pode pagar por todo o esforço de planejar, em especial quando consideramos o Gerenciamento de Portfólios.
  40. 40. <ul><li>Análise de Risco e Gerenciamento de Projetos por Probabilidade de Sucessos (SDPM) </li></ul>
  41. 41. Por que análise de riscos ? <ul><li>Nossa experiência em projetos demonstra que projetos baseados em cronogramas determinísticos tem baixa probabilidade de sucesso. </li></ul><ul><li>A modelagem computacional de cronogramas com a análise de riscos pode ampliar a probabilidade de sucesso. </li></ul>
  42. 42. Simulação de Riscos <ul><li>A simulação de riscos pode ser baseada em simulações de Monte Carlo ou usar três estimativas, como veremos a seguir. </li></ul>
  43. 43. Simulação de Riscos Estimativas em 3 pontos <ul><li>Dados de projeto (duração, volumes, custos, etc) são coletados com o uso de três estimativas: - otimista, pessimista e mais provável. </li></ul><ul><li>Eventos de risco são selecionados com base a “rankings” utilizados em análise qualitativa de riscos. </li></ul>
  44. 44. Simulação de Riscos Estimativas em 3 pontos <ul><li>Cenário Otimista: </li></ul><ul><ul><li>Contém eventos cuja probabilidade excede 90% </li></ul></ul><ul><li>Cenário Mais Provável: </li></ul><ul><ul><li>Contém eventos cuja probabilidade excede 50% </li></ul></ul><ul><li>Cenário Pessimista: </li></ul><ul><ul><li>Contém eventos selecionados </li></ul></ul>
  45. 45. Simulação de Riscos Estimativas em 3 pontos <ul><li>Cada cenário pode conter atividades e custos adicionais, além de empregar diferentes recursos e calendários. </li></ul><ul><li>O planejador tem como resultado três diferentes cronogramas, com custos, materiais e datas para os principais marcos de projeto. </li></ul>
  46. 46. Parâmetros desejados <ul><li>A definição das probabilidades de se alcançar diferentes resultados permite se fixar custos e datas finais desejados (metas de projeto) </li></ul>06/08 07/08 08/08 10/08 03/09 06/09 06/08 07/08 08/08 10/08 03/09 06/09
  47. 47. Probabilidade de Sucesso <ul><li>Para a meta negociada (cliente/patrocinador/equipe) temos uma probabilidade de ocorrência, que denominamos “ probabilidade de sucesso ”. </li></ul>06/08 07/08 08/08 10/08 03/09 06/09 06/08 07/08 08/08 10/08 03/09 06/09
  48. 48. Buffers/Reservas <ul><li>A diferença entre o cronograma entregue para a equipe (otimista ou provável) e a data fixada como meta estabelece o buffer do projeto . </li></ul>06/08 07/08 08/08 10/08 03/09 06/09 06/08 07/08 08/08 10/08 03/09 06/09
  49. 49. Cronograma Crítico (exemplo) <ul><li>Existem reservas de custos, materiais e tempo que são calculados não somente para o projeto como um todo, mas também temos o registro de reservas comparados ao cronograma de trabalho. </li></ul>
  50. 50. Tendências de Probabilidade de Sucesso <ul><li>A melhor forma de medir a performance de um projeto é estimar o que está acontecendo com a probabilidade de sucesso. </li></ul><ul><li>Se ela aumenta, isso significa que as reservas estão sendo gastas abaixo do planejado. </li></ul><ul><li>Se ela diminui indica que a performance não é adequada. </li></ul>
  51. 51. Tendências de Probabilidade de Sucesso
  52. 52. Tendências de Probabilidade de Sucesso <ul><li>Tendências de Probabilidade de Sucesso não refletem apenas performance de projeto (como é o caso de valor agregado) mas também por diversos elementos ao redor do projeto. </li></ul>
  53. 53. Tendências de Probabilidade de Sucesso <ul><li>Consideramos – assim – que a tendência de probabilidade de sucesso é a principal ferramenta integrada de análise de performance de projetos. </li></ul>
  54. 54. Tendências de Probabilidade de Sucesso <ul><li>Pode ser utilizada como único indicador de performance para a alta direção pois é suficiente para estimativas de performance e tomada de decisão. </li></ul>
  55. 55. Success Driven Project Management <ul><li>A aplicação do indicador de probabilidade de sucesso dá origem ao método russo S uccess D riven P roject M anagement . </li></ul>
  56. 56. Success Driven Project Management <ul><li>Informações complementares sobre SDPM podem ser encontradas em http://www.gestaoeprojetos.com </li></ul><ul><li>Destaque: 5 th Annual Conference of PMI College of Scheduling </li></ul><ul><li>– Apresentação dos princípios de SDPM por Russell Archibald (membro fundador do PMI) </li></ul><ul><li>– Detalhes por Vladimir Liberzon </li></ul>
  57. 57.
  58. 58. Ferramentas e Técnicas de GP Corporativas <ul><li>Devemos organizar dados de forma a apoiar a simulação de trabalho baseado em recursos em todo o Portfólio e com a aplicação de normas e padrões corporativos. </li></ul><ul><li>Modelos Computacionais eficientes são baseados em livros de referência e bibliotecas (fragnets), garantindo maior nível de detalhe no planejamento e execução. </li></ul>
  59. 59. Ferramentas e Técnicas de GP Corporativas <ul><li>Devemos calcular Cronogramas por Restrição de Recursos para cada projeto e o portfólio. </li></ul><ul><li>Devemos garantir a aplicação de simulações de risco em projetos. </li></ul><ul><li>Devemos selecionar critérios de sucesso que sejam compatíveis com os objetivos do negócio (pensamento no lucro e não no custo). </li></ul>
  60. 60. Ferramentas e Técnicas de GP Corporativas <ul><li>Não há projeto sem incerteza e portanto devemos definir metas de projeto com probabilidades razoáveis e um bom controle sobre reservas de contingência. </li></ul><ul><li>Projetos podem ser controlados mediante a análise da probabilidade corrente de sucesso em função das metas, de forma que se tome ações corretivas para probabilidades negativas. </li></ul>
  61. 61. Contact Information <ul><li>Name: Peter Berndt de Souza Mello, PMP </li></ul><ul><li>Email: [email_address] // [email_address] </li></ul><ul><li>Phone: +55 16 8163-3903 // 61 3244-2510 ** Ribeirão Preto ** Brasília ** </li></ul><ul><li>www.spiderproject.com.br </li></ul><ul><li>Session #: PMT01 </li></ul>
  62. 62. COMPLEMENTOS <ul><li>A versão a seguir inclui slides com explicações complementares relacionados aos mapas mentais utilizados no evento. </li></ul>
  63. 63. Project Management Tools for Modern Project and Portfolio Management Vladimir Liberzon, PMP Peter Souza Mello, PMP Victoria Shavyrina, PMP Spider Project Team Session n# PMT01
  64. 64.
  65. 65. Parte 1 <ul><li>Requisitos de Sistemas de Gerenciamento de Projetos Corporativos </li></ul>
  66. 66.
  67. 67. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve ser baseado em padrões corporativos. (dicionários, bancos de dados e bibliotecas) </li></ul><ul><li>Deve calcular cronogramas baseados em restrições de recursos levando em consideração limitações relacionadas a recursos humanos, materiais, fluxos de caixa e dependências externas. </li></ul>
  68. 68. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve considerar prioridades entre recursos, atividades, fases e projetos. </li></ul><ul><li>Deve simular gastos e faturamentos para permitir o gerenciamento adequado de fluxo de caixa entre projetos em um portfólio. </li></ul>
  69. 69.
  70. 70. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve permitir o planejamento de uso de recursos com base a suas habilidades </li></ul><ul><li>Deve calcular a “corrente crítica” com base aos diversos tipos de recurso </li></ul><ul><li>Deve simular riscos e incertezas de projeto </li></ul>
  71. 71. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve prover a alta gerencia com informações integradas que reflitam não apenas a situação atual, mas também tendências e performance do portfólio para a tomada de decisão. </li></ul><ul><li>Deve manter históricos de projeto/portfólio </li></ul>
  72. 72. Parte 2 <ul><li>Dados (informações) </li></ul>
  73. 73.
  74. 74. Organização de Dados <ul><li>Sistemas coporativos de gerenciamento de projetos tem requisitos vitais para uma implementação adequada </li></ul><ul><li>É necessário garantir que … </li></ul>
  75. 75. Requisitos de Dados <ul><li>Os custos de projetos tem uma estrutura consistente entre cada projeto (uso dos mesmos componentes de custo) </li></ul><ul><li>Contas de Custo devem ser a mesma em todos os projetos </li></ul>
  76. 76. Requisitos de Dados <ul><li>A estrutura de codificação de fases, atividades, recursos e projetos sejam utilizadas em todo o portfólio </li></ul><ul><li>Recursos compartilhados pertençam a um “pool” corporativo de recursos </li></ul>
  77. 77. Requisitos de Dados <ul><li>Recursos do mesmo tipo dividem as mesmas características (atributos comuns de peso, unidade, volumes, etc) </li></ul><ul><li>Atribuições típicas de recursos dividem as mesmas características (produtividade, custos, requisitos de materiais). </li></ul>
  78. 78. Requisitos de Dados <ul><li>Processos típicos são modelados da mesma forma entre todos os projetos </li></ul><ul><li>Estes itens e os requisitos de simulação de performance definem as estruturas de dados necessárias e algumas distinções serão vistas quando necessário. </li></ul>
  79. 79.
  80. 80. Estrutura de Dados <ul><li>Os elementos de qualquer modelo computacional de projeto são: </li></ul><ul><ul><li>Atividades de Projeto; </li></ul></ul><ul><ul><li>Dependências entre atividades; </li></ul></ul><ul><ul><li>Recursos e sua aplicação; </li></ul></ul><ul><ul><li>Calendários e Custos; </li></ul></ul><ul><ul><li>Estruturas Analíticas de: Trabalho, Recursos e Custos. </li></ul></ul>
  81. 81.
  82. 82. Dados de Atividades <ul><li>Normalmente atividades de projetos são caracterizadas por suas durações. </li></ul><ul><li>Além disso, é freqüentemente necessário se estabelecer o volume físico de trabalho correspondente a atividade. </li></ul>
  83. 83. Dados de Atividades <ul><li>Volumes de atividades podem ser medidos em metros, em toneladas, unidades, percentuais, horas planejadas ou qualquer outra unidade. </li></ul>
  84. 84. Dados de Atividades <ul><li>Diferente da duração, o volume de uma atividade não depende do recurso atribuído. </li></ul><ul><li>Uma atividade que descreva uma obra civil, um pedaço de software, um documento necessário por sua unidade de volume (m 2 , caso de uso, unidade) pode ser aplicada em um ou vários projetos. </li></ul>
  85. 85. Dados de Atividades <ul><li>A duração desta atividade é então o RESULTADO da quantidade de recursos disponíveis, o volume a ser realizado e a produtividade esperada. </li></ul>
  86. 86. Dados de Atividades <ul><li>A aplicação de VOLUMES permite definir os requerimentos de custo e materiais típicos por unidade (tijolos por m 2 ou pontos de função por caso de uso). </li></ul>
  87. 87. Dados de Atividades <ul><li>A base corporativa de dados pode então fornecer informações para cada projeto referentes ao uso de recursos típicos em função de produtividade ou índice de produção. </li></ul>
  88. 88. Dados de Dependências <ul><li>Normalmente é necessário se criar mais do que uma dependência entre tarefas (início-início & fim-fim, por exemplo). </li></ul><ul><li>Além dos “lags” positivos e negativos entre atividades, pode ser útil se criar “lags” baseados em VOLUMES (A solda entre tubos ocorre quando X tubos já foram desfilados; Os testes começam quando X casos de uso foram integrados). </li></ul>
  89. 89. Dados de Recursos <ul><li>Além de recursos individuais pode ser necessário se estabelecer as equipes/grupos e também as habilidades/papéis </li></ul><ul><li>Um “recurso-múltiplo” é um conjunto de recursos trabalhando juntos, como um time, um “carro com motorista”, um “computador com software”, etc) </li></ul>
  90. 90. Dados de Recursos <ul><li>Recursos são divididos em duas categorias: </li></ul><ul><ul><li>Renováveis (recursos humanos e equipamentos) </li></ul></ul><ul><ul><li>Consumíveis (materiais e equipamentos aplicados) </li></ul></ul><ul><li>Deve ser possível se atribuir materiais a recursos definindo seu consumo e não apenas as atividades (consumo de gasolina em um automóvel, por exemplo) </li></ul>
  91. 91. Dados de Recursos <ul><li>Se diferentes recursos podem fazer um mesmo trabalho então eles tem a mesma habilidade ou papel. </li></ul><ul><li>Recursos com a mesma habilidade são substituíveis entre si, apesar de poderem ter produtividades diferentes realizando a mesma atividade. </li></ul>
  92. 92. Dados de Recursos <ul><li>Um recurso pode ser utilizado em diferentes habilidades ou papéis. </li></ul><ul><li>Para cada papel, um recurso pode ter uma produtividade específica e consumir materiais/custos de uma forma específica. </li></ul>
  93. 93. Dados de Atribuições <ul><li>Atribuir recursos a atividades exige a noção de “equipe” – um grupo de recursos trabalhando em uma atividade juntos. </li></ul><ul><li>Uma “equipe” pode conter recursos individuais, múltiplos e habilidades/papéis. </li></ul>
  94. 94. Dados de Atribuições <ul><li>Para a definição de trabalhos parciais é necessário estabelecer tanto o percentual do recurso atribuído como sua quantidade. </li></ul><ul><ul><li>O uso de “cargas” ou “percentuais de aplicação” visto em alguns softwares não é suficiente pois para um projeto pode ser diferente ter dois recursos 50% do tempo do que ter 1 recurso 100% do tempo. </li></ul></ul>
  95. 95. Dados de Atribuições <ul><li>Um recurso útil para otimização de cronogramas é o registro de uso variável de recursos. </li></ul><ul><ul><li>Exemplo: Defini-se que o recurso X será utilizado com uma carga mínima de 40% e uma quantidade mínima de 3 unidades. Isso permite que uma atividade inicie com recursos parciais e receba novos recursos na medida em que eles estiverem disponíveis. </li></ul></ul>
  96. 96.
  97. 97. Dados de Atribuições <ul><li>Além de consumir materiais em uma atividade (processo), em alguns projetos é necessário se calcular a produção de materiais , de forma com que possam determinar o fluxo de ações para atividades subseqüentes. </li></ul>
  98. 98. Calendários <ul><li>Uma ferramenta corporativa deve conter mecanismos claros e detalhados para garantir a atribuição de calendários personalizados para: </li></ul><ul><ul><li>Atividades </li></ul></ul><ul><ul><li>Recursos </li></ul></ul><ul><ul><li>Relacionamentos (dependências) e “lags” </li></ul></ul>
  99. 99. Dados de Custos <ul><li>Normalmente não é suficiente definir custos por atividades e recursos e é necessário se conhecer todos os gastos e receitas, o que se gastará com impostos, aluguéis, equipamentos e etc. </li></ul><ul><li>Em alguns casos é necessário se conhecer taxas de retorno e câmbios de moedas </li></ul>
  100. 100. Dados de Custos <ul><li>Componentes de custo devem ser utilizados de diversas formas para garantir um gerenciamento de custos adequado </li></ul><ul><li>Deve-se expressar inclusive os desperdícios, como por exemplo o custo de equipamentos parados ou pessoal mobilizado sem atividades de projeto. </li></ul>
  101. 101.
  102. 102. Cálculo de Desperdício: recurso ativo x ocioso R$ 154.560 28 dias
  103. 103. Otimização de Cronograma = Redução do Desperdício R$ 138.000 25 dias
  104. 104. Economia de 11% ao tratar dados de custo adequadamente
  105. 105.
  106. 106. Centros de Materiais, recursos e custos <ul><li>A tomada de decisão em nível de portfólio ou mesmo no projeto necessita diversas formas de se comparar a realização x previsões. </li></ul><ul><li>Centros de custo, materiais e recursos permitem análises detalhadas de diversas faces de um mesmo projeto. </li></ul>
  107. 107. Múltiplas EAPs (WBS) <ul><li>A reorganização de atividades em diferentes Estruturas Analíticas de Projeto facilitam a identificação e detalhamento do escopo além de diferentes tipos de relatórios e mecanismos de controle. </li></ul><ul><li>Sugere-se pelo menos a construção de uma EAP baseada em entregáveis, outra em processos e uma terceira em responsáveis. </li></ul>
  108. 108. Múltiplas EAPs (WBS) <ul><li>Atividades sem atribuição de pacotes: </li></ul>
  109. 109. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “entregáveis” </li></ul>
  110. 110. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “responsabilidade” </li></ul>
  111. 111.
  112. 112. Arquivos de Projeto <ul><li>Um sistema de gestão de projetos deve ser capaz de permitir a análise de cenários não apenas entre um cronograma principal e uma linha de base, mas em função de múltiplas situações (medições diárias, semanais e mensais; cenários de risco; cenários de alternativas, etc) </li></ul><ul><li>Arquivos de projeto devem ser versionados. </li></ul>
  113. 113. Livros de Referência (bancos corporativos) <ul><li>Um sistema de gestão de projetos deve possuir padrões para aplicação em todo o portfólio. </li></ul><ul><li>Padrões devem incluir não somente processos e modelos, mas também estimativas (custo, prazo, recursos) de atividades típicas. </li></ul>
  114. 114.
  115. 115. Biblioteca de “Fragnets” <ul><li>Uma “fragnet” é um conjunto típico de processos que pode ser utilizado diversas vezes. </li></ul><ul><li>A criação de uma “fragnet” permite a modelagem detalhada de situações de projeto e sua reaplicação com maior segurança em novos projetos. </li></ul>
  116. 116. Biblioteca de “Fragnets” <ul><li>Em TI, as atividades habituais de levantamento de requisitos, arquitetura, desenvolvimento e testes baseados em um “caso de uso” pode ser uma “fragnet” reaplicada em um projeto com dezenas de casos de uso. </li></ul><ul><li>Pesos e ajustes finos são feitos no conjunto, aproveitando-se do ganho em produtividade na preparação do plano inicial. </li></ul>
  117. 117. Biblioteca de “Fragnets” <ul><li>Em engenharia civil, uma “fragnet” para a montagem de “um canteiro” pode conter os recursos mínimos em uma situação padrão e depois ser detalhada com base a volumes (tamanho do canteiro ou mesmo tipo de terreno). </li></ul><ul><li>Uma “fragnet” contém: </li></ul><ul><ul><li>Em situações típicas, quem faz o quê, em quanto tempo, por quanto, em que condições, por quanto e com que materiais e métodos. </li></ul></ul>
  118. 118. Continuação <ul><li>O complemento segue os slides originais. </li></ul><ul><li>Clique aqui para retornar a Parte 3 </li></ul>

×