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.