私の名前はマキシムです。過去8年間、大企業でビジネスアナリストおよび製品所有者として働いてきました。今日は、多数の開発チームを使用して編成された製品開発についての私の考えを皆さんと共有したいと思います。
このトピックに興味があり、喜んで話す人は、猫の下で歓迎します。
大企業から始めましょう。大企業とは、何千人もの開発者、テスター、アナリスト、DevOpsエンジニア、製品所有者、その他の人事管理者がいる企業を意味します。これらは、数十の部門、数百のチーム、複雑な階層、無限の依存関係、および責任範囲です。
そのような会社に入ると、最初はナビゲートするのが難しいです。しかし、時が経ち、今では自分の「島」を想像することができます。原則として、これらは次のとおりです。
- 非常に大規模で複雑なビジネスプロセスに関与する、理解しやすいシステムまたはコンポーネント。
- 製品の所有者は、間違いなくこのシステムをどこで開発するかを知っている人です。
- 関連性の程度が異なる一連のドキュメント。
- 自動化された、それほどではない一連のテスト。
おなじみですか？
これは典型的なものであり、最悪のソフトウェア開発システムではありません。通常、成功した製品を持つ企業の開発部門は、10〜15年でこの形になります。成功した製品はお金をもたらし、お金は開発に投資されます。開発は飛躍的に成長しており、直線的にスケーリングされ、プロジェクトマネージャーがすべての依存関係を頭の中で維持できなくなり、多くのチームが「包括的」になり始め、場合によっては製品に損害を与える状況になります。それを開発するのではなく。このような状況では、1つのチームが自分の成功を目指して努力するのはごく普通のことであり、同僚が問題を抱えていることを心配する必要はありません。そのため、共通の機能が提供されません。ユーザーが必要とするものではなく、無限の利害関係者が最も大きな声で尋ねる機能を開発することは、物事の本質です。「テーブル上」での開発は珍しいことではありません。プロセスは進行中です-要件が来て、実装され、テストされ、提供されます。喧騒の画面の後ろに主要なものを隠すのは簡単です-製品開発は以前ほど効果的ではありません。
この効率の低下を理解するために、製品管理の古典に目を向けましょう。今、あなたにいくらかのお金でこの科学を教えることができる十分なオンラインの学校または大学があります。
あなたがそれらを知らなかったなら私の小さなリスト
つまり、「クラシック」によれば、製品は人々が購入するものです。プロダクトマネージャーの仕事は、ターゲットオーディエンスを見つけ、価値のあるメッセージを決定し、適切な販売チャネルを選択し、経済を縮小し、成長ポイントを見つけ、すべての適切な仮説を整理することです。必要に応じて、アイデア、ターゲットオーディエンス、チャネル、メッセージ、ビジネスモデル、市場を変更します。または、予測可能な見通しがないことが明らかな場合は、製品を強制終了します。
上記の話のように聞こえませんか？
重要なのは、あなたが小さなスタートアップである場合、すべての製品開発プロセスは非常に透過的で簡単です。問題を見つけて修正するのは非常に簡単です。製品のアイデアを理解するのは簡単です。必要な機能を理解して開発するのは簡単です。ユーザー-手元にあります。製品-ここに、すべてのメトリックがあります。
しかし、時間が経つにつれて、製品は市場シェアを獲得し、製品ラインに発展し、ますます多くの開発者が採用され、あなたがそれを知る前に、あなたの会社は構造、利益、責任の巨大な混乱に変わります。
- カスタム製品ユーザー？今、あなたの製品の所有者はそれらを覚えていません。彼らはある利害関係者から別の利害関係者に急いで行き、最初にどのような要件をつかむべきかを理解しようとします。
- ユニットの経済学は明確で透明でしたか？現在、製品の所有者はPnL（Profit and Loss）を考慮せず、チーム全体をスプリントフロアに疑わしい利点のある側面でロードしています。
- 仕事の話、カスタマージャーニーマップ、その他の人はいますか？現在、彼らは店に「製品の所有者として、運用および保守部門がそれを必要としているので、これを実行してほしい」と書いています。
- 結果と条件に対する責任についての理解はありましたか？これで、各チームはそれ自体のためになりました。あなたの機能は、リリースまたは2年後に本番環境に配信されます。
大規模製品の開発管理の複雑さは飛躍的に高まっています。何をすべきか？
トップマネジメントが最初に頭に浮かぶのは、この複雑なシステム全体をスイスの時計のように機能させる魔法のフレームワークが必要だということです。需要があります-供給があります。私は、理論的には目前のタスクに対処できるそのようなフレームワークをいくつか知っています。
それらは「銀の弾丸」ですか？
私は、ゴールデンコーチが採用され、最新の管理およびコミュニケーションプロセスが導入されるという、いくつかのビジネス変革を経験しました。何千人もの人々が一夜にして立場を変え、新しい構造、新しいチーム、新しいプロセス、新しいプロジェクトに移りました。
そして、私は次のように言うことができます：
- それは高価です。
- 速くはありません。
- それは非常に危険です。
- 最終的な成功は、会社の文化に大きく依存します。人々が理解し、信じれば、成功する可能性があります。
このアプローチが唯一の正しいアプローチですか？他に何ができるか見てみましょう。
製品開発を拡大する方法は他にもあると思います。残念ながら、手順を追った説明はありませんが、これに役立つ可能性のある私のアイデアは次のとおり です。
製品。製品は付加価値を持たなければなりません。価値の観点から、システムとコンポーネントの動物園を検討してください。エンドカスタマー、カウンターパーティ、またはサードパーティのすべてのバリューストリームを強調表示し、システムマップをそのようなストリームで分割します。各製品の所有者は、管理下にあるバリューシステムの完全なチェーンを持っている必要があります。責任の範囲が大きすぎる場合は、彼に2人のアナリストを与えてください。
指標..。管理するには、最初に測定方法を学ぶ必要があります。各製品の所有者は、製品のメトリクスを特定する必要があります。これに基づいて、この製品の開発を行います。
ユーザー。利害関係者を脇に置きましょう。ユーザーだけが製品の価値について真のアイデアを与えることができます。製品の所有者は、インタビューの結果と仮説のサポートチケットの分析に導かれる必要があります。
仮説。機能のブラインド実装はもうありません。すべてのエピックまたは機能は、メトリックへの影響を期待する必要があります。機能を実装してA / Bテストでテストする場合、製品の所有者は仮説が成功したかどうかを理解する必要があります。
調整..。もちろん、複数の製品の作業は、選択したフレームワークに従って調整する必要があります。ただし、この調整を製品マネージャーの共同責任委員会に変えるべきではありません。
上記の条件を維持することによってのみ、製品管理を正常にスケーリングでき、概して、このスケーリングにどのフレームワークを選択するかは重要ではないと思います。