Iteration 0

クイックリンク: | Iteration 0 の基本 | Delivery Kits

フェーズ概要

Iteration 0 は、互いに積み重なる 4 つの主要な活動で構成されます。

1. EM>PS Transition - 内部の知識移管
2. Stakeholder Planning Meeting - 顧客との初期整合
3. Customer Kickoff - チーム全体のエンゲージメント
4. Support Preparation - 先回りした Issue 管理

各活動には、プロジェクトの円滑なスタートを確保するための具体的なインプット、プロセス、アウトプットがあります。

EM>PS Transition

目的: アカウントの背景を集め、SOW を検証し、顧客対応活動の準備を行う。

事前ミーティング準備

移管ミーティングの前に:

1. ドキュメントのレビュー

   • Statement of Work (SOW)
   • Kantata プロジェクト詳細
   • Customer Epic に紐づく Scoping Issue
   • Consulting Block SKU の場合: DoW をレビュー（Customer Epic に添付されているはずです）

2. ミーティングのスケジュール設定

   • 含めるメンバー: Engagement Manager、Technical Architect、Professional Services Engineer、Account Manager、Customer Success Manager（アサインされている場合）
   • アジェンダの準備には Schedule Intake issue または このテンプレート を使用

3. 前提データの収集

   • 関連情報については Delivery Kits を参照
   • Iteration 0 の基本 をレビュー
   • discovery のベストプラクティス を考慮
   • 複雑なプログラムの場合は RACI テンプレート を準備

ミーティングの実施

議論は次に焦点を当てます。

• ビジネスドライバーと文脈
• SOW の検証と明確化
• 技術要件の概要
• Stakeholder Planning と Kickoff のスケジュール計画
• リスクと依存関係

主要なアウトプット

ミーティング後、以下の完了を確認します。

• 内部チームが最新ステータスをどこで確認できるかを理解している
• Collaboration Project のセットアップを開始し、Slack チャンネルにピン留め、内部レトロスペクティブ Issue（Customer Epic に添付）も同様
• 顧客との Stakeholder Planning ミーティングがスケジュールされている
• 顧客との議論のための技術的前提条件が特定されている
• 初期リスクがドキュメント化されている

💡 ヒント: Discovery では大きく考え、チームの整合性とチームの準備状況を考慮してください。目標は、顧客が十分に準備された状態で自信を持って Planning and Design セッションに入ることです。

Stakeholder Planning Meeting

目的: プロジェクトのスコープ、リソース、管理アプローチ、依存関係を整合させ、チーム全体のキックオフ前に期待のずれを明らかにする。

ミーティングのセットアップ

1. 顧客 PM および GitLab と顧客チーム双方の主要ステークホルダーとの専用ミーティングをスケジュールします。
2. Stakeholder Planning Template を使って議論をガイドします
3. プロジェクトパラメータの相互理解に焦点を当てます

主な議論トピック

1. プロジェクトステークホルダー

   • すべての主要参加者とその役割を特定
   • 対応可否とコミュニケーションチャネルを確認

2. プロジェクト目的

   • ビジネスドライバーと成功基準を検証
   • ユースケースと期待される成果を整合

3. プロジェクトのベロシティとタイムライン

   • ペースとマイルストーン日程の期待値を設定
   • スプリント／イテレーションのケイデンスの好みを議論

4. プロジェクト前提条件

   • 技術的・組織的準備状況をレビュー
   • 作業開始のブロッカーを特定

5. キックオフ準備

   • 全体キックオフのアジェンダと参加者を決定
   • キックオフミーティングへの期待値を設定

6. オンボーディング検証

   • すべてのアクセスと権限が整っていることを確認
   • 環境とツールの可用性を検証

7. 次のステップ

   • オーナーと期日を伴うアクションアイテムをドキュメント化
   • Customer Kickoff と Discovery セッションの計画

主要なアウトプット

• 検証されたステークホルダーリストと役割
• タイムラインとベロシティに関する期待の整合
• ドキュメント化された前提条件と依存関係
• Customer Kickoff のアジェンダ準備
• 明確なオーナーシップを伴うアクションアイテム
• Customer Slack チャンネルを作成し、Customer Project チームメンバーを招待。AR は テンプレート として使用できます

💡 ヒント: このミーティングを使って、より広範なキックオフミーティングの前に、GitLab と顧客チーム間の期待のずれを特定し対処してください。

Customer Kickoff

目的: すべての関連プロジェクトステークホルダーを集め、プロジェクトの目的、アプローチ、次のステップを整合させ、迅速な実行を可能にする。

準備

1. EM>PS Transition と Stakeholder Planning から得たインサイトを統合
2. Kickoff デッキテンプレート を使ってプレゼンテーションを準備
3. ステアリングコミッティのあるプロジェクトには、SteerCO テンプレート も準備
4. すべての主要ステークホルダーが招待されていることを確認

ミーティングコンテンツ

以下の包括的な概要を提示します。

• プロジェクト目的と成功基準
• チーム構造と役割
• プロジェクトアプローチと方法論
• タイムラインとマイルストーン計画
• コミュニケーションとレポーティングのケイデンス
• 次のステップと即時のアクション

主要なアウトプット

• プロジェクト目的とアプローチに対する理解の確認
• Discovery & Planning セッションのスケジュール
• Iteration Cadences の確認
• 明確なオーナーシップを伴うアクションアイテムのドキュメント化

Issue 対応のサポート準備

目的: Support チームに主要なプロジェクト情報を提供し、エンゲージメント中の Issue 解決を効率化する。

このプロセスは実装などのインフラ関連プロジェクトでは特に重要ですが、サポート Issue が発生する可能性のあるあらゆるエンゲージメントでも価値があります。

ZenDesk アクセス

ZenDesk light（読み取り専用）アクセスを持っていない場合:

• Zendesk Global の場合
  • Zendesk ‘Light Agent’ アカウントのリクエスト を参照
• Zendesk US Government の場合
  1. Access Request を起票
  2. System name の値が Zendesk - US Federal, light agent access であることを確認
  3. マネージャーにアサイン
  4. マネージャーが承認したら（AR の指示に従って）、Zendesk - US Federal の tech_stack オーナー に通知
     • このアクセスを得るには米国市民権が必要であることに留意してください

サポートノートの作成

Step 1: 顧客組織を見つける

1. Organizations Repository にアクセス
2. 顧客名を検索（ハッシュに続いて Salesforce 名が表示されます）

Step 2: YAML ファイルを編集

1. 検索から YAML を選択し、Edit > Open in Web IDE をクリック

2. notes セクションの後（パイプ | で始まる）に情報を追加:

---
id: 27946339528
name: 5a1f9965 Test Account
notes: |
   PS Project in Progress
   Project Manager:
   Slack Channels:
   Engineers:
   Start Date:
   Anticipated End Date:
   Summary of Engagement:
   Support should know:
   Collaboration Project RAID(Issue) Board Link:

ページのソースコードを見る - ページの編集 - please contribute.