リソース計画
必要なプロジェクトリソースの特定
Microjourney™をMinimum Lovable Product(MLP)として識別し、優先順位を付け、サイジングを行ったら、次は必要なリソースを判断します。
プロジェクトの複雑さに基づいて、次の事項を考慮します。
- 問題なくデリバリーするために必要な役割と、その役割がプロジェクト期間中のどの時期に必要になるか
- 共同制作をサポートする上で必要なコーチングとメンタリングのレベル
- プロジェクトに必要な経験のレベル
- プロジェクトには、どのPega Platform™ 製品スキルが必要か(例:Pega Customer Service™)
- オンサイトチームとバーチャルハイブリッドチームが適切かどうか
- デザインスプリントが必要かどうか、また、デザインスプリントの促進にどのような調査とリソースが必要か
- どのようなユーザーインターフェイス(UI/UX)の作成が必要か
- チームメンバーの就労ビザ要件など、現地の事情に即した考慮事項
プロジェクトでの役割
リーダーシップ、ビジネス、技術的な役割全体で、Pegaプロジェクトをサポートするリソースを利用できます。 次の表に、担当できる各種の役割を記載します。
ロール | 説明 |
---|---|
プロジェクトリード | プロジェクトリードはプロジェクトの実施を管理します。ガバナンスとプロジェクト全体の成功に責任を負います。 |
ビジネスアーキテクト(BA) | ビジネスアーキテクトは、要件を把握し、優先順位を設定してビジネスのコラボレーションを確保します。 |
システムアーキテクト(SA) | システムアーキテクトは、ワークフローの作成と変更、デシジョンテーブルとデシジョンツリーの作成、ハーネスセクションの構成、テストケースの設計を行います。 |
エクスペリエンス(UI/UX)デザイナー | エクスペリエンスデザイナーは、ユーザーインターフェイス(UI)とユーザーエクスペリエンス(UX)の専門知識をプロジェクトに提供します。 |
ビジネスに関する役割と技術的な役割については、経験と取得認定に基づいて、さまざまなレベルがあります。 システムアーキテクトの役割を例に取ると、役割のレベルは次のようになります。
SAレベル |
---|
システムアーキテクト (SA) |
シニアシステムアーキテクト |
リードシステムアーキテクト |
ビジネスチームのプロジェクトでの役割
ビジネスチームが通常担当する役割には、プロダクトオーナー、スクラムマスター、テストリード/テスターなどが挙げられます。
製品オーナー
- 企業を代表し、ビジネスの意思決定のための唯一の連絡窓口となる
- 目的の直接把握(DCO)セッションに参加
- 製品のバックログを責任を持って管理
- 利害関係者の期待を設定
- スクラムチームの作業に優先順位を設定
- スクラムチームの質問に答え、詳細を明確に説明
- ユーザーストーリーの完了を承認または却下する
スクラムマスター
- 毎日のスタンドアップミーティングを実行
- プロジェクトチームに常勤で専属
- スクラムについて説明し、スクラムのベストプラクティスについてチームをコーチング
- 必要に応じてミーティングやイベントの進行役を担当
- チームの障害や障壁を取り除く
- プロダクトオーナーと開発チームとの協力を奨励
- しっかりとしたエンジニアリングの実践と作業への取り組みを奨励
テストリード/テスター
- 企業のエンドツーエンドのテスト計画の責任者
- テスト環境とデプロイメントを整備
- テストケースの作成と実行を管理
- 欠陥の解決と再テストを追跡
共同制作
共同制作とは、クライアントがPega製品とPegaのベストプラクティスを十分に理解するための内部リソースを特定することです。 このプロセスを通じて、クライアントチームのメンバーはプロジェクトデリバリーに参加して貢献できるようになります。
共同制作リソースは、アプリケーションの構築方法を学習し、クライアントの社内に伝えられるようその知識を維持します。 また、リソースはプロジェクトチームが直接ビジネスに関する理解を深められるようにし、ソリューションの開発が進むに従ってそのソリューションに影響を与えます。 共同制作リソースは、プロジェクトの終了後はそれぞれ自立しますが、Pegaが認定すると、アプリケーションの開発を継続し、繰り返しさらなるビジネス成果を達成することもできます。
発見フェーズ中に共同制作を可能にすると、MLPが適切な成果を確実に実現できるようになります。
共同制作を検討する場合にすべき作業は次のとおりです。
- 初期のMLPをサポートする上で必要な共同制作リソースのレベルを決定する
- クライアントと協力して、役割を果たすことができる社内の人材を特定する
- リソースにPegaアプリケーションの認定トレーニングをプロジェクトの開始前に必ず受講してもらう
- 共同制作計画を作成して、認定からプロジェクト作業に実際に携わるまでのパスをマッピングする
- こうした人材にソフトウェアに十分慣れてもらうために、さらにトレーニングや演習セッションを計画に追加する必要が生じる場合もあります
- ランチミーティングを何度か開催して、他のPega認定エキスパートと特定のトピックを説明することもできます
- 共同制作リソースの生産性をリソース計画に織り込む - リソースの習熟度と生産性は時間の経過とともに向上します
- プロジェクトデリバリーチームが共同制作者にメンタリングとコーチングを行うために、どの程度時間をかるか検討する
- その他の考慮事項を評価する(例:プロジェクトを対面で実行するか、バーチャルに管理するか)
次の図は、共同制作パスの内容の一例です。
12か月にわたる共同制作の実現パスは、次のようになります。
0~3か月
- Pegaのメンターの所要時間:20%
- 共同制作者の生産性:40%
- 共同制作者のコミットメント
- 100%専属
- プロジェクトのキックオフ前にPegaのトレーニングを受講しておく
- 1か月以内にCSA認定を取得する
- ガバナンスの実行者:共同制作リードが計画を維持する
- ガバナンスのレビュー:毎週
4~6か月
- Pegaのメンターの所要時間:10%
- 共同制作者の生産性:60%
- 共同制作者のコミットメント
- 100%専属
- 最初の6か月でCSSAコースの教材を作成する
- ガバナンスの実行者:共同制作リードが計画を維持する
- ガバナンスのレビュー:隔週
7~9か月
- Pegaのメンターの所要時間:0%
- 共同制作者の生産性:80%
- 共同制作者のコミットメント
- 100%専属
- CSSA認定を取得する(その後100%生産性が高まる)
- ガバナンスの実行者:該当なし
- ガバナンスのレビュー:隔週
10~12か月
- Pegaのメンターの所要時間:0%
- 共同制作者の生産性:100%
- 共同制作者のコミットメント
- メンターの役割を担う場合もある
- ガバナンスの実行者:該当なし
- ガバナンスのレビュー:毎月
次の図は、カスタマーサービスの共同制作実現計画の一例です。
共同制作の実現計画は、以下の内容を追跡する詳細な計画で構成する必要があります。
- プロジェクト全体を通じて、知識を身につけ認定取得の準備を整えることを目的とした、チームメンバーとメンターが主導する定期的なセッションがスケジュールされていること。 ランチミーティングや、製品機能またはベストプラクティスの概要説明などになる場合もあります。
- 各スプリントに合わせて、共同制作者の能力と貢献者を徐々に育成する活動と開発作業を行う必要があります。 たとえば、初回のスプリントではツールの概要を説明し、その後のスプリントではSLAの構成方法を詳しく説明するといった形です。
次の問題に答えて、理解度をチェックしましょう。
このトピックは、下記のモジュールにも含まれています。
- 発見フェーズとMLP v1