昨年のシステムおよびビジネス分析のスペシャリスト会議-レポートのDmitry Petrashev（Dellのサンクトペテルブルクオフィスのシニアアナリスト）
レポートページでは、プレゼンテーションとビデオを見つけることができますが、ここではテキスト...
はじめに
すべての良い一日。 私の名前はDmitry Petrashevです。 私はデルのサンクトペテルブルク事務所のシニアアナリストです。 今日は、 インパクトマッピングなどの戦略的計画へのアプローチについてお話したいと思います。
- 私はそれが何であるかを教えます、
- なぜ彼らに興味を持ち、私たちの会社に紹介することにしたのか、
- 実装の経験とその結果を共有します。
私たちはすぐに食料品会社を持っていると発言しますが、私の話ではおそらく多くの特異性があるでしょう。 しかし、アプローチ自体は、カスタム開発と特定のシナリオの両方に適用できるほど普遍的であることを説明する価値があります。
それで、なぜ私たちの場合、開発チームはここで必要なことや影響のマッピングを常に行うとは限らないと思います。
ビジネスインタラクションとR＆D
当社では、「正確に必要なもの」は、製品戦略を担当する特別な訓練を受けた人、つまり製品マネージャーによって決定されます。
- 製品が直面する戦略的なビジネス目標を決定し、会社全体が動いている場所とそれらを比較し、主要な顧客や実例となる顧客と通信します。
- ビジネス目標を知っているプロダクトマネージャーは、次のリリースに必要な変更のリストを作成し、分析を通じてそれらを開発チームに渡します。
彼からの12のタイムゾーンには、必要な機能を実装する開発チームが住んでいます。基本的には、スリープでも精神でも、そのような変更が必要な理由はありません。 それらのバックログは、ストアに送信した購入のリストにすぎません。 彼らは何を正確に調理しますか、原則として、彼らは知りません。
そのため、このコミュニケーションのギャップにより、よく知られている問題が増えています。
問題
1.ビジネス目標を達成するために製品にどのような変更が必要かについての決定は、製品マネージャーのみが行うため、これらの決定は必ずしも効果的で正当化されるとは限りません。
2.製品がどこに向かっているのか理解していないチームは、製品を改善する意欲がありません。 それらは機能をカバーするだけで、それ以上ではありません。
3.元の目標を知らずに、この機能をどのように実装する必要があるか、そしてこの順序で正確にチームに説明することは非常に困難です。
4.製品マネージャーの職業病を発症します。 彼らは、彼らの意見では自由である様々な些細な事柄で要件を拡張するために、リリース日に近づくのが大好きです。 これらの「小さな編集」はすべて、本当に重要でないかどうかわからないという理由だけで、未処理から抜け出すのは非常に困難です。
私たちは以前、さまざまな方法でこれらの問題を解決しようとしました。
1.マーケティング要件が記載された文書-MRD。 徐々に死にました。 おそらく、書くよりも話すのが習慣であるアジャイルへの移行へのオマージュとして。
2.「テーマ」=テーマがあり、リリースを説明し、すべての変更の一般的な傾向を1つの段落に設定することになっています。 うまくいきませんでした。
インパクトマッピングは、製品がどこに移動しているか、開発チームとしてこれにどのように貢献しているかを明確にするためのもう1つの試みになりました。
インパクトマッピング
インパクトマッピングは、戦略的な計画へのアプローチであり、製品マネージャーの頭のビジネス目標から、目標を達成するために必要な製品の変更まで、論理的なチェーンを構築できます。
アプローチの名前（インパクト-インパクト）は、私たちが理解しようとしているものによって決定されます：誰がどのようなインパクトを私たちの目標に与えることができるか、そしてそのときだけ、製品で何を変更する必要があるかを決定します。
出口では、マインドマップを取得します。マインドマップは、議論の過程で、ビジネスと処女の代表者によってまとめられます。 複数ページのドキュメントはなく、1つの適切に構成されたスキームのみ。
マップを準備するには、4つの簡単な質問に答える必要があります。
ステップ1.なぜ-なぜ
まず、なぜ-なぜという質問に答える必要があります
1.このバージョンの製品をリリースする理由
2.製品で何かを変更する必要があると考えるのはなぜですか
このステップでは、目標を定義します。 目標は当然スマート（SMART）でなければなりません：
1.特定
2.測定可能、
3.アクション指向、
4.合理的な時間で達成可能。
「なぜ」という質問に対する答えは、プロダクトマネージャーによるものです（そうである必要があります）が、彼の目標が基準を満たしているとは考えられません。 この目標に取り組む必要があります。
良い目標は、既成のソリューションではなく、解決すべき問題です。
ステップ2.誰-誰
次に、Who？という質問に答えます。 -誰？ 主なタスクは、関心のある（またはそうでない）人々の輪を決定することです。
1.誰が私たちの目標を達成するのを助けることができますか？
2.誰が干渉できますか？
このステップでは、ユーザーだけでなく、関係するすべての人々を考慮することが重要です。 結果に影響を与えることができる人は誰でも私たちのカードを手に入れるべきです。 製品は真空状態では機能せず、製品の使用はエンドユーザーだけでなく影響を及ぼします。
私たちの場合、それは私たちが統合し、マーケティングする他のチームであり、会社のトップマネージャーでさえあることが判明しました。
ステップ3.方法-方法
1.関係する各人の質問に答えます。この俳優が目標を達成するのを助けるために、この俳優の行動をどのように変更（影響）する必要がありますか？
2.ユーザーおよびその他のアクターへの影響を判断します
これはおそらく、インパクトマッピングアプローチ全体からの唯一の「質問」であり、例による説明が必要です。
「試用期間後も製品を使い続けたいユーザーの数を増やす」という目標を設定したプロジェクトがありました。
インパクトが定式化されました-「価値を生み出すまでの時間を短縮する」、すなわち 製品が提供する機会、ユーザーが解決する問題（ユーザーがオートランを開いた瞬間から開始）を理解するためにユーザーが必要とする期間を短縮するため。
理想的に定式化されたインパクト-シンプルで直接目標に影響を与えます。
実際、ドキュメント、セットアップ、GUIなどに多数の変更が加えられました。
ステップ4.何-何？
マップを構築するための最後の質問は何ですか？..この段階でフィーチャが表示されます。
製品に変更を加えたり、目的の影響を与えるために何かを開発したりする必要は必ずしもないことを理解する必要があります。 たとえば、ドキュメントを変更するだけで十分な場合があります。 または別の例-ユーザーを引き付けるための機能は必ずしも必要ではありませんが、代替ソリューションはマーケティング活動と広告キャンペーンです。
マップステージ
1. SMARTの要件を忘れずに目標を決定し、
2.目標にどれだけ近づいているかを示す指標を選択します。
3.目標を達成するための中間段階（マイルストーン）を決定し、
4.マップのバックボーンを描き、4つの重要な質問に答えます-なぜ+誰+どのように+何、
5.可能な代替手段を探しています。機能ではなく、役割（誰？）に焦点を当てることをお勧めします。
6.マップ上の優先順位を決定し、
7.進むにつれて、私たちが最も効果的な方法で目標に向かって動いていることを忘れないでください。
地図の例
この例は、レポートの終わり近くで言及される本から正直に引用されています。
1. 100万人のプレイヤーへの拡大を目的としたオンラインゲーム（中間段階は40万から80万のプレイヤーに2倍に成長します）
2.いくつかの役割が強調されています。目標を達成することで、プレイヤーだけでなく、たとえば広告主も支援できることは明らかです。
3.各ブランチでは、いくつかの影響が区別されます。
4.機能は目的に明示的に対応します。 問題を覚えていますか？ ここでは、私たちが何をしているのか、なぜなのか、さらに、目標に向かって進むためのいくつかの代替オプションがはっきりとわかります。
5.マップブランチのアスタリスクは、優先順位を示しています。
6.マップのブランチは、カスタムストーリーストーリーに簡単に分類されます（...として...したいので...そのように...）。
デルにインパクトマッピングを実装する
私はイニシエーターとして行動したため、まず第一に、実装全体が段階に分割されました。
ステージ1の時間は星によって決定されましたが、判明したように、現在のリリースの終わり、次のバージョンのタスクを把握する必要がある時間、これは新しいレールへの移行を開始するのに最適な時間です。
インパクトマッピングのアイデアをプロダクトマネージャーに販売し、新しい生活を送る必要がある理由を彼に説明することから始めました。 女子チームとして私たちが通常遭遇する問題、理解の欠如を感じる理由-製品が動いている場所と悪い理由について話し合いました。
私たちのPMにとって、この対話は驚きでした。 しかし、彼は明白なことを否定しませんでした。
そこで、私はインパクトマッピングのアイデアを紹介し、結果は共同の努力によって達成されること、そして彼が再び単一ページのMRDのみを書き始めることを示唆しないことを強く噛みました。
その後、次のリリースに向けてPMから目標をゆっくりと引き出し始めました。これによると、既に議論のための機能のリストがありました。
1.ここで最も難しいことは、マネージャーに特定の目標を設定させることであり、それは測定可能であり、限られた期間で達成されます。
2. 1時間の会議から、真実のように見えるものを選択するまで、ターゲットを40分間だけ突き合わせました。
3.もう一度、プロダクトマネージャーの頭の中に思考が存在することは、必ずしもそれを明確に表現できるという意味ではないと確信しました。
最初の会議の終わりに、印象を共有し、同意しました
1.目標についてもう一度考えます（長期的にも含む）
2. 1週間後、地図を描くために再び集まる
その週の間、私たちのプロダクトマネージャーは自然に目標を考えていませんでしたが、次の会議に備えました。 目標の草案がありました。マネージャーが以前にバックログにゼロ以下で入力したすべてを処理することに同意する可能性は低いという理解がありました。 したがって、私はバックログのリバースエンジニアリングをいくつか行い、今後のリリースのためにマップの最初のバージョンを自分で準備する必要がありました。
1.役割が十分迅速に特定された
2.必要な影響も
3.しかし、すべての機能が目標と接続することはできませんでした。 今後は、結果として、ほとんどの「非論理的な機能」が切り取られたと言います。
結果のドラフトは製品マネージャーに提出されました。
1.目標に適合しないものについて話し合い、これらの機能/ストーリーを突き刺し、
2.すでに特定された役割の枠組みで他に何ができるかを議論しました。
3.必要な材料（マーケティング、プリセールス）を提供することを除いて、製品側で何もする必要がなかったいくつかの新しい役割があります。
驚くべきことに、私たちのプロダクトマネージャーは、彼の目の前で完成されていたマップの完成に非常に積極的に参加しました。 彼のおかげで、製品の変更に関係のない多数のブランチがマップに表示されました。
製品に影響マッピングを実装する最終段階までに、リリースの最初から、影響マッピングを使用してバージョンの機能の構成を最初に概説します。
これまでのところ、最初の試みがどれほど成功するかを感じました。
社内レビュー
1.プロダクトマネージャーは、スクラムに近いさまざまな方法論を何度も詰め込んでいたと言いましたが、このアプローチは気にせず、本当に気に入っています（当然、マップはアナリストの責任範囲内にあり、それらによって描かれています）。
2.チームは、何が起こったかに大きな関心を示しました。 彼らは特に、自分の意見に耳を傾け、ビジネス目標に関して合理的な機能を提供できることを気に入っています。
3.チームはコンパスを受け取りました。これにより、スプリントの計画が容易になり、一連のストーリーと実装の詳細に関する紛争を最小限に抑えることができます。
4.私たちのマネージャーは、リリース計画の結果を理解するために、一般的な計画を実行する必要はなく、マップを見るだけで満足していました。 同時に議論は非常に簡単にオフラインで転送されます。
5.誰もが、チームの活動がカードに発芽しただけでなく、以前は影だった活動（マーケティング作業、ビジネスレベルでの製品のプッシュ）も気に入っています。
6.アナリストは、現在の状態のコールの各コールでカードを使用します。これは毎週実行され、カードの主要なブランチを通過します。 今では、より多くの質問を続けることに焦点を合わせていることがわかりました。
このアプローチについてさらに情報を得るには、Goiko Adzicによる同名の本を強くお勧めします。
PS次の会議で、レポートはまだ受信されています。 面白いメッセージを待っています！