Pouvez-vous me dire comment puis-je utiliser la valeur de marge dans mon diagramme de réseau pour le réajuster (si cela est applicable)? En utilisant le tableau suivant, jai calculé la valeur de la marge et dessiné un diagramme de réseau. 
Recherche de la valeur Slack: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Je souhaite conserver la durée initiale du projet intacte (par conséquent, je suis ne va pas changer le nombre de semaines utilisées dans le chemin critique). Mais je souhaite réduire le nombre de semaines utilisées dans les chemins non critiques. Puis-je faire cela en utilisant les valeurs de slack (ou une autre méthode)?
Commentaires
- Est-ce plus lié à la gestion de projet? ou une question de savoir comment écrire le logiciel pour découvrir un calendrier plus serré?
- @MichaelT Salut, il ' est plus lié à la gestion de projet
- Daccord, merci. ' je ne savais pas où poser la question. les gens de stackoverflow mont dit de le publier ici.
- Il est préférable de signaler une question pour la migration vers un autre site plutôt que pour la republier. De cette façon, les liens de " cela appartient là-bas " sont plus clairement établis dans léchange de pile. Republier une question signifie que vous avez une question fermée à un endroit et une question ouverte à un autre. Les responsables du SO sont souvent d’avis que tout ce qui ' nappartient pas au SO appartient au P.SE qui n’est pas ' toujours correct . Si vous avez des questions sur la place de quelque chose, il est souvent conseillé de rejoindre une salle de chat (la salle de chat de P.SE ' sappelle le tableau blanc et demandez.
- Pourquoi voulez-vous faire cela?
Réponse
TL; DR
Vos valeurs flottantes pour les tâches sous-critiques ne sont pas réellement relâchées pour le reste du projet. Vous pouvez augmenter le flottant sur les sous- tâches critiques avec des techniques de gestion de projet standard telles que:
- Réduction de la portée des éléments de tâche sous-critiques.
- Augmentation des ressources affectées à chaque tâche ou étape.
- Élimination des jalons ou des éléments de travail non essentiels.
Bien que cela ne soit pas recommandé, vous pouvez également appliquer des techniques à partir du chemin critique telles que le « suivi accéléré » ou le « blocage du chemin » des tâches sous-critiques, mais cela ne fait pas vraiment partie de la méthodologie officielle. Appliquer ces techniques loin de la critique La chaîne l peut réduire la durée de crash des tâches sous-critiques, mais cannibalise généralement les ressources du chemin critique pour ce faire.
À quoi sert Slack
Slack dans un calendrier de projet remplit généralement plusieurs objectifs principaux:
- Désoptimise les sous-processus afin de lisser le plan de projet global.
- Empêche lerreur dutilisation à 100% de rendre votre processus fragile.
- Vous donne du temps, de largent ou la capacité de votre équipe à emprunter, plutôt que de forcer un recalcul de votre plan à chaque hoquet.
Votre chemin critique na aucune marge
Votre chemin critique na aucune marge. Vous définissez le chemin critique comme suit:
A-> B-> E-> F = 14 semaines est le chemin critique
Aucun des liens entre le chemin critique na de marge. Que ce soit vrai ou non dans la vraie vie, je nen ai aucune idée. Cependant, votre diagramme indique explicitement Slack = 0 pour chacun des éléments du chemin critique. Considérez que:
(0 float) * (4 chained milestones) = no slack on critical path Puisque vous avez zéro de mou dans votre chaîne critique, toute imperfection réelle du processus créera une traînée sur votre projet. Cela signifie quaucun élément de votre chemin critique ne peut accepter aucun glissement du tout sans vous obliger à recalculer lintégralité de votre calendrier, et peut également vous obliger à réévaluer votre budget ou vos dates de livraison. Cela semble mauvais.
Votre chemin sous-critique n’ajoute pas de marge
Les retards dans les tâches ou les jalons qui ne sont pas sur votre chemin critique ne devraient pas retarder l’ensemble du projet. Vous n « ai pas défini ce que ces tâches non critiques représentent, mais comme elles » ne sont pas sur votre chemin critique, elles représentent probablement:
- Fonctionnalités facultatives.
- Portée supplémentaire.
- Nice-to-haves.
- Exercices de re-cadeaux de gâteaux aux fruits, ou autre chose tout aussi sans rapport avec un produit livrable.
Indépendamment de quoi ils représentent, et même sils sont essentiels au produit final, le relâchement des tâches sous-critiques ne vous permet dajuster les dates de début ou de fin de ces tâches que dans les limites des tolérances; ils ne vous achètent rien liés à votre chaîne critique.
Un meilleur modèle pour Slack avec chemin critique
Selon lentrée de Wikipedia sur la méthode du chemin critique :
Bien que le diagramme dactivité sur flèche (« Graphique PERT ») soit encore utilisé à quelques endroits, il a généralement été remplacé par lactivité- diagramme sur nœud, où chaque activité est affichée sous forme de boîte ou de nœud et les flèches représentent les relations logiques allant du prédécesseur au successeur, comme indiqué ici dans le « diagramme Activité-sur-nœud ».
Lavantage de ce modèle par rapport à celui de votre question est quil vous permet de modéliser la variance sur le chemin critique, ce que votre échantillon ne fournit actuellement pas. Il peut donc valoir la peine de réévaluer ce que vous essayez de modéliser, et si l’activité sur nœud fournira un meilleur outil de planification pour votre cas d’utilisation spécifique .
Réponse
Mais je souhaite réduire le nombre de semaines utilisées dans les chemins non critiques.
Je lis ceci car vous voulez que la durée totale de votre réseau de chemins non critiques diminue, augmentant ainsi la marge sur ces chemins. Pour ce faire, il vous suffit de réduire la durée cible des packages qui se trouvent hors du chemin critique.
Cependant, je ne suis pas sûr de la valeur de cela. Lhypothèse initiale est que, dans la distribution probabiliste de la durée de chacun de vos packages, vous ciblez une durée qui se situe quelque part autour du MODE de cette distribution, une cible qui représente une possibilité réaliste mais aussi suffisamment maigre pour ne pas constituer un sur-tampon. Lorsque vous réduisez cette durée, vous augmentez le risque et, afin datténuer, vous finissez par augmenter lutilisation des ressources et / les heures de travail afin de respecter la durée cible plus agressive. Durée = Utilisation du travail / des ressources.
Cela menace alors lactivité de travail sur ces packages sur le chemin critique, ce qui menacera directement votre durée globale.
Bien sûr, de lautre côté de cela, vous augmentez votre marge de manœuvre, vous disposez donc de quelques cycles pour faire face aux variations dhoraires défavorables. Cependant, tout cela semble super sur papier, mais votre réalité sera très différente.
Votre autre risque est que votre chemin critique lors de la planification nest valide que lors de la planification. Au moment où vous appuyez sur go et commencez le travail et commencez à faire progresser vos paquets dans le calendrier, votre ou vos chemins critiques changeront et changeront et changeront et changeront. Les packages dont vous avez arbitrairement réduit la durée peuvent et vont probablement tomber dans le (s) nouveau (x) chemin (s) critique (s) et, puisque vous avez réduit la durée et augmenté votre menace, vous avez maintenant créé une menace plus importante pour la durée globale de votre calendrier.
Dans lensemble, je ne vois pas la logique de ce que vous essayez de faire du point de vue de la planification / planification. Cela ne veut pas dire quil ny a pas de logique, je ne peux tout simplement pas le voir et je nai jamais entendu personne en parler auparavant.