製品開発ロードマップ：コース「ソフトウェア製品の作成とその開発の管理」

こんにちは、Habr！製品管理に特化した一連の資料を継続します。この投稿では、製品マネージャーがロードマップの内容を決定する方法と、バックログに優先順位を付ける方法について説明します。すべての詳細はカットの下にあります。

コース目次

1.製品マネージャーとフレームワークの役割

2.市場の細分化と競合分析

3.ユーザーペルソナ

4.仮説テスト

5.製品の位置付け

6.製品のロードマップ <-ここにいます

7.開発の要件の立案

8.ビジネスモデルとビジネス-計画

9.財務計画と価格設定

-継続



するロードマップを持つことは、製品開発を管理するために非常に重要です。ただし、ロードマップを正しく作成するためには、この問題に体系的に取り組む必要があります。ロードマップを適切に作成するにはビジョンを持つ必要がありますが、ロードマップとビジョンを混同しないことが非常に重要です。







国連のモットー：「グローバルに考え、ローカルに行動する。」興味深いことに、優れたソフトウェア製品のロードマップを作成するときにも機能します。これを行うには、あなたの願望が今ここで終わらないように、グローバルなビジョンを持っている必要があります。ビジョンの枠組みの中で、目標が設定されています。目標も非常にグローバルであり、ロードマップが導くのはこれらの目標です。準備されたマップに従って移動すると、リリースはこの移動のマイルストーンおよびステージになります。これは、製品開発の特定のステップの具体化です。



あなたは計画を立ててどの地平線を振るべきですか？異なる場合もありますが、最初は6か月に制限することをお勧めします。製品がどこに移動するかを正確に知っている場合は、3年または5年になる可能性があります。制限はありません。たとえば、彼の最近のスピーチでアマゾンの創設者であるジェフ・ベゾスは、50〜100年の計画期間を持つブルーオリジン宇宙プログラムを発表しました。つまり、人は自分の人生の後、ほとんどの時間働く会社を作ります。これはどうして可能ですか？



この場合、グローバルビジョンについて話しているだけです。BlueOriginは、激しい宇宙飛行の可能性を提供する必要があります。ベゾス氏によると、アマゾンは既存の宅配便とメールのインフラストラクチャを基盤としていました。それらが存在しなかった場合、Amazonは機能することも、それほど成功することもできなかったでしょう。今日、Blue Originは、ロケット、宇宙港、衛星、軌道ステーションなど、将来の宇宙旅行のためのインフラストラクチャを作成することを計画しています。ブルーオリジンの世界的な目標は、2025年までに宇宙船を建造することです。



グローバルな目標を理解することは、ロードマップを作成するのに役立ちます。ロードマップでは、具体的な手順を示し、近い将来に設定された目標を達成するための現実的な計画を作成します。そして、Blue Originは、野心的な計画を持つ企業として、その使命を果たしようとしています。それは、人や物のアクセスしやすく便利な移動のための世界的なサービスを組織することです。

天から地へ..。

より現実的な例を考えてみましょう。建設会社が高品質の建設に従事している場合、その作業の概念は次のようになります。



●ビジョン-モスクワ北部（SAO）で最高の住宅地を建設する。

●目標-5000のアパートメント、モダンな建築、クラスの快適さ、便利なレイアウト、車のない中庭。

●ロードマップ-テリトリーの開発と改善のキュー。

●リリース-コンクリートで仕上げられた建物、道路、公園（完成の段階で分割可能）。

●機能-リリースのコンポーネント。たとえば、遊び場、植えられた木、屋根付きの駐車場、ランプ。

ソフトウェア製品のロードマップを作成するにはどうすればよいですか？

ソフトウェアロードマップにはリリースが含まれており、各リリースには特定の機能が含まれている必要があります。利用可能な機能とリソースを考慮して、日付ごとにロードマップをスケジュールすることが非常に重要です（これについては後で詳しく説明します）。たとえば、これはソーシャルアプリの1つのロードマップがどのように見えるかです。







ロードマップは、すべての部門に対して一度に計画する必要があることに注意してください。会社が大きく、営業マネージャーが独自のロードマップを持っている場合は、それを開発部門のロードマップにリンクする必要があります。そうでなければ、たとえばアジア市場で製品を宣伝する時が来たとき、あなたは既成のローカリゼーションを持っていないことが判明するかもしれません...そして実際に中国語をサポートしています。







製品に何を含めるべきかについての要求は、多くの異なる四半期から来ています。これについては、以前の投稿の1つですでに説明しました。..。それらは注意深く整理され、計画される必要があります。バージョン1.0ではすべての機能を準備してリリースすることはできないことを理解することが重要です。実際には、すべてのアイデアを実装するのに十分なリソースがないためです（そうでない場合は、アイデアがほとんどなく、さらに考える必要があります）。



適切なアプローチにより、ロードマップは、製品開発プロセスを段階に分割し、反復における優先度と重要性を下げて機能を展開する機会です。ソフトウェア開発を制御する



別のソフトウェア製品開発フレームワーク（ソフトウェア製品管理フレームワーク）を見てみましょう。







特定のフレームワークの下で生活している企業の成熟度マトリックスは、次の表によって決定されます。また、ロードマップの作成プロセスを正式に順守することで、会社はすぐに2番目の成熟度に到達します







。一般に、このフレームワークは、製品開発のすべてのコースの独立したブランチです。今はそれにこだわるつもりはありません。このトピックに関する追加の投稿を読むことに興味がある人は、この投稿にコメントを残してください。



ここでは、ソフトウェア開発のいくつかの正式な手順を遵守し、これらのプロセスを構築することによって、会社自体がより優れたソフトウェアを提供する文化を向上させることのみを受け入れます。ロードマップはこの文化の一部です。

製品要件を収集して処理する方法は？

さまざまな側面から要件を受け取った場合、それらを何らかのシステムに入力する必要があります。たとえば、Acronisは非常に強力なツールであるJiraを使用しますが、スタートアップの場合は、RedmineやAsanaなどの無料のものを含むより単純なものを使用できます。



重要なのは、悪い考えがないため、すべてのアイデアが登録されていることです。アイデアがまだ実装に値しない場合、その優先順位は低いままになります。したがって、「どのように機能するか」の詳細な説明がなくても、すべての文をシステムに入力することが非常に重要です。このアプローチでのみ、要求される機能の実装を計画できます。つまり、実際のロードマップを作成できます。







すべてのアイデアは、いわゆる「受信バックログ」に到達します。これらの機能を誰が必要としているかを評価および理解することなく、形式化または「未加工」にすることができます。リクエストを処理して詳細を追加した後、それらの一部は次のリリースに進むことができます。残りはバックログに送られ、私はそこに長く滞在することができます。

大作

アジャイルまたはスクラムの方法論は、「エピック」のような用語を意味します。その本質をできるだけ簡単に説明する場合、いくつかの大きな機能について話します。その実装には、開発者、テスター、インターフェイスデザイナー、テクニカルライターなどのすべての参加者の関与が必要です。



通常、エピックを作成するときは、ビジネスの観点からの重要性が評価され、人件費が計算され、現在のリリースに含めるか、バックログに送信するかが決定されます。







すでに採点されているエピックの場合、システムで優先度を割り当てることができます。たとえば、同じJiraで、「高」、「中」、「低」を設定できます。ただし、たとえば、Acronisのバックログには、数百、さらには数千の機能があります。この場合、単純な優先順位が不可欠です。

機能スコアの計算

より複雑なスコアリング方法は、機能スコアと呼ばれます。アイデアは、開発に影響を与えるすべての要因を単一の評価にまとめることです。次に、正規化された評価に基づいて、その機能をリリースに含めるか、現時点で開発を中止するかを決定します。したがって、正のメトリックは機能にポイントを追加し、負のメトリックは反比例で機能します（値が多いほどポイントが少なくなります）。肯定的な指標には次のものがあり



ます。1。緊急性。

2.それを必要とするクライアントのサイズ。

3.新規顧客の出現による市場シェアの拡大。

4.現在のクライアントの離脱による潜在的な利益または損失。

5.戦略的成果（ビジョンの具現化につながる目標）。



ネガティブメトリック：

1。人件費の額。

2.潜在的なリスク。



機能スコアは数値である必要があります。これは定性的な評価ではなく、ある種の評価であり、その計算方法は、特定の製品の開発の枠組みの中で統一され、承認される必要があります。



ポイントは、正規化された値、会社の市場目標、およびその他のパラメーターに基づいて決定されます。機能スコアで考慮される最初のパラメーターは、顧客要因です。いわゆるカスタマーファクターは、緊急性とカスタマーサイズの積として定義されます。下の画像で計算の例を見ることができます。







市場参入度は、新しい顧客を引き付ける可能性として定義され、顧客ベースを拡大する計画によって異なります。たとえば、新規顧客を引き付けない機能の場合、このパラメーターは0に等しくなり、たとえば500人の顧客を引き付けることができる機能の場合、スコアは20になります。



次の質問は戦略コンプライアンスです。戦略を評価するには、この機能が戦略的な開発の方向性に沿って進むのに役立つかどうかを確認する必要があります。そして、それがカバーする方向が多ければ多いほど、スコアは高くなります。







収益は、機能の実装がもたらす可能性のある潜在的な利益です。このパラメータの見積もりは、会社の規模、製品の特性、および期待する収益によって異なります。この表は、このインジケーターのスコアリングの例を示しています。







しかし、今度は反対の要因について話しましょう。それは、機能に与えるポイントが少ないほど、それらがより多く現れるということです。たとえば、特定の機能の開発にいくら費やしてもよいかによって、開発コストを特定の見積もりの​​レベルで固定することもできます。







リスクは2番目の側面です。評価に対する信頼度が低いほど、リスクが高くなります。つまり、機能スコア式の基準の値が低くなります。







上記のすべての要因を考慮した後、機能スコアの式は次のようになります







。特定の要因に基づいて、スコアが客観的である場合は適切です。ただし、市場に参入したばかりの場合でも、機能スコアを作成してください。まったくないよりも主観的である方が良いです。

タクシーアプリケーションの例のロードマップ

以前の投稿の1つで、タクシーを呼び出すためのアプリケーションの作成についてすでに説明しました。この製品の次の機能をランク付けする必要があるとし







ます。優先順位のあるテーブルは次のようになります







。「適切なタイミングで注文する」機能について考えてみます。すべてのパラメーターを合計すると、56になります。この数値はどういう意味ですか？何も！これは相対的な評価であり、同じ基準と評価に従って、9つの機能すべてを計算する必要があります。結果は優先順位リストです。私たちのアプリケーションでは、明らかにAndroid上でモバイルアプリケーションを作成する必要があります。 2番目の動きは「子供向け」の料金です。



体系的なアプローチにより、ビジネスにとってそれほど重要ではないことを実行したり、実装のために「ランダムな機能」を選択したりすることができなくなります。段階的および段階的な作業の収益率は高くなります。そして、これは非常に重要です。なぜなら、各プロジェクトの開発には、時間、コスト、量などの制約要因が常にあるからです。その組み合わせはあなたに品質を与えます。

優先事項だけではありません

リリース計画では、開発チームの能力が考慮されます。一部の製品には、そのようなコマンドが複数あります。たとえば、タクシー注文サービスを作成するには、少なくともバックエンド、QA、Android、iOSコマンドが必要です。



ただし、優先順位を付けることに加えて、開発者が次の各機能に取り組むために割り当てることができる時間数も見積もる必要があります。これを行うには、チームの人数に、準備に割り当てられた日数を掛ける必要があります。次のリリース（スコープ）で利用可能な容量に何が入るかを理解することは、リソースの浪費を回避するのに役立ちます。



1つのリリースサイクルでのさまざまなチームの容量：







以下の表を見ると、iOSのモバイルアプリケーションには、iOS開発チームだけでなく、バ​​ックエンドやQAのスペシャリストにも多くのリソースが必要であることが明らかになります。そのため、チームはとにかく作成する時間がないため、最初のリリースにiOS用のモバイルアプリケーションを含めないことを経営陣が決定するのは論理的ですが、一方で、「適切な時期にタクシーの注文」を完了します。







したがって、並べ替えられたすべての機能の優先度の順に進むと、タクシーを注文してアプリケーションを開発するためのロードマップ







は次のようになります。後続の各バージョンには、開発チームの能力に配置される次の優先度の機能が含まれます。

ロードマップ-製品開発哲学として

ロードマップはコミットメントではなく、予測であることを忘れないでください。ロードマップを現在の計画として扱うことをお勧めします。 1か月以内に新しいクライアントが来て、新しい機能を要求する可能性があります。そして、彼女をバックログに追加すると、彼女の優先順位はおそらく以前に計画されたものよりも高くなります。原則として、製品に取り組むときは、あらゆる瞬間のロードマップを用意することが重要ですが、今日は変化する市場の状況に適応する必要があるため、静的にするべきではありません。



ロードマップ（一般的なルールに従って機能に優先順位を付ける）を使用して提案された作業には、内部文化が必要です。すべての利害関係者は同じスコアリング原則に従う必要があるため、最初のステップは計算式について話し合い、次にこのルールに従うことです。もちろん、優先順位を改善する方法を理解していれば、すべてを変更できますが、その後、バックログ全体の優先順位を再計算する必要があります。



大規模な製品の場合、カスタム機能の開発に直接関係しないものに開発チームの異なる能力を割り当てることもお勧めします。たとえば、開発チームのリーダーは次のように言うかもしれません。「新しいバージョンのPythonに切り替える必要があります。そうしないと、より多くの時間（お金）があります。）古いバージョンで既存のエコシステムを維持するために費やします」。このような問題を解決するために、たとえば、チームのキャパシティの25％を新規顧客の獲得に関連する機能に割り当て、45％を現在の顧客の維持に、20％を技術的負債とリファクタリングに割り当て、10％をバッファとして残して機能の余地を残すことができます。製品開発に直接関係のない活動（新しいビルドシステムの展開、CI \ CDの実装など）を説明するために突然または頭上に来た人。

結論

開発の計画とロードマップの調整を成功させるには、バックログを定期的に確認し、開発を計画していてリリーススコープに含める機能の機能スコアを再計算する必要があります。ただし、次のリリースをすでに決定している場合は、マネージャーと開発者の間の相互作用を確立する必要があります。



これを行うために、次の投稿では、開発部門が設定する必要のある機能の要件を作成するためのメカニズムについて説明します。これは、機能を開発するために必要です。できれば、見たい形で開発してください。要件を明確にする必要がある理由、要件を形式化する方法、および開発者の要件を処理するために存在するプラクティスについて説明します。



→コースのすべての講義のビデオ録画はYouTubeで利用できます



開発のロードマップと要件に関する講義：