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.

