Tag Archives: Hammok

Considerações sobre Hammoks e Exemplos aplicados

  By Isadorasm | 23/06/2009 - 5:42 pm | Publicações
Leave a comment

     No Practice Standard of Scheduling (publicação do PMI®), uma hammock é colocada como sinônimo de tarefas-sumário e deveriam, portanto reunir informações sobre a duração das atividades a ela vinculadas.

     O termo hammock surgiu muito antes do standard e tem implementações com funções mais completas em softwares como o Primavera e Spider.

     Como mecanismo básico, a hammock é “presa nas pontas” por outras atividades distribuídas no projeto e portanto passa a ter a duração da rede entre as atividades que “esticam as pontas da hammock”. O nome “hammock” corresponde a outro tipo de rede: aquela de dormir, como as que vemos no Ceará ou nos barcos de transporte do Amazonas.

     Uma hammock portanto pode ser uma sumarizadora de atividades que estão em distintas partes de uma EAP. Diferente da Tarefa-Sumário como encontramos no MSProject, ou as “Fases” no Spider, a hammock pode ser influenciada por elementos distribuídos por todo o projeto, sem uma hierarquia pré-definida.

 

O texto completo contém:

- Ilustrações de diferentes tipos de hammock.
- Aplicação na distribuição de atividades de projeto.
- Cálculo de desperdícios.
- Simulação de opções de nivelamento em projeto.

 

Abra o texto completo em PDF em:
[link ainda não disponível em função das mudanças do site do Spider Team]

Tarefa Hammock (Debate) – Parte II

  By Isadorasm | 21/06/2009 - 7:55 pm | Publicações
Leave a comment

Antes de continuar, algumas considerações:

1- Este material surgiu em função de um debate na lista da E-Plan.
2- Você pode visualizar a parte I do Debate (Clicando aqui)
3- Você pode saber mais sobre o tema abortado – Hammocks & Exemplos aplicados – (Clicando aqui)

___________________________________
Carta de Farhad Abdollahyan sobre Hammocks:

 

     Caro Peter,

     Para começar, no exemplo não sei de onde vem a Corrente Critica (30 dias)!!! E depois o 25 dias, dado que as atividades supostamente tinham 10 (C) e 20 dias (A, B e D) de duração!

     Dependendo da maneira que nivelarmos o projeto, passamos de 40 dias sem nivelamento para 50 ou 60 dias, dado que o caminho crítico sem nivelamento é Início-A-B-Fim. (0+20+20+0). Se colocarmos uma prioridade maior no C, o MS Project nivelará a atividade A e teremos:

“corrente crítica” = (C)Farhad 10 + (A) Farhad 20 + (B) Peter 20 = 50

Senão teremos

“corrente crítica” = (A) Farhad 20 + (B) Peter 20 + (D)Peter 20 = 60

     Em segundo lugar, creio que está cometendo um erro crasso de conceito e outro de entendimento do problema!

     Quando escreve que “Se eu prender uma atividade HAMMOCK em INICIO e FIM e colocar FARHAD e Peter como recurso utilizado nela” não faz menor sentido. Uma atividade “Hammock” ou “Summary Activity” é “um grupo de atividades do cronograma agregadas, relacionadas em algum nível de resumo e exibidas/relatadas como uma única atividade no nível de resumo”, em outras palavras, uma Hammock não é uma atividade de verdade, é apenas uma sumarizadora, portanto, não devemo alocar recurso nela diretamente.

     Para criar uma HAMMOCK, criamos um marco de início e um de fim e relacionamos logicamente as atividades desta sub-rede (ou sub-projeto) e temos uma hammock. No MS Project conseguimos este efeito criando uma indentação, e o SW demonstra uma barra preta variável (como você disse) cujo início tem uma relação início a início com a primeira atividade da rede e o seu ponto final tem uma relação término a término com a última (no seu exemplo “início” e “Fim” respectivamente).

     De certa forma, representa o pacote de trabalho.

     O outro erro seu é que recomenda uma atividade sumarizadora para o colega que tem dois grupos de atividades distintas:

     (1) Atividades que irão produzir as entregas propriamente ditas, e (2) Atividades de fiscalização e apoio que não geram entregas tangíveis.

     Se indentar as atividades principais e criar a super guarda-chuva (HAMMOCK) não irá resolver o problema do colega, pois o que ele quer realmente é poder inserir atividades de fiscalização e apoio.

     E não se trata de questão de SW, pois para dizer a verdade, o MS Project até permite associar recurso a esta atividade sumarizadora (e calcularia os custos como o colega quer), mas este macete tem dois problemas: (a) MSP soma os custos das atividades de sub-rede com os custos dos recursos alocados diretamente na Hammock e mostra tudo no Hammock, isto pode confundir! (b) Da mesma forma que não é correto colocar predecessor ao nível da Hammock, não devemos também alocar recurso no Hammock.

Abraço,

Farhad

 

———————————————————————————————————
Peter Mello, em resposta a carta:

 

      Farhad,
      Meu erro foram as unidades. Eu comecei com a unidade DIA e depois coloquei o custo HORA. Onde eram 20 e 10 dias, eu fiz o exercício com 10 e 5 dias (portanto basta dividir os seus achados por 2 para acertar com meu erro de unidades).
O raciocínio está correto e os resultados (ajustados) também:
- seus 60 dias seriam os meus 30
- seus 50 dias seriam os meus 25.
- o valor hora é de fato R$ 1,25 (para dar os R$ 10,00 por dia que usei nas minhas contas)
No entanto:

      A) O MSProject precisa que você faça ajustes manuais durante o nivelamento para achar o melhor resultado. Se você tiver 4 ou 40 atividades, vai conseguir fazer a priorização correta e ter um bom retorno. Se tiver 400 ou 4000 atividades, não pode depender de priorizações manuais para encontrar o melhor nivelamento
      B) O MSProject não mostra a corrente crítica. Apenas coloca em vermelho os elementos pertencentes ao caminho crítico CPM e portanto todas as folgas não tem qualquer utilidade.
      Quanto aos usos da HAMMOCK:
      - A descrição da Hammock no Practice Standard of Scheduling nasceu DEPOIS das hammocks serem inventadas e aplicadas em diversos softwares. Não é por que o Practice Standar diz que a hammock só pode ser utilizada para A, B ou C que ela também não possa ser usada para D, E ou F. No entanto, a regra MÍNIMA estabelecida para uma hammock é que ela seja capaz de agregar durações provenientes das atividades que ela sumariza. No Standard, tarefa sumário e hammock são sinônimos, o que não é exato. A hammock se presta a sumarizar atividades que não estão em subitens da mesma decomposição da EAP, enquanto a tarefa sumário está sempre presa a estrutura hierárquica da decomposição.
      - Por estas “funções extras” da hammock que não estão no Practice Standard e nem no MSProject, mas estão no Primavera e no Spider é que a hammock se presta exatamente ao que o colega quer, durante sua análise de fiscalização.
     - Você sabia que durante o preparo do Practice Standard houve uma votação para ver se “cronograma nivelado por recurso” deveria entrar ou não no Standard? Como a base dos desenvolvedores é americana e eles usam CPM e prestam pouca atenção a CCPM ou qualquer método que faça nivelamento adequado de recursos, cronogramas baseados por recursos quase não foram contemplados no Practice Standard.
     - Se isso tivesse acontecido, isso iria fazer com que as pessoas que utilizam corrente crítica ou resource critical path deixassem de usar ? O standard não é prescritivo e sim descritivo.
Vou preparar um PDF com tudo, para você ver como funciona.

 

Abraços,
Peter.

Tarefa Hammock (Debate) – Parte I

  By Isadorasm | 20/06/2009 - 9:42 pm | Publicações
Leave a comment

Antes de continuar, algumas considerações:

1- Este material surgiu em função de um debate na lista da E-Plan.
2- Você pode visualizar a parte II do Debate (Clicando aqui)
3- Você pode saber mais sobre o tema abortado – Hammocks & Exemplos aplicados – (Clicando aqui)

 

Carta de Farhad Abdollahyan sobre Hammocks:
___________________________________________

 

—– Original Message —–
From: Farhad Abdollahyan, PMP
To: planejamento@yahoogrupos.com.br
Sent: Friday, June 19, 2009 12:06 PM
Subject: [E-Plan.br *9 Anos*] – Re: Tarefa Hammock

 

      Caro Peter,
      Não pretendo polemizar, mas cabe alguns esclarecimentos:

     (1) o colega usa MS Project, não SPIDER ou Primavera, portanto, o que lhe aconselhei resolverá o problema dele.

     (2) O que eu estou colocando, em termos de pacotes de trabalho e atividades gerenciais, também deve ser valido em qualquer outra ferramenta (Spider, I-Nexus, Primavera, Clarity, etc.), pois, a partir do momento em que alguém colocasse uma atividade que começa com marco inicial do projeto e que termine com o marco final esta tarefa se transforma em um dos caminhos críticos do projeto.
É simples assim!
Se nivelasse esta atividade, em qualquer SW decente de GP, o prazo total do projeto irá estender, o que convenhamos é um contra-senso total!
     (3) Não faz sentido de fazer nivelamento de recursos em atividades gerenciais (fiscalização e apoio) se este nivelamento afetar as datas de entregas técnicas, pois como mencionei “… é correto considerar atividades gerenciais como críticas apenas por que estão no caminho crítico? Estas tarefas realmente atrasam o projeto? A resposta é não!”, ou pelo menos não deveriam! Você não deve atrasar um projeto por que não tem fiscal para liberar ou homologar uma entrega. Não é uma boa prática! Ao contrário, deve adicionar recursos ou mudar a fiscalização de tal sorte que esta atividade não se torne burocrática atrasando o projeto, não acha?
     (4) O que defendo é que as atividades (meio) de apoio gerencial, ou devem ser espalhados ao longo de todos os pacotes de trabalho, ou devem ser concentrados num subprojeto sem amarração com as entregas para não afetar o cerne, ou seja as entregas (fim) que adicionam valor ao cliente. Alias, esta minha posição é respaldada pela técnica de Product-based Planning do PRINCE2.
Se pensar um pouco fora da caixa (do SPIDER), pelo menos por alguns momento, verá que tenho razão.

 

Forte abraço,
Farhad

 

——————————————————————————————————
Peter Mello, em resposta a carta:

 

     Farhad,

     Você se esquece que quando dá uma informação genérica e categórica sobre hammock sem de fato dizer onde se aplica sua resposta, você infelizmente vai passar a informação equivocada para quem não está acompanhando a mensagem desde o início.
Somente alguns – que leram todo o thread – vão saber que o colega usa MSProject e que sua resposta é PARA este caso em particular.

     Quanto as suas afirmações:
     I – “Se nivelasse esta atividade, em qualquer SW decente de GP, o prazo total do projeto irá estender, o que convenhamos é um contra-senso total!”
Errado. Um bom software de nivelamento poderá de fato descobrir formas de REDUZIR o tempo global de projeto por perceber o custo que a atividade de fiscalização tem no projeto. Ele irá buscar alternativas de mudança de prioridades nas atividades reais de projeto para que o valor global do projeto seja REDUZIDO. Lembre-se: a hammock não determina o tamanho do projeto. Ela tem o tamanho de suas atividades determinadas pelas atividades a qual se relaciona. Se eu mudo a ordem entre elas, a hammock DIMINUI.

Exemplo:
Inicio>A>B>Fim
Inicio>C>D>Fim
- A, B e D tem 20 dias
- C tem 10 dias
- A e C são executadas por FARHAD
- B e D são executadas por PETER
- FARHAD custa R$ 10,00 a hora
- PETER custa R$ 10,00 a hora.
- Se eu prender uma atividade HAMMOCK em INICIO e FIM e colocar FARHAD e Peter como recurso utilizado nela, então o software irá calcular:
- Farhad: Uso em A, C e também em todo o tempo restante do projeto.
- Peter: Uso em B e D.

     NOTA: após o envio do email (editado no Blog): As durações A,B,D são de fato 10 dias e C apenas 5 dias. O valor de R$ 10,00 é por DIA, não por HORA.

     Se eu utilizar um nivelamento padrão de mercado, eu vou ter a rede nivelada por recurso assim:

Corrente Crítica (30 dias)
- Início>A (FARHAD, 10 dias = 100 reais) > B (PETER, 10 dias = 100 reais) > D (PETER, 10 dias = 100 reais) > FIM
Caminho Não Crítico:
A > C (FARHAD, 5 dias = 50 reais) > FIM
Hammock:
- Irá calcular o custo de Farhad quando não estiver trabalhando = 30 dias – 15 = 15 x 10 = R$ 150,00
- Irá calcular o custo de Peter quando não estiver trabalhando = 30 dias – 20 = 10 x 10 = R$ 100,00

     CUSTO FINAL DO PROJETO = R$ 300 (corrente critica) + R$ 50 (caminho não crítico) + R$ 250,00 (hammock)

     TOTAL: R$ 600,00 (ou 30 dias com 2 pessoas a 10 reais cada)
Se eu utilizar o nivelamento de um BOM SOFTWARE (que você disse que ia aumentar o projeto), o resultado é:

Corrente Crítica (25 dias)
- Inicio>C (FARHAD, 5 dias = 50 reais) > B (PETER, 10 dias = 100 reais) > D (PETER, 10 dias = 100 reais) > FIM
Caminho Não Crítico:
C > A (FARHAD, 10 dias = 100 reais) > FIM
Hammock:
- Irá calcular o custo de Farhad quando não estiver trabalhando = 25 dias – 15 = 10 x 10 = R$ 100,00
- Irá calcular o custo de Peter quando não estiver trabalhando = 25 dias – 20 = 5 x 10 = R$ 50,00

CUSTO FINAL DO PROJETO = R$ 250 (corrente critica) + R$ 100 (caminho não crítico) + R$ 150,00 (hammock)
TOTAL: R$ 500,00 (ou 25 dias com 2 pessoas a 10 reais cada)

 

CONCLUSÃO:
A) A hammock não muda o caminho crítico;
B) A hammock permite o cálculo gerencial de desperdícios em projeto;
C) A hammock apoia o software em tomada de decisão quanto ao melhor sequenciamento entre recursos.

     II – “(3) Não faz sentido de fazer nivelamento de recursos em atividades gerenciais (fiscalização e apoio) se este nivelamento afetar as datas de entregas técnicas… é correto considerar atividades gerenciais como críticas apenas por que estão no caminho crítico? Estas tarefas realmente atrasam o projeto? A resposta é não!”, ou pelo menos não deveriam! Você não deve atrasar um projeto por que não tem fiscal para liberar ou homologar uma entrega.”

     Farhad: Claro que não queremos atrasar um projeto por que a fiscalização não homologou alguma coisa. Mas o fato é que isso ACONTECE e portanto tem que ser levado em consideração em nosso projeto!

     Meu papel não é remover um problema do meu modelo de cronograma por que não quero que ele aconteça. Meu papel é colocar o problema no modelo e descobrir qual é a forma de minimizar o impacto caso isso aconteça. Portanto, exatamente por que um fiscal pode de fato atrasar o projeto e se tornar uma atividade crítica embora não deva ser, eu preciso definitivamente tentar trazer esta situação para o meu modelo e ver alternativas para lidar com o problema!
Você continua “Ao contrário, deve adicionar recursos ou mudar a fiscalização de tal sorte que esta atividade não se torne burocrática atrasando o projeto, não acha?”

     Claro que acho! Exatamente por que pode ser necessário adicionar mais recursos de fiscalização para evitar os problemas é que eu preciso calcular o TEMPO, os RECURSOS e os CUSTOS desta fiscalização como parte do meu projeto!! Somente se eu colocar esta situação no meu cronograma e descobrir COMO atuar com ela é que vou eliminar o problema e não simplesmente tirando a atividade de fiscalização do meu projeto!

Abraço,

 

Peter.