Hewlett Packard Enterpriseのコンサルタントは、ITSM、プロジェクトおよびポートフォリオ管理、あらゆるレベルでの監視など、IT管理の分野で同様のプロジェクトを実施します。
世界中の過去数年間で、このようなプロジェクトの実施にアジャイルアプローチを適用することを顧客がますます求めているか、積極的に主張しているという事実に直面しています。 そのような先例はすでにロシアに現れています。
長年にわたって、IT管理の分野でのコンサルティングプロジェクトの実施に対するアプローチが、「ファイブプラス」のためにHPEで策定されてきたことは明らかです。 世界中で何千ものプロジェクトが完了し、膨大な数の教訓と、方法を示す厳密な方法論があります。 そしてもちろん、これはすべてウォーターフォール形式です。 つまり、「プロジェクトの開始」、「設計」、「作成」、「展開と試用」です。 「彼は来た、見た、勝った」
なぜ
ここではすべてがシンプルです-顧客はできるだけ早く結果を必要とします。 自分で判断してください。 中規模または大規模のほぼすべてのロシアの会社を取ります：
1.予算計画は8月のどこかから始まります。
- イニシアチブを策定します
- 経済効率のふるいを通して評価され、「スクリーニング」されます。
- プロジェクトに変わる
- 誰かが詳細な要件を書いて
- 対応する行がIT予算に表示されます。
2.年の初めに、予算を取って入札をします。手順は楽しく、十分に速くありません。
3. 3月に運が良ければ、仕事を始めます。
4.すべてのKPI（顧客側と請負業者側の両方）のため、結果は何らかの形で年末に発行されなければなりません。
合計：イニシアチブからプロジェクト結果までのプロジェクトのライフサイクル-約1年半。 これは非常に長い時間です。
何が悪いの
この状況にはいくつかの理由がありますが、少なくとも：
- 「勝つ」（時間を短縮する）ための予算と入札手続きは困難です。 イニシアチブの開始から入札の結果まで4〜6か月後、同じトピック内であるにもかかわらず、顧客の要件が変更される場合があります。 タスクの柔軟な再優先順位付けのためのツールが必要です。
- プロジェクトの枠組みの中で、顧客はもちろん、ウォーターフォールの作業にも慣れています。 そして、すべての内部規制、プロジェクト管理の基準などに書かれています。しかし、6、9、または12ヶ月の結果を待つのは非常に退屈です。 繰り返しますが、この期間中、プロジェクトの実装中に多くのことが変更される可能性があります。 はい、変更されていない場合は、結果を部品で取得し、すぐに作業に使用します。
どうする
顧客は、特定の問題を解決するためにお金を割り当てることは前世紀であることを理解する必要があります。 タスクの設定は、すでにわかっているように、これらのタスクの実装中に頻繁に変更されます。 したがって、特定の主な方向性の開発（ITSM、ポートフォリオおよびプロジェクト管理、インフラストラクチャまたはサービスの監視などのための当社のコンサルティングプロジェクトの場合）、特定の開発ベクトルの設定に資金を割り当てる必要がありますが、具体的ではありません要件と結果。 もちろん、これには考え方の変更、内部手順の再構築が必要になりますが、それなしではどこにもありません。
さらに、組織の変化、つまり人々の働き方の変化をスムーズに通過させることが必要です。 多くの組織では、人々が急速かつ多数の変化に慣れているという事実に直面しています。これは通常、組織内の1つまたは別のレベルでの「手動制御」の結果です。 組織の変更管理（MoC、（組織）変更の管理）のベストプラクティスを使用する必要があります。これらの変更は混notではないが、以前に設定された同じ開発ベクトルを提供することを人々に示します。
最後に、コンサルティングプロジェクトについて具体的に話している場合、HPEではいわゆる「サンドイッチモデル」を使用します。
- プロジェクトの開始時に、実装する必要があるタスクの初期バックログが形成されます。 ウォーターフォールアプローチの一部としてシステムのプロセスと機能要件を設計する方法と同様に、これを「マイクロプロジェクション」と考えることができます。
- たとえば、ScrumXPが示すように、このバックログは優先されます。 さらにアジャイルモードで作業し、要件を修正および変更できます。 もちろん、厳格な規律、適切な役割（製品所有者、スクラムマスターなど）の存在が必要です。 コードの開発と並行して、必要なドキュメントを作成し、組織の変更を準備します（DevOpsのフレームワーク内には、プロセスコンサルタントの意識を非常によく変える「すべてがコード」というマントラがあります）。
- 「顧客-請負業者」の組み合わせで作業する場合、プロジェクトの概念を取り除くことはできません。 定義上、プロジェクトは時間制限のあるアクティビティです。 したがって、ある時点で、アジャイルのストーリーを要約し、プロジェクトの結果を顧客に提供する必要があります（必要に応じて追加の官僚機構を提供します）。 ちなみに、これは作業が完了したことを意味するものではありません。顧客は「サンドイッチ」（項目2）の途中で、より多くの意欲で定期的に新しいリリースと新しい価値を受け取り、事前に作業を継続する準備ができているという事実に慣れています新しい資金の配分について。
ご覧のとおり、両側にアジャイルをウォーターフォールでラップします。これにより、一方で、ウォーターフォールアプローチに近いプロジェクトの開始および終了により、リリースを行い、顧客により多くの価値を与えることができます。それには始まりと終わりがあります。 これは、顧客が時間と材料のスキームではなく、固定価格のスキームに従ってアジャイルプロジェクトを実装することを非常に頻繁に望むためです。
このトピックは私たちにとって非常に有望であるように思われ、すでにこの形式の多くのプロジェクトがすでに進行中です。 たとえば、世界中で運営されている会社に大規模なプロジェクトがあり、製品の所有者がリリースの間に世界中からシステムの最大200人の主要ユーザーを収集し、作業の結果を表示し、それらからフィードバックを収集し、彼らの助けを借りて新しいアイテムをバックログに追加します。 これはほんの小さなタッチであり、そのようなプロジェクトの可能な規模を示しています。伝統的にアジャイルは小さなチームでよく生きているからです。 ただし、エンタープライズレベルについて話をすると、SAFeが助けになります。これについては、既に説明しました。
要約すると、アジャイルまたは「ほぼアジャイル」の形式のコンサルティングプロジェクトが可能です。 私たちもそれらを作ります。 国内の企業や組織の詳細を考慮に入れるなど、このトピックに関する質問やコメントをお聞かせください。