プロダクトマネージャー向けのヒント：プロダクトバックログとプロダクトビジョンをリンクする

製品ベースのアジャイル開発チームにとっての絶え間ない課題の1つは、彼らが「今」行っていることを、製品がたとえば2〜3年後に形作ることになっていることにマッピングすることです。

チームが何に取り組んでいるのかわからないということではなく、日々のタスクに集中しすぎて、全体像における「現在の」作業の影響の感度を常に損なう可能性があるという事実についてです。 今日の実行中に行われた決定または選択は、特に製品が進化しているときに、将来大きな影響を与える可能性があります。

実際の例を見てみましょう。

私は、サイトコンテンツのテキスト翻訳サービスを導入しようとしていたアジャイルチームの一員でした。 決定が下され、サードパーティの機械翻訳ツールが使用されました。 ただし、製品ロードマップでは、将来的には、ユーザーが独自のコンテキスト翻訳を修正して提供できるようになる必要があると述べています。つまり、翻訳機能には、フィードバックに基づいて独自に学習できるように、人工知能が必要です。
この開発を考えると、行われた選択は適切ではなく、したがって、全体像がスプリントでアジャイルチームが課されたものにリンクされていなかったため、かなりの程度のやり直しが必要でした。

チームはこの情報を取得するために意識的な努力をすることができると主張することができますが、要点は、なぜこれらの「長期」目標を既存のアジャイルツールとダッシュボードに取り込むことができないのかということです。

アジャイルチームは、開発サイクルで明確に定義された特定のタスクを実行しますが、それは、製品の進化に無関心であるという犠牲を払って行わなければならないことを意味しますか？ いいえ、そうは思いません。

私の知る限り、アジャイルチームの日常業務において、この情報を提唱または推奨する迅速なツールやフレームワークはありませんが、そのようなビューを既存のビューで作成することはできますか？ 試すだけの価値があります？ どうすればそれができるか見てみましょう。

アジャイルで最も一般的なアーティファクトである製品バックログから始めます。
SCRUM Instituteによると、製品バックログはプロジェクトで実行する必要があることのリストです。 これらには、拡張機能やバグが含まれる場合があります。 チームがアイテムの優先順位構造を知らない限り、番号付きリストは役に立ちません。 ここで、利害関係者と協力して明確な要件を取得し、相互依存関係を解決し、製品バックログアイテムの優先リストを取得する全体的な責任を持つプロダクトオーナーが参加します。

このプロセス中に、より大きく依存する作業項目がさらに小さな部分に分割され、チームの開発が容易になる可能性があります。 これらの製品バックログアイテムは、より小さなチャンクに分割され、2〜4週間のスプリントサイクルで実行され、製品開発の「方法」コンポーネントに答えます。

一方、製品のバックログアイテムは、製品ビジョンと呼ばれることが多い製品の「真北」にもマッピングされます。 これは、複数のバージョンのリリースを通じて達成されることが多い製品の望ましい状態であり、ターゲットオーディエンスまたは顧客が望むものとそれがもたらす価値に密接に関連しています。

アジャイルチームを顧客にリンクするこの一連の要素（製品のバックログとビジョンを含む）は、次のように表すことができます。

アジャイルチームと顧客が必要とするものとの間の遠いリンク…

スプリントと製品のビジョンを明確に結び付けるビューがないため、製品の所有者は、「どのように」の部分に集中しすぎて、「何」のより大きく重要な目標を見失うリスクに直面することがよくあります。誤った優先順位付けに。

ここで説明するアプローチは、両方のコンポーネントをリンクするシンプルで強力なビューを作成することです。 これは、 Product Vision Matrix（PVM）として知られています。 目的は、製品のビジョンをきめ細かい開発項目にリンクすることです。 このマトリックスは、製品開発に関するチームの進捗状況を分析する際の重要な要素になります。 また、組織の上級管理職向けの製品ダッシュボードとしても機能し、製品目標の達成可能性について投稿し続けます。

名前が示すように、PVMは、列がキャプチャされているディメンション（マイクロからマクロまで）を表すマトリックスです。 ビジョンがユーザーに食品体験を提供することであり、出発点が食品注文である食品注文アプリの助けを借りて、PVMを理解しましょう。 サンプルマトリックスは次のようになります。

Product Vision Matrixには、次のフィールドを含めることができます。

• 製品バージョン：これは、公式リリースのマイルストーンであり、多くの場合、顧客が受け取る製品バージョンです。
• ビッグロックアイテム：これは、機能も属するカテゴリまたはテーマです。 これらのアイテムは、製品ビジョンの長期的な製品ニーズ領域にもなり得ます。
• 機能：これは、開発中の製品機能です。 この機能は、1つまたは複数のテーマ（大きな岩のアイテム）に属することができます。
• スプリントID：これは機能が開発されているスプリント番号です。
• 開発ステータス：このフィールドは、開発の進行状況（計画済み、設計完了、開発完了、テスト済み、およびリリース済み）を示します。

ここでは、マトリックスの構造が示されていることに注意してください。 製品のビジョンを捉えることができる列を特定することで、より創造的になることができます。

このアプローチの利点は、各チームメンバーが製品全体の目標を明確に把握できることです。 進化する製品の場合、チームメンバーは全体像をよりよく理解する必要があります。 これにより、彼らは効果的に貢献できるだけでなく、より多くの説明責任を果たすことができます。 その結果、より集中的で適応力のあるチームが常に顧客の動向を把握し、スプリントが製品のビジョンと最終的な成功に貢献する上でもたらす違いを認識します。

世界のトップ大学からオンラインで製品管理コースを学びましょう。 マスター、エグゼクティブPGP、または高度な証明書プログラムを取得して、キャリアを迅速に追跡します。

あなたのための注目のプログラム：デュークCEからのデザイン思考認定プログラム