プロジェクトはどのように1年遅れますか？
...「一度に」当日
...フレッドブルックス
投稿を書くというアイデアは、最近、次のケースに対処しなければならないという事実のために生まれました：プロジェクトマネージャーは、プロセスをサポートし、方法論の要件を順守し、メトリックを収集し、プロジェクトに対する高いモチベーションを維持しようとしています。 しかし、作業結果（マイルストーン、成果物）の次の検証の時が来て、プロジェクトの完了の程度が計画されたものより遅れており、必然的に期限につながることがわかります。 そして、プロジェクトマネージャーは、できるだけ早く脅威を排除しようとして、チームに発言し、警告とプライベートモニタリングでプロセスをスピードアップしようとしますが、理由を特定せずに動作することはめったにありません。
問題の原因を特定するための可能なオプションとして（特定の場合-これは時間の使いすぎです）、プロジェクトを監視するためのかなり単純なツールの1つであるパレート図を思い出したいと思います。 このチャートにより、問題を解決するために対処する必要がある優先度の高いタスクを特定できます。 すべての品質管理ツールから、いくつかの理由でパレート図に根ざしたことは注目に値します。
1.使いやすさ。
2.計算の速度と、追加のソフトウェアを使用する必要がないこと。 十分なバグ追跡システムとExcel。
3.データを「遡及的に」処理する機能。 これは、何らかの要因がわからない場合、分析時にいつでも入力できることを意味します。
4.データの可視性。
以下は、開発計画の遅れの理由を判断するためのパレートグラフの構築の詳細な説明です。
そのため、最初の段階で、データとその分類を決定する必要があります。 プロジェクトで、タスクの実行とバグの修正の両方に時間が費やされたとします。 次に、分析のために、バグ追跡システムから次の情報をアンロードするだけで十分です：作成された機能のリストとクローズされたバグ。 時間の浪費があったタスクを分離し、その原因を特定します。 例として、チームで次の要因が特定されたと仮定します。
-タスクの不適切な評価。
-タスクを閉じるときのバグの出現による時間の超過。
次に、バグを引き起こす要因を個別に識別する必要があります。 例として、次の理由も考えられます。
-タスクをテストする時間の不足によるバグの発生。
-機能をテストできないためにバグが発生する（状況をシミュレートすることはできませんでした）。
-バグは、機能の実装のエラー（または予期しないプログラマーのケース）のために現れました。
第2段階では、違反の事実の数を計算する必要があります。 この例では、図1の結果を反映しています。
図1.事実の数
3番目の段階では、各ファクトの時間超過を計算する必要があります（図2）。
図2.時間オーバーランの計算
全体像として、この例では、これらの要因の両方を重要であると推定します。 事実の数は、発生頻度、費やされた時間、影響の度合いを示します。 したがって、両方の値を組み合わせて、要因の数を考慮して時間オーバーランを決定します。 この例の前立腺の計算では、指標を掛けるだけです（図3）。
図3.要因の数を考慮した時間超過
次に、要因の影響を判断します。 このため、これらの要因の合計数（列4の合計）に対する要因の数（4）を考慮して、時間超過の割合を考慮します。 列を降順で並べ替えます（図4）。
図4.要因の影響。
次のステップは、要因の全体的な影響を判断することです。 最大値を持つ最初の因子については、それ自体の値は、後続の各因子-前のプラス自体になります（図5）。
図5.要因の全体的な影響。
最後の段階-プロット。 座標軸が構築されます。 縦軸はパーセンテージ、横軸は問題の原因の数に対応する間隔です。 上記の例では、結果はExcelに組み込まれています（図6）。
図6.パレートグラフ
グラフは各原因の影響の程度を明確に示しており、法80/20（総影響）に従って、結果に影響を与えた主な要因を区別できます。 上記の例では、3つの理由が原因です。
1.タスクをテストする時間の不足によるバグの発生。
2.タスクを閉じるときのバグの出現による時間の超過。
3.機能をテストできないことによるバグの発生（状況をシミュレートすることはできませんでした）。
要点：実践が示しているように、遅れの理由に関するチームの仮定の通常の口頭による質問は、パレート図を構築することによって得られる結果と常に一致します。 さらに、80/20ルールにより、マネージャーは結果の要因を排除することに集中できます。
PS。 投稿が有用であり、説明があまりにも詳細ではないことを願っています。