これは、プロジェクトを予定どおりに実施することが非常に困難である理由と、優先順位を設定することで状況を改善する方法を理解する試みです。
そのため、プロジェクトの開発を始めています。 プロジェクトの目標と概要はすでに特定されていますが、これまでのところ、その実装については何もわかっていません。 どのタスクを解決する必要がありますか？ どのリソースが必要ですか？ 不明。
この段階では、私たちにとってのプロジェクトは具体的なものですが、それでもまだ形のないクラウドです。
必要なのは詳細です。 プロジェクトの目的から始めて、比較的小さな、そして最も重要な、非常に具体的なタスクに段階的に分割します。その解決策は、プロジェクト全体の正常な完了を意味します。
その結果、その技術的な実装の角ばった輪郭は、最初に合理化された設計から生まれます。プロジェクト全体を構成する一連の「レンガ」タスクの形です。 「重くて、失礼な、目に見える。」
そのため、プロジェクトは個別の「ブリック」に分割され、各ブリックは個別に認識と評価の対象となります。 次のステップは、プロジェクト全体を実装するために必要なリソースを特定することです。 この手順はそれほど複雑ではありません。各タスクのリソース強度を個別に評価した後、単純な合計によってプロジェクト全体のコストがわかります。
わかりやすくするために、プロジェクトリソースはテーブルまたはシェルフの形式で表示されます。プロジェクトリソースは、プロジェクトを構成するすべてのタスク（「レンガ」）が一列に配置されます。 各タスクは棚で行われます（つまり、「リソースを消費します」）、棚の寸法はプロジェクトの規模に対応し、もちろん、限られています-ちょうど人生、時間、お金が制限されているのと同じように-または両方同時に。
上記のアクションは、いくつかの重要な質問への回答をすでに提供しているはずです。
- プロジェクトを完了するにはどのようなリソースが必要ですか？
- どのタスクを解決する必要がありますか？
- 各タスクを完了するにはどのようなリソースが必要ですか？
これらは単なる質問への答えではないようです-これは計画です。 その実装に着手します。
時間が経つにつれて、タスクは1つずつ解決され、架空の「リソースシェルフ」に精神的に置かれます。 現在、「リソースシェルフ」には、プロジェクトのどの部分が既に実装されているか、および実際に何個の計画リソースが既に使用されたかが明確に示されます。 もちろん、すべてが計画通りに進んだ場合、完了した各タスクは、当初想定されていたのと同じくらい正確にシェルフ上のスペースを占有します（つまり、リソースを吸収します）。普遍的な世界の調和を強調します。
残念ながら、世界の調和には困難が伴います。 遅かれ早かれ、タスクの1つ（通常は1つではない）が突然、より困難で、より高価で、より長く、または一度にすべてになることが判明しました。 彼女は、事前に割り当てられた場所にはもはや適合していません-彼女は、 いわば、それでいっぱいです。
ここで、最も不愉快な開発の瞬間の1つ、棚からレンガが振りかけられます 。 計画されたよりも多くのリソースを使い果たしたタスクは、それ自体で「より高価」になっただけでなく、まだ実現されていないタスクを取り去りました-破線でダイアグラムにきちんと描かれたタスク。
おそらく幸運はまだ笑っており、すべてのタスクを棚に戻すことができますが、このためには、残りのタスクを計画よりも低コストで実行する必要があります。 この結果はどのくらいありますか？..
私たちは自分自身を欺くことはありませんし、当然のことと思います-遅かれ早かれ、いずれのプロジェクトでも、 レンガが棚から落ちます 。 予定どおりにプロジェクトをリリースしてください。ただし、計画された機能の一部はありません。 非常に多くの場合、 非常に重要なことがプロジェクトの最後に突然現れるからです。
になる方法 問題の解決策は、最初の優先順位付けです。
プロジェクトの確率的性質により、すべてが計画どおりに進むかどうかを完全に確信することはできません。 ランダム性がいつどの方向に作用するかはわかりませんが、タスクがプロジェクトの終わりに近づくほど、実装の「オーバーボード」になる可能性が高くなると確信できます。 時間が足りなかったり、他のリソースがなかったり、プロジェクトの予算を増やせないこともあります。
おそらく、1つまたは複数のタスクを（「予算に入らない」ことで）失う可能性は大きな問題ではありません。 しかし、これは、プロジェクトのいくつかの非常に重要な要素が「削減」に該当する場合にのみ、実際の問題になります。
この理解に基づいて、明白な解決策は、計画段階でタスクを最も重要なものから最も重要でないものに配置し、プロジェクトにとって重要なタスクから実装を開始することです。 したがって、「間に合わない」というリスクはなくなりませんが、最も重要ではない二次的なタスクのみが危険にさらされます。
重要なポイント：他のすべてを「重要」とみなし、「重要でない」タスクから優先順位を設定する場合、先送りするのは難しく、非生産的です。 第一に、プロジェクトの最初から何かを取るに足りない「非常に必要ではない」と見なすことは困難です-さらに計画と実装を行う場合はなおさらです。 第二に、プロジェクトの「二次」を探すと、重要な主要なタスクを見逃すことは非常に簡単です。
「これなしではプロジェクトをリリースできない」という質問をする方がはるかに効果的です。 この質問により、そのような重要なことを忘れることはもはや簡単ではありませんが、テスト、サポートドキュメント、「setup.exe」などのタスクとして、「プロジェクトブリック」を計画するときに見落とされやすくなります。 もちろん、 棚からレンガが落ちるリスクを減らすために、できるだけ早く実装する必要があります 。
要約すると：
- プロジェクトの実装に必要なリソースの初期推定値、および開発プロセスでの実際の消費量は、ランダム性の要素を持つ確率的な量です。
- プロジェクトの確率的性質により、予算不足のリスクがあり、プロジェクトのあらゆる部分の実施を拒否することがよくあります。
- 開発の初期段階で計画されたタスクは、必要なリソースを取得する可能性が最も高くなります。
- 計画段階で優先順位を設定すると、開発の初期段階でプロジェクトの重要なタスクを計画し、最終段階で二次的なタスクを残すことができます。これにより、プロジェクトの最も重要な要素の実装が成功する可能性が高まります。