リソース計画。 パート2および3。これはリソース計画に依存します。 リソース計画を決定するもの

最初の導入部分の続きでは、2つの重要なトピックをすぐに検討します。 一方では、これらのトピックは、単一のプロジェクトの管理よりも、プロジェクトプログラムまたは会社全体の管理により関連しています。 一方、企業の主要プロセスにおけるリソースプランニングの役割を特定のプロジェクトマネージャーが理解することで、経営陣とのコミュニケーションが大幅に促進され、リソースプランニングの必要性とリソースプランの品質について不適切な議論が行われます。

リソース計画に依存するものは何ですか？

はい、リソース計画は最も創造的なタスクではなく、リソース計画の更新は避けられない悪として多くの人に認識されています。 しかし、Excelのプレートの色付け、タイムシールドからリソースプランへの現在の時間の転送と確認、および従業員の不足、クライアントの不可抗力、新しい合意されたスコープを考慮して、プロジェクトの残りの時間を計画することに多くの時間を費やす必要がある理由を理解しましょう。

1. プロジェクトのマージンと財務計画の計算の正確さ。 すべての会社が財政を計画しています。 会社の収益性の高い部分はプロジェクトの利益です。 プロジェクトが開始時に予測されたよりも収益性が低い場合、会社は期待していたお金を受け取りません。 ボーナスファンドまたは株主所得のわずかな変化についてのみ話している場合は、そうです。 そして、会社が借りたお金で生活しているとしたら？ そうすると、会社は銀行の利息にもっとお金を払わなければならず、利益を減らすことになります。 逆に、リソース計画が作成されたとしても、マージンがあり、実際にはプロジェクトの月あたりのコストが計画よりも少ない場合、これも悪いことです。 特に、会社がすべて同じ借金で生活し、請求されないお金の費用を支払うことを余儀なくされる場合。
2. プロジェクトチームのオープンポジションをクローズするタイミング。 これは、正しい計画であり、あまり正しくない計画の最も明らかな結果です。 ここではすべてが簡単です-私は事前に現実的なリソースプランを作成しました-リソースマネージャーとHRがプロジェクトの準備を整え、適切なスペシャリストを選択できるようにしました。 しかし、計画が非現実的である場合、絶えず変更が加えられている場合、または一般的にプロジェクトの開始直前に作成されている場合、完全に装備されたチームをタイムリーに獲得する機会はほとんどありません。 プロジェクトが重要かつ優先される場合、そのような計画は会社によって大きな打撃を受ける可能性があります-適切な人材を時間通りに確保できず、未開発のチームから始め、締め切りが迫り、人々が絶えず残業し、すぐにプロジェクトに不要なリスクを負わせます。
3. HRサービスをダウンロードします。 人事は何を機能させますか？ 本当にそうではありません。 人事は何をするべきですか？ 適切な企業では、HRは、リソースマネージャーによる要約リソースプランの分析結果を、特定のスペシャリストにとって満たされていないニーズの形で作業することができます。 もちろん、ディレクターの本能や一部のリソースマネージャーの意見に焦点を当てることはできますが、リソースプランの分析と最適化は最も簡単で最も理解しやすい方法です。 このアプローチにより、HRは作業内容を理解し、すべてのプロジェクトの概要を確認し、リソースマネージャーはプロジェクトのリソースリスクを確認し、HRに時間がない場合に代替オプションを準備する機会があります。 そして、「緊急」、「明日」、「エスカレーション」などの体制で欠員が発生した場合、彼はどのように間に合うでしょうか？ もちろん、ありません。 正確でタイムリーなリソース計画は、全員を救います。
4. AXOをダウンロードします。 新入社員がタイムリーに機器を受け取ることができるように、彼らのために仕事が準備されました。AXO部門は、採用計画を詳細に確認する必要があります。 詳細には、デザイナーと開発者の職場の要件は通常異なるためです。 採用計画は、マスターリソース計画の最初の派生物です。 一般に、この時点で、AXOの代わりに、財務、経理、輸送部門などのサービスユニットを配置することができました。
5. オフィスの大きさと快適さ。 企業の生活が活発になり、積極的に成長または最適化されている場合、リソース計画が特に重要になります。 そして、ここでのリスクは非常に具体的です。 会社は頻繁にオフィスを変更するか、未使用のスペースの過払いを強いられます。
6. リソースの最適化された使用。 単一のプロジェクトのリソース計画を検討するとき、このポイントに戻ります。 しかし、この点について簡単に触れれば、さまざまな方法で同じ結果を得ることができます。 一部の従業員が過負荷になる（ダウンタイムの支払い）、一部の従業員が過負荷になる（2倍のレートで処理するための支払い）などのリソースプランを作成できます。 このような状況を回避するために、リソース計画は、特定のプロジェクトのリーダーのレベルと、プログラムマネージャーとリソースマネージャーのレベルの両方で最適化されます。
7. 会社の全体的なパフォーマンス。 それ自体を示唆する結論は、十分に確立されたリソース計画を備えた企業が効果的な企業である可能性が高いということです。 逆もまた同様です。リソースプランニングが不十分な場合、会社は常に不足を経験し、その後、最初のタイプの会社と比較して、過剰なリソースと工数のコストが発生します。 したがって、それが意味するすべてを備えた会社の発展に向けられる利益の低下。

悪くないでしょ？ リソース計画はIT企業のほぼすべてに影響を与え、それがどのように影響するかがわかります。

次に、逆問題を検討し、リソース計画とその品質が何に依存しているかを把握してください。

リソース計画を決定するものは何ですか？

リソース計画の少なくとも最初のバージョンを作成するために必要なものについて考えてみましょう。 主な導入は、明らかに、作業の複雑さ、タイミング、複雑さ、一貫性、予算、および配信方法の評価（作業分解構造の形で）です。 原則として、リソースプランの修正という形で、他のすべてを考慮することができます。 それでは、これらの各点と他のいくつかの点がリソース計画にどのように影響するかを見てみましょう。

1. メインスコープの初期評価の正確さ。 このトピックについては後で詳しく説明しますが、今考えてみましょう。全体として何がリソースプランを立てているのでしょうか。 おそらく、それが完全に失礼な場合は、「プロジェクトの複雑さを考慮し、プロジェクトの期間をとり、実行者のタイプごとに作業をグループ化し、各タイプの実行者の必要数とプロジェクトでの雇用期間を計算します」 実生活では、すべてがはるかに複雑ですが、変更されないのは、労働計画の質が労働集約度の評価の質に直接依存していることです。 はい、良い評価に基づいて悪いリソース計画を立てることはできますが、入力の複雑さの誤った見積もりを受け取った場合、誰も良いリソース計画を立てることはできません。 原則として、プロジェクトの複雑さを評価する際にエラーが発生すると、重大な処理が行われたり、期限を守れなかったりします。 これはどれも、プロジェクトマネージャーと会社の株主を喜ばせるものではありません。
2. プロジェクトの条件の正確さとリアリズム。 顧客が非常に厳しい期限を設定することはよく起こります。 原則として、安全を確保し、何か問題が発生した場合に備えて時間を確保してください。 一般的な場合、ルールは機能します：「時間の短縮は、追加のパフォーマーによって補うことができます」。 ただし、このルールは非常に狭い範囲の条件で、多くの条件下で機能します。 そしてある瞬間から、誰もが約9人の女性と1ヶ月で赤ちゃんを産む可能性について覚え始めます。 このトピックについては長い間議論することができますが、これまでのところ、プロジェクト時間の短縮（面倒さを考えると）は実行者の数の増加につながるだけでなく、オーバーヘッドコストの増加にもつながると言われています（少なくともチームリーダーの追加と管理システムの複雑化について話している）プロジェクト。 もちろん、これはリソース計画に反映されるべきです。
3. 配信方法。 ここではすべてが簡単です-柔軟な方法論、古典的または反復的なウォーターフォールのいずれに従って作業する場合でも、それぞれの方法論には特定の構造とプロジェクト管理ロジックが必要です。これは、異なる量の管理オーバーヘッド、チーム構造、リソース計画の構成で表されます。
4. 作業の複雑さと接続性。 実際、ほとんどの場合、最初に作業の構造を分析し、プロジェクトコンポーネント間の依存関係を特定しないと、高品質のリソース計画を作成することはできません。 この声明の明確で典型的な例は、既存の情報システムの変換プロジェクトです。 このようなプロジェクトには、ほとんどの場合、レガシーシステムから新しいシステムへのデータ移行などのすばらしいことが含まれています。 特に、データ品質を強化および改善するための多数の中間ステップを含むマルチステージ移行がある場合。 このような美しさの存在は、順序、実装のタイミング、および関連するシステムコンポーネントの実装に厳しい要件を課します。 この場合、特定された相互依存関係を明確に理解した上で、リソース計画をすでに実行する必要があります。
5. 予算。 社内で開発を辞めるか、アウトソーシングするか、結合チームを作ります。 高性能の専門家を購入する余裕がありますか？ 前者は、与えられた量の作業をより速く、より良い品質で行います-したがって、彼らはより少ない時間を費やします。 ただし、計画期間が1つのプロジェクトの時間を超えており、プロの開発者のプールを拡大することがタスクの場合、予算が許せば、初心者と上級開発者をペアにすることは非常に理にかなっています。 はい。特定のプロジェクトのコストを増やすことで、実際のプロジェクトで必要な経験を積むことができます。 ただし、多くの場合、これは初心者の専門家から真の専門家を育てる唯一の方法です。 いずれにせよ、予算のサイズは、チームおよびリソース計画を選択する際の決定要因の1つです。
6. 保証契約の存在。 多くの人がこの作業段階を忘れています。 多くの場合、リソース計画は、システムを運用する段階で終了します。 そして、保証期間内にさらに1年間サービスを受ける必要があるという事実-これはリソース計画にもプロジェクト経済の計算にもありません。 実際、このアプローチは、テクニカルサポートの別の契約が必要な場合にのみ有効です。 それ以外の場合、保証サポートに提供されるリソースの不足は、リソースマネージャーの生活を複雑にし、財務予測を不正確にし、プロジェクトの経済的パラメーターをゆがめる間違いになります。
7. チームメンバーの普遍性。 非常に重要な側面。 プロジェクトに普遍的な戦闘機が装備されていると想像して想像すると、それぞれが新しいコンポーネントのアーキテクチャを設計し、開発の複雑さを評価し、フロントレベルとアプリケーションおよびデータベースサーバーのレベルで開発を行い、テストケースとテストを記述し、リリースを作成し、リリースノートを作成します。これらすべてを高品質で高速に実行すると、夢のチームになります。 そして、そのようなチームのリソース計画は非常に単純に見えます。時間をかけて、すべてのチームメンバーに均等に配分します。 実際には、プロジェクトチームメンバーの特定のスキルセットがリソース計画に課す制限を考慮する必要があります。
8. 品質および変更管理アプローチ。 これは別の非常に大きなトピックです。 さて、あなたが変化を歓迎することが知られている柔軟な方法論の1つのフレームワークに住んでいるなら。 しかし、ウォーターフォールに住んでいるか、エッジに住んでいるふりをする場合、変更管理はプロジェクトマネージャーの重要なスキルの1つです。 または、プログラムまたは大きなプロジェクトについて話している場合はチェンジャーマネージャー。 リソース計画の段階では、事前にリソースを予約する変更量、予約するリソース、これらのリソースが関与する期間などを理解することが非常に重要です。
9. チームの分布。 原則として、同じ場所（または同じ部屋）にいるチームのパフォーマンスは、同じチームのパフォーマンスを大幅に上回りますが、そのメンバーは複数の場所に分散しています。 人々は同じであり、給料にほぼ同額を費やしているようですが、チームの生産性ははるかに低くなっています。 リソース計画では、どのチームがプロジェクトを作成するか、どのように分散されるか、プロジェクトの重要な瞬間にプロジェクトを1か所にまとめることができるかどうかを理解することが非常に重要です。
10. リソースを共有する機能。 孤立したプロジェクトについてではなく、たとえば、近隣のプロジェクトの同僚とリソースを手探りできるプログラムの場合、リソース計画の条件ははるかに快適になります-½、⅓、¼FTE（正社員）を計画する機会があります。残りの時間は他のプロジェクトに関与するため（実際、これはリソースマネージャーの個別のタスクですが、かなり解決可能です）。 孤立したプロジェクトにはそのような贅沢はありません。開発者やテスターを雇うことはできません。 しかし、多くの場合、この状況はプロジェクトマネージャーと共に発生します。 プロジェクトの過程で負荷が不均等になると、経営資源が最適に使用されなくなります。
11. 休日。 リソース計画の最初のバージョンでは、人員の必要性の大まかな評価がある場合、休日を気にしないことはまったく許容できます。 しかし、毎日のプロジェクト管理のツールとしてのリソース計画に関しては、非稼働日を考慮しないことはすでに非常に危険になります。 1年に52週間があり、各チームメンバーが少なくとも2週間は休暇に費やします。 わずか10人のチームについて話している場合、これは、すぐに約2 x 5 x 10 = 100人日分の赤字になることを意味します。 これは、例えば残業によってカバーされます。
12. 休日。 年末年始の1週間半、5月の祝日、2月23日、3月8日、およびそれらのような他の人は、年間52週間からさらに2〜3週間かかります。 そして、さまざまな国の人々が働く分散チームについて話すと、すべてがさらに簡単になります。 各国には独自の祝日があり、プロジェクトマネージャーは、祝日を考慮した正確なリソース計画を作成するために、チームメンバーが働いている国の文化を少なくとも少し勉強する必要があります。 そうでない場合は、前の段落に戻って、意図的に設けられた労働時間の不足とプロジェクトの困難を倍増させることができます。

もちろん、このリストはさらに拡張できますが、主なトピックを強調しました。 リソース計画の品質はIT企業のほぼすべてに影響し、リソース計画自体の品質は、特定のスキルが必要とされる正しい会計処理のために、かなりの数の要因によって影響を受けることがわかります。

次の部分では、より実用的なものに進み、独立したプロジェクトの一部としてリソース計画のトピックを検討します。