ネットワーク図のスラック値を使用して再調整する方法を教えてください（該当する場合）。次の表を使用して、スラック値を計算し、ネットワーク図を作成しました。 
スラック値の検索： 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks 元のプロジェクト期間をそのまま維持したい（したがって、私はクリティカルパスで使用される週数は変更されません）。ただし、クリティカルパス以外で使用される週数を減らしたいと思います。スラック値（または別の方法）を使用してそれを行うことはできますか？
コメント
- これはプロジェクト管理に関連していますか？または、より厳しいタイムラインを見つけるためにソフトウェアをどのように作成するかという質問ですか？
- @MichaelTこんにちは、'プロジェクト管理に関連しています
- わかりました、ありがとう。 'どこに質問すればよいかわかりませんでした。 stackoverflowの人々から、ここに投稿するように言われました。
- 再投稿するのではなく、別のサイトに移行するための質問にフラグを立てるのが最善です。そうすることで、"あそこに属する"のリンクがスタック交換でより明確に確立されます。質問を再投稿すると、ある場所で閉じた質問があり、別の場所で開いている質問があることを意味します。 SOの人々は、' SOに属さないものはすべてP.SEに属し、'常に正しいとは限らないと考えることがよくあります。 。何かがどこにあるかについて質問がある場合は、チャットルームに参加することをお勧めします（P.SE 'のチャットルームはホワイトボードと質問します。
- なぜこれを行いたいのですか？
回答
TL; DR
サブクリティカルタスクのフロート値は、プロジェクトの残りの部分では実際にはスラックではありません。サブクリティカルタスクでフロートを増やすことができます。次のような標準的なプロジェクト管理手法を使用した重要なタスク：
- 未重要なタスク要素の範囲を縮小します。
- 各タスクまたはマイルストーンに割り当てられるリソースを増やします。
- 重要でないマイルストーンや作業要素を排除します。
推奨されませんが、クリティカルパスからテクニックを適用することもできます未臨界タスクの「ファストトラッキング」や「パスのクラッシュ」などですが、それは実際には公式の方法論の一部ではありません。批評家から離れてこれらの手法を適用するlチェーンは、サブクリティカルタスクのクラッシュ期間を短縮する可能性がありますが、通常、クリティカルパスからリソースを共食いします。
スラックの目的
プロジェクトスケジュールのスラックは、通常、いくつかの主要な目標を達成します。
- サブプロセスを最適化解除して、プロジェクト全体の計画。
- 100％使用率の誤りがプロセスを脆弱にするのを防ぎます。
- 強制するのではなく、時間、お金、またはチームの能力を借りることができます。あらゆる問題で計画を再計算します。
クリティカルパスに余裕がない
クリティカルパスに余裕がない。クリティカルパスを次のように定義します。
A-> B-> E-> F = 14週間がクリティカルパスです
クリティカルパス間のリンクにたるみはありません。これが実生活に当てはまるかどうかはわかりません。ただし、ダイアグラムには、クリティカルパス項目のそれぞれについて Slack = 0 が明示的に示されています。次の点を考慮してください。
(0 float) * (4 chained milestones) = no slack on critical path クリティカルチェーンにゼロのたるみがあるため、実際のプロセスの欠陥により、事業。つまり、クリティカルパス上のアイテムは、スケジュール全体の再計算を強制せずに のずれをまったく受け入れることができず、予算や出荷日も再評価する必要がある場合があります。それは悪いようです。
サブクリティカルパスはSlackを追加しません
クリティカルパス上にないタスクまたはマイルストーンの遅延は、プロジェクト全体を遅らせるべきではありません。あなたこれらの非クリティカルタスクが何を表すかは定義されていませんが、クリティカルパス上にないため、おそらく次のように表されます。
- オプション機能。
- 追加のスコープ。
- 便利です。
- フルーツケーキの再贈与の演習、または出荷可能な製品とはまったく関係のないその他の方法。
何に関係なくそれらは表しており、最終製品に不可欠である場合でも、クリティカルでないタスクの緩みにより、許容範囲内でそれらのタスクの開始日または終了日を調整することしかできません。何も購入しませんクリティカルチェーンに関連しています。
クリティカルパスを使用したスラックのより良いモデル
クリティカルパス法に関するWikipediaのエントリによると：
矢印のアクティビティ図（「PERTチャート」）はまだいくつかの場所で使用されていますが、通常はアクティビティに取って代わられています-オンノード図。各アクティビティはボックスまたはノードとして表示され、矢印は「ノード上のアクティビティ図」に示されているように、先行から後続への論理関係を表します。
質問のモデルに対するこのモデルの利点は、分散をモデル化できることです。クリティカルパス上で、これはサンプルでは現在提供されていないものです。したがって、モデル化しようとしているものを再評価し、ノード上のアクティビティが特定のユースケースに適した計画ツールを提供するかどうかを再評価する価値があります。 。
回答
ただし、クリティカルパス以外で使用される週数を減らしたい。
クリティカルパスネットワークの合計期間を短縮して、これらのパスのスラックを増やしたいので、これを読んでいます。これを行うには、クリティカルパスから外れているパッケージのターゲット期間を短くするだけです。
しかし、これを行うことの価値はわかりません。最初の仮定は、各パッケージの期間の確率分布内で、その分布のモードの周りのどこかにある期間をターゲットにしているということです。これは、現実的な可能性を表すが、バッファリングを超えないように十分に傾いているターゲットです。その期間を短縮すると、リスクが増大し、軽減するために、より積極的な目標期間を達成するために、リソース使用率や作業時間が増加することになります。期間=作業/リソース使用率。
これにより、クリティカルパス上のパッケージでの作業アクティビティが脅かされ、全体の期間が直接脅かされます。
もちろん、その反対側では、スラックを増やしているので、不利なスケジュールの変動に対処するためにそこにいくつかのサイクルがあります。ただし、これはすべて紙の上では非常によく見えますが、現実は大きく異なります。
もう1つのリスクは、計画におけるクリティカルパスは計画時にのみ有効であるということです。 goを押して作業を開始し、スケジュール内でパッケージの進行を開始した瞬間に、クリティカルパスが変更および変更され、変更および変更されます。期間を任意に短縮したパッケージは、新しいクリティカルパスに分類される可能性があり、またそうなる可能性があります。期間を短縮して脅威を増やしたため、全体的なスケジュール期間に対してより大きな脅威が作成されました。
全体として、スケジューリング/計画の観点から、あなたがやろうとしていることの論理を理解することはできません。それは論理がないという意味ではありません、私はそれを見ることができず、誰もこれについて議論するのを聞いたことがありません。