つまり、最初はアイデア（サイト、ソフトウェア、サービスの提供）があり、次に具体的なマテリアルの実装がありました。
実装は、明らかに、一部のリソースを他のプロダクションと同様に他のリソースに変換するチェーンです。 この投稿は、ITプロジェクトの検討に専念します。実動としてではなく、一連の変革として確実に検討します。
以下、リソースとは、プロジェクトの結果を達成するためにその存在が必要なオブジェクトを意味します。 プロジェクトの中間成果物を含めることは、そのためのリソースになります。
一般的なITプロジェクトリソース
リソースの原因は何ですか？ 明らかな「お金」と「時間」に加えて、それらの派生物も起因する可能性があります。
- ツールキット（平凡な職場から始まり、スタンドと開発ツールで終わる）-お金が必要
- スタッフとその特定の知識にはお金が必要です（彼はそうです:)）、そして知識の場合は、おそらく時間です
- 顧客基盤と顧客ロイヤルティ-時間とお金の両方が必要
- プロジェクトで作成されたアーティファクト「半製品」には、お金と時間の両方が必要です。
後者は、たとえば、次のとおりです。
- プログラムコード
- ドキュメント（TK、ユーザー、その他）
- 展開されたソリューション
- データベース内の情報、顧客情報
- デバイスの製造について話している場合、組み立てられたプロトタイプと直接製造用の材料（完成したコンポーネント）
例または理論のいずれかで概念に深く入り込むことは意味がありません。 目標を達成するために必要な有形または無形のオブジェクト（またはアニメート）がリソースの概念で示されることは明らかです。 実際、他のシステムと同様に、リソース自体は相互接続ほど重要ではありません。
ゲームビルディングの例を挙げましょう。完成した結果を得るには、常にアートとコードの両方が必要です。 アートなしでコードを書くことはできますが、テストすることはできません。 コードなしでアートを描くことはできますが、コードなしでアートの全体的な結果（ビジョンとインタラクション）をライブで見ることは事実上不可能です。 どうする ほとんどの場合、彼らは完成したものの基本的な特性を繰り返すアートのスタブを使用してコードを記述し、一般的な視覚アートはアート開発ツールのレンダリングによって相互作用なしでホイップアップされます。 最終的に、すべて
プロジェクト管理方法論とリソース変換のチェーンとの関係
反復（タイムボックスを使用して、さらに総称してアジャイルと呼びます）およびカスケードアプローチは、主に時間で管理する方法がリソースの変換の観点とは異なります。 ある場合には、それは等しい部分に「カット」され、カスケードされたものではそうではありません。 反復はあちこちに存在する可能性があります。全体の問題は、プロジェクトがどのような中間結果を作成するかです：柔軟なアプローチの場合、各反復で最終的な不完全な製品があり、カスケードの場合、個別の関数/モジュールがあります。 同時に、特にタイムボックスが短いほど、結果の数は明らかに異なります。
上記のすべては非常に明白ですが、次の点に注意することができます。リソースの消費は異なります。 上記の本では、リソースは2つのタイプに分けられます。
- 再現不可能、備蓄、蓄積-「エネルギー」（ITプロジェクトの資金）、
- 再現可能で、在庫がなく、蓄積されないリソース-「能力」（ITプロジェクトの人々）。
カスケードアプローチでは必要に応じて「電力」と「エネルギー」の両方を使用しますが、柔軟なアプローチでは「電力」を最大限に使用し、適切に「エネルギー」を投与します。 2番目のケースで総消費量が増えないことを保証するには、反復（同じリソース）によって生成される中間結果がプロジェクト中に一定の変更を必要としないことが必要です。 したがって、柔軟なアプローチを使用するという単なる事実は、アーキテクチャの開発と機能実装のシーケンスを放棄することを正当化するものではありません。
変換チェーンの例
いくつかのオプションを検討してください-B2BとB2C。 B2Bでは、単純なドキュメントベースのERPのような開発プロジェクトを検討し、B2Cでは、訪問者が互いにサービスを注文および購入するサイトエクスチェンジを検討します。
図の矢印は順序を反映しています。
B2B「ERP」アジャイル
B2C Exchange Cascade
一見したところ「すべてがすべてに関連している」という事実のために図がよく読めない場合、それらはいくつかに分けることができます。 しかし、すべて同じように、それはすべてと結びついており、避けられません。 プロジェクトは、下から上に建てる高層ビルの建設中に、以前の結果が後続のもので使用されるようなものです（建設の場合-重力の問題のため、プロジェクトの場合-避けられない因果関係のため）。 「時間」などのリソースは、すべてが矢印で散らばらないように、まったく与えられていません。
はい。 （突然）柔軟なアプローチが「スリマー」であると思われる場合、そのダイアグラムの原始性は、2番目にあるリソースの欠如を隠します。
結論の代わりに-リソースチェーンのプリズムによるプロジェクトのリスク管理
「リスクのない計画は一連の願いであり、計画のないリスクはカジノです。」 （（c）鉱山）。
リスクとは、プロジェクトの指標を適切な指標からそらすイベントです。 このリスクは、プロジェクトの最終結果に影響します（予定どおりではなかったか、品質が低いか、予算から外れました）。 今慎重に手を従ってください:)
ステートメント。 リソースの作成と適用のシーケンス、およびリソースチェーン内のリソース自体の有無によって、プロジェクトのリスクのレベルが決まります。
証明。 任意の指標を考えてみましょう。そのリスクは、計画された指標から値が逸脱する可能性です。 ある時点でのインディケーターの値は、プロジェクトの最後で、この時点までに含まれるリソース（すべてのリソース）の関数です。 このことから、リソースの構成とその順序の変更により、インジケーターの値が変更（グラフ）されることになります。 これは、リスクのないプロジェクトが存在しないことも意味します（実際、リソースは計画されたプロジェクトに対応しないため）。 リソースの「コンテンツ」をリスクジェネレーターと呼ぶことはできません。「コンテンツ」を変更するとリソースが変更されるためです（たとえば、データベースはMS SQL Serverではありませんが、Firebirdは2つの異なるリソースです）。 [証拠の終わり]
上記のすべてが何らかの理論のように思える場合、この理論が大小両方に現れるという事実を考えてください。 2つのオプションのうち、どのタスクを最初にバックログから取得するかを決定する場合でも、中間の「排出」リソース（スタブなど）の作成が少なくて済むオプションが最適です。 どちらが良いかを決定しようとしている場合-地理的分離または機能に基づいて異なるオフィスに数百のジョブの導入を整理する-リソースチェーンのどのオプションが希望する少数からインジケータを逸脱するかを見てください（選択はプロジェクト三角形の3つのインジケータの選択されたペアに依存します） 。
読んでくれてありがとう。 すべての成功したプロジェクト！