Você pode me dizer como posso usar o valor de folga em meu diagrama de rede para reajustá-lo (se for aplicável)? Usando a tabela a seguir, calculei o valor da folga e desenhei um diagrama de rede. 
Encontrando o valor da folga: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Quero manter a duração do projeto original intacta (portanto, estou não vai mudar o número de semanas usadas no caminho crítico). Mas quero reduzir o número de semanas usadas em caminhos não críticos. Posso fazer isso usando os valores de folga (ou outro método)?
Comentários
- Isso está mais relacionado ao gerenciamento de projetos? ou uma questão de como alguém escreve o software para descobrir um cronograma mais estreito?
- @MichaelT Olá, está ' mais relacionado ao gerenciamento de projetos
- Ok, obrigado. não ' não sabia onde fazer a pergunta. pessoas em stackoverflow me disseram para postar aqui.
- É melhor sinalizar uma pergunta para migração para outro site em vez de repostagem. Dessa forma, os links de " pertencentes a esse " são mais claramente estabelecidos na troca de pilha. Reenviar uma pergunta significa que você tem uma pergunta fechada em um local e uma aberta em outro. O pessoal do SO muitas vezes é da opinião de que tudo o que não ' pertence ao SO pertence ao P.SE, que não ' está sempre correto . Se você tiver dúvidas sobre onde algo pertence, geralmente é aconselhável entrar em uma sala de bate-papo (P.SE ' a sala de bate-papo é chamada de o quadro branco e pergunte.
- Por que você deseja fazer isso?
Resposta
TL; DR
Seus valores flutuantes para tarefas subcríticas não são realmente fracos para o resto do projeto. Você pode aumentar flutuar em sub- tarefas críticas com técnicas de gerenciamento de projeto padrão, como:
- Reduzir o escopo dos elementos subcríticos da tarefa.
- Aumentar os recursos atribuídos a cada tarefa ou marco.
- Eliminando marcos ou elementos de trabalho não essenciais.
Embora não seja recomendado, você também pode aplicar técnicas do caminho crítico como “fast-tracking” ou “crashing the path” de tarefas subcríticas, mas isso não faz parte da metodologia oficial. Aplicando essas técnicas longe da crítica A cadeia pode reduzir a duração da falha das tarefas subcríticas, mas geralmente canibaliza recursos do caminho crítico para isso.
Para que serve o Slack
O Slack em um cronograma de projeto geralmente atinge vários objetivos principais:
- Desotimiza subprocessos para facilitar o plano geral do projeto.
- Evita que a falácia de 100% de utilização torne seu processo frágil.
- Oferece muito tempo, dinheiro ou capacidade de equipe para pedir emprestado, em vez de forçar um recálculo de seu plano a cada soluço.
Seu caminho crítico não tem folga
Seu caminho crítico tem folga zero. Você define o caminho crítico como:
A-> B-> E-> F = 14 semanas é o caminho crítico
Nenhuma das ligações entre o caminho crítico tem folga. Se isso é verdade ou não na vida real, não tenho ideia. No entanto, seu diagrama diz explicitamente Slack = 0 para cada um dos itens do caminho crítico. Considere que:
(0 float) * (4 chained milestones) = no slack on critical path Uma vez que você tem zero folga em sua cadeia crítica, qualquer imperfeição de processo da vida real criará um empecilho em sua projeto. Isso significa que nenhum item em seu caminho crítico pode aceitar qualquer derrapagem sem forçá-lo a recalcular toda a programação e pode forçá-lo a reavaliar seu orçamento ou datas de envio também. Isso parece ruim.
Seu caminho subcrítico não adiciona folga
Atrasos em tarefas ou marcos que não estão em seu caminho crítico não devem atrasar o projeto geral. Você não definimos o que essas tarefas não críticas representam, mas como não estão no seu caminho crítico, provavelmente representam:
- Recursos opcionais.
- Escopo adicional.
- Agradável.
- Exercícios de realimentação de bolo de frutas ou qualquer outra coisa igualmente não relacionada a um produto que pode ser entregue.
Independentemente do que eles representam, e mesmo que sejam essenciais para o produto final, a folga em tarefas subcríticas apenas permite que você ajuste as datas de início ou término dessas tarefas dentro das tolerâncias; eles não compram nada para você relacionados à sua cadeia crítica.
Um modelo melhor para o Slack com caminho crítico
De acordo com a entrada da Wikipedia sobre o método do caminho crítico :
Embora o diagrama de atividade na seta (“Gráfico PERT”) ainda seja usado em alguns lugares, ele geralmente foi substituído pela atividade- diagrama no nó, onde cada atividade é mostrada como uma caixa ou nó e as setas representam os relacionamentos lógicos que vão do predecessor ao sucessor, conforme mostrado aqui no “Diagrama de atividade no nó”.
O benefício deste modelo em relação ao que está em sua pergunta é que ele permite modelar a variância no caminho crítico, que é algo que sua amostra atualmente não fornece. Portanto, pode valer a pena reavaliar o que você está tentando modelar e se a atividade no nó fornecerá uma ferramenta de planejamento melhor para seu caso de uso específico .
Resposta
Mas eu quero reduzir o número de semanas usadas em caminhos não críticos.
Estou lendo isso porque você deseja que a duração total da sua rede de caminhos não críticos diminua, aumentando assim a folga nesses caminhos. Para fazer isso, tudo o que você precisa fazer é diminuir a duração prevista dos pacotes que estão fora do caminho crítico.
No entanto, não tenho certeza de qual é o valor em fazer isso. A suposição inicial é que, dentro da distribuição probabilística de duração de cada um de seus pacotes, você está almejando uma duração que está em algum lugar em torno do MODO dessa distribuição, uma meta que representa uma possibilidade realista, mas também enxuta o suficiente para não constituir excesso de buffer. Ao reduzir essa duração, você aumenta o risco e, para mitigar, acaba aumentando a utilização de recursos e / horas de trabalho para cumprir a meta de duração mais agressiva. Duração = Trabalho / Utilização de recursos.
Isso, então, ameaça a atividade de trabalho nesses pacotes no caminho crítico, o que ameaçará diretamente sua duração geral.
Claro, do outro lado disso, você está aumentando sua folga, de modo que tem alguns ciclos para lidar com variações desfavoráveis de cronograma. No entanto, tudo isso parece ótimo no papel, mas sua realidade será muito diferente.
Seu outro risco é que seu caminho crítico no planejamento é válido apenas no planejamento. No momento em que você pressiona ir e começar a trabalhar e começar a progredir seus pacotes na programação, seu (s) caminho (s) crítico (s) IRÃO mudar e mudar e mudar e mudar. Esses pacotes cuja duração arbitrariamente reduziu podem e provavelmente cairão no (s) novo (s) caminho (s) crítico (s) e, como você reduziu a duração e aumentou sua ameaça, agora você criou uma ameaça maior para a duração geral de sua programação.
De modo geral, não consigo ver a lógica do que você está tentando fazer a partir de uma perspectiva de programação / planejamento. Isso não significa que não haja lógica, simplesmente não consigo ver e nunca ouvi ninguém discutir isso antes.