產品營運模式：Marty Cagan 訪談摘要產品營運模式由 Marty Cagan 提出，旨在為傳統企業提供以產品為中心的轉型路徑。這種模式強調賦權產品團隊，將裁決權下放給負責解決關鍵問題的專家。 Cagan 批評傳統的 Scrum 設置，倡導透明和持續交付流程，注重創新而非可預測性。產品營運模式強調委託、跨職能團隊合作，將工程師、設計師和產品經理的角色連結在一起。這種方法不同於 Scrum 團隊，後者通常僅由開發人員組成。
TL; DR：產品營運模式：Marty Cagan 專訪
讓我們來探討Marty Cagan 對產品管理革命、擁抱授權團隊以及透過採用其最新著作《轉型》中所描述的產品營運模型來促進創新的見解。我們將揭示如何有效地導航到以產品為中心的方法的轉型路徑，以及 Marty 在這種背景下如何看待 Scrum。
《變身》書籍封面
產品營運模型面試問題集1：一般模型
馬蒂·凱根的「轉型」強調了向產品營運模式的關鍵但可行的轉變，強調轉型的第一步、信任的關鍵作用以及對結果的關注。他用行業實例來反駁質疑，並討論了產品運營模型的適應性和可擴展性。 Marty Cagan 也談到了產品經理不斷變化的角色，平衡速度與品質和持續的客戶參與。第一組問題涉及產品營運模型本身：
1. 理解轉型
Marty，在《轉型》一書中，您認為轉型為產品營運模式對於傳統公司來說是必要且可能的。請詳細說明公司為啟動這項轉型應採取的首要步驟。
Marty Cagan：我們建議從組織評估開始。我們提供了第 29 章中使用的。
2. 成功案例研究
本書對成功轉型進行了詳細的案例研究。您能否分享一個書中未包含的例子來說明一家公司在轉型過程中克服了重大障礙？
馬蒂凱根：這就是寫這本書的目的。每一個案例都體現了一家公司克服重大障礙的例子。每個案例研究都代表了一項重要的工作。
3. 賦能產品團隊
您強調了授權產品團隊的重要性。根據您的經驗，組織中最常見的賦權障礙是什麼？如何消除這些障礙？
馬蒂凱根：最大的障礙是信任。它需要高階主管和利害關係人真正信任，才能授權其他人承擔解決關鍵問題的責任，這就是為什麼轉型就是要逐步贏得這種信任。
4. 領導在轉型中扮演的角色
CEO和高階領導應如何改變思考和運作方式，以促進向產品模式的成功過渡？
Marty Cagan：主要是高階領導者需要了解產品模式及其意義。然後，他們需要願意為產品團隊提供機會來證明他們值得信任。
5、轉型後的創新
一旦公司成功轉型，哪些做法可以確保其持續創新並且不會陷入舊模式？
馬蒂凱根：一旦對話真正轉向結果，一旦團隊證明他們知道如何實現結果，那麼公司就很難恢復到僅僅輸出。因此，關鍵是要專注於一致的結果。
6. 轉型成功的衡量標準
您建議公司追蹤哪些指標或指標來衡量其轉型為產品主導型組織的有效性？
Marty Cagan：雖然有許多進展指標，但由於轉型的重點是交付成果，除非產品團隊開始交付成果，否則其他指標都只不過是活動衡量標準（又稱虛榮指標）。再說一遍，關鍵是持續交付成果。我們建議從特定的試點團隊開始，然後從那裡擴展。
7.解決懷疑論
您如何解決公司內部的懷疑，特別是那些認為產品營運模式不適用於其特定產業或市場的懷疑？
馬蒂凱根：首先，我們都應該承認懷疑是正常且合理的，尤其是在做出瞭如此多承諾但未能兌現結果的組織中。其次，這就是為什麼書中的例子涵蓋了世界上如此多的不同行業和地區，從受監管的金融服務到受監管的醫療保健再到受監管的鐵路旅行。但需要指出的是，如果有人想找到一個不嘗試轉型的理由，那麼選擇某件事並說「這就是我們不能這樣做的原因」並不難。但這本書充滿了公司忽略這些人的例子。
8. 產品策略與願景
您如何建議公司製定與產品營運模式一致、同時適應市場變化的產品策略和願景？
Marty Cagan: もし彼らが『EMPOWERED』という本を読めば、強力な製品ビジョンと製品戦略を作成する方法を理解するでしょう。また、製品ビジョンが数年にわたるように設計されている一方で、製品戦略は複数年にわたるように設計されていることがわかるでしょう。四半期ごとに一度更新して、市場の変化 (および製品チームの継続的な学習) に適応します。
9. アジャイルと製品の実践のスケーリング
大規模な組織内の複数のチームや地域にまたがってアジャイルと製品の実践を拡大するときに考慮すべき重要な要素は何ですか?
Marty Cagan: この製品モデルは、いくつかの要素で他の企業よりも規模が大きい、世界最大のテクノロジー主導型製品組織の一部で使用されています。したがって、モデルがスケーラブルであるかどうかには疑問の余地はありません。実際、このモデルの中心となるのは、継続的なイノベーションと大規模な結果です。
10. プロダクト マネジメントの将来
テクノロジーの急速な進歩に伴い、今後 10 年間でプロダクト マネージャーの役割はどのように進化すると思いますか?
マーティ・キーガン: これは大きな話題です。 「将来に向けた準備」を参照してください。
11. スピードと品質のバランス
企業は、製品開発のスピードと高品質基準を維持する必要性とのバランスをどのようにとっているのでしょうか?
Marty Cagan: 重要なのは、チームが製品モデルの原則、特に小規模で頻繁な独立したリリース、つまり継続的デリバリーを使用している限り、スピードと品質は相互に排他的ではないことを認識することです。 『Accelerate』という本を読んで、最良の組織がどのようにしてより迅速に行動し、より高い製品品質を維持するかという背後にある理論的根拠を学びましょう。
12. 変革中の顧客中心主義
企業が変革中および変革後にどのようにして顧客中心主義を維持しているかについて説明していただけますか?
マーティ・ケイガン: 企業が製品モデルの原則に従う場合、それはユーザーや顧客と緊密かつ継続的な関わりを持つことを意味します。実際、これが変革の主な理由の 1 つです。顧客との対話はイノベーションのプロセスにとって非常に重要です。
13. 失敗から学ぶ
個人的または観察された変革の試みの失敗例と、その経験から得られた教訓を共有していただけますか?
マーティ・キーガン: 「移行の失敗」を参照してください。
14. 新しいテクノロジーの統合
企業は、変革の一環として、人工知能や機械学習などの新しいテクノロジーを製品開発プロセスにどのように統合すべきでしょうか?
Marty Cagan: 製品モデルを使用する企業の特徴の 1 つは、特に新しい実現テクノロジーの源としてのエンジニアの関与のレベルです。現在、人工知能と機械学習の応用において先導している製品モデル企業を目にすることができます。
15. 変化する市場で機敏性を維持する
企業は、新たに採用した製品モデルが機敏であり、予期せぬ課題に対応できることをどのように確保できるでしょうか?
Marty Cagan: これが、製品モデルがプロセス、フレームワーク、または方法論ではなく一連の原則である主な理由です。
製品オペレーティング モデル インタビューの質問セット 2: モデルとスクラム
2 番目の質問セットでは、製品オペレーティング モデルとスクラムの微妙な違いについて説明します。権限を与えられたチーム、役割のダイナミクス、アジャイル環境でのスケーリングに関する問題を掘り下げていきます。 Marty Cagan は、従来のスクラム設定を批判し、権限を与えられた製品チームにおける役割の差別化と深さを強調し、伝統的なスクラムの実践に挑戦し、予測可能性よりもイノベーションを擁護します:
16. 権限を与えられた製品チームとスクラム チームの比較
マーティ、あなたのフレームワークでは、問題を創造的に解決するために製品チームに自主性を与えることを主張していますね。この概念がスクラム フレームワークの自己管理チームの概念とどのように異なるか、またはそれとどのように一致するかについて詳しく説明してもらえますか?エンパワーメントを促進する上で、スクラム チームのどのような側面が十分に活用されていないと思いますか? Marty Cagan: ほとんどの「スクラム チーム」は、単に開発者とバックログ マネージャーのプロダクト オーナーのグループであり、「デリバリー チーム」とも呼ばれます。権限を与えられた製品チームは、開発者、デザイナー、製品マネージャーなど、完全に部門を超えた専門家で構成されています。「製品チームと機能チーム」を参照してください。より一般的には、スクラムは特定の配信プロセスです。製品チームは発見と提供を目的として設計されており、エンジニアは当面の提供タスクに最適と思われるあらゆる提供プロセスを使用できます。17. 役割の比較
プロダクト運用モデルでは、プロダクト マネージャー、プロダクト デザイナー、テクニカル リードの役割を、プロダクト オーナー、スクラム マスターと比較してどう思いますか?開発者などのスクラムの役割間の同意または不一致?スクラムの役割は、真に権限を与えられた製品チームに必要な責任を適切に概説していると思いますか、それともモデルにギャップがあると思いますか? Marty Cagan: プロダクト オーナーは、真のプロダクト マネージャーの約 10% に相当します。あなたの「スクラム チーム」にはプロのプロダクト デザイナーが完全に不足しています。スクラム マスターは通常、デリバリー マネージャーが担う役割ですが、製品モデルに関係なく、プロダクト リーダー (エンジニア、デザイナー、プロダクト マネージャーのマネージャー) は、強力なプロダクト マネージャーを指導し育成する任務を負っており、強力なプロダクト マネージャーの主な責任は次のとおりです。 。デザイナー兼実力派エンジニア。テクニカル リードは、発見と提供において中心的な役割を果たす上級開発者です。正直に言うと、スクラム チームはプロのプロダクト チームと比較するとかなりアマチュアです。世界トップクラスのテクノロジー主導の製品企業は、製品チームによって構築されています。18. スクラム イベントと成果物
スクラムでは、開発プロセスをガイドする特定のイベントと成果物を指定します。これらの実践は製品の運用モデルにどのように適合しますか?これらのイベントや成果物は製品のオペレーティング モデルに組み込まれていますか、それとも製品チームに権限を与える原則に沿った別のアプローチを提唱していますか?
Marty Cagan: 製品チームのエンジニアがデリバリー作業にスクラムを使用することに決めた場合、必要に応じて公式または非公式にスプリントを実行できます。しかし現実には、ほとんどの製品チームは数年前にスクラムを超えて、継続的デプロイメントとより自然に統合できるもの、通常はカンバン ボードまたは簡略化された派生製品に移行しました。
19. アジリティと製品戦略のバランスをとる
スクラムに対するよくある批判は、長期的な目標を犠牲にして短期的な配信目標に集中しすぎる可能性があるというものです。製品戦略。あなたの製品のオペレーティング モデルは、製品の一貫した戦略的ビジョンと連携しながら、チームが機敏で変化に対応できるようにするにはどうすればよいでしょうか?
Marty Cagan: それが戦略的コンテキストのすべてであり、プロダクト リーダーの重要な役割です。製品会社では、アジャイル/スクラムコーチは、各製品チームが独自の製品ビジョンと製品戦略を持っているとアドバイスします。これは、製品会社で働いていないことの非常に明らかな兆候です。 EMPOWERED は、製品チームが正しい意思決定を行えるようにするために必要な戦略的コンテキストについて説明します。
20. スケーリングに関する考慮事項
組織の規模が成長するにつれて、同じ製品に取り組んでいる複数のスクラム チームを管理するために SAFe や LeSS などのフレームワークに頼ることがよくあります。製品チームに権限を与えるという概念は、大規模な組織全体にどのように拡張されますか?これをスクラムのスケーリングアプローチとどう比較しますか?拡張されたスクラム フレームワークから得られた貴重な教訓や、別のアプローチが必要だと思われる領域はありますか?
マーティ・ケイガン: 上記の質問 #9 の回答を参照してください。しかし、より一般的に、SAFe のようなプロセスはイノベーションではなく、予測可能性を最適化することに重点が置かれています。これが、世界に 1 社も存在しない理由を説明する私の理論です。 SAFe を使用する、または SAFe を単一の製品モデルとして使用する。さらに、アジャイルの背後にある原則によれば、SAFe はアジャイルではありません。これは明らかにウォーターフォールであり、予測可能性を考慮して設計されたプロセスとしては確かに理にかなっています。対照的に、製品モデルの最初の原則の 1 つは予測可能性よりもイノベーションであり、もう 1 つはプロセスよりも原則です。したがって、この製品モデルが SAFe のようなウォーターフォール配信プロセスと互換性がない理由は簡単に理解できるはずです。そうは言っても、SAFe の次のイテレーションでは「製品モデル」という用語が登場することを私は完全に期待しています。これは長い間彼らのマーケティング戦略であり、彼らは自分たちがやっていることを理解していない、または関心を持っていない人々に頼っているからです。 。
結論
Marty Cagan とともに製品オペレーティング モデルを調査する中で、私たちは製品中心のアプローチに向けた変革の旅に着手し、権限を与えられた製品チームとチームの間で起こり得る相互作用を分析しました。スクラムダイナミクス。ケイガン氏は、強力な製品チーム内で微妙な役割を優先する従来のスクラム フレームワークを批判し、イノベーション主導で適応性のある製品管理戦略の必要性を強調しています。
どのようなモデルの製品を使用していますか?さらに興味深いのは、スクラムにはまだ居場所があるのでしょうか?学んだことをコメント欄で共有してください。
以上是Marty Cagan 談產品營運模式與 Scrum 的未來的詳細內容。更多資訊請關注PHP中文網其他相關文章！
