読書メモ「プロフェッショナルプロダクトオーナー」

各章メモ

1章：戦略

プロダクトマネジメントのすきま

外の2つは経営層が考えること、うち二つは開発社の関心ごと、その間にはすきまが生まれる。
ビジョン、価値、検証がプロダクトマネジメントのすきまを埋める。

プロダクトのビジョン

ビジネスモデルキャンバス
リーンキャンバス

価値

プロダクトはリリースされるまでは価値がない
価値は最終的に収益と費用であらわされる
価値指標にインセンティブを設けてもパフォーマンスと士気は改善しない
→グッドハートの法則：尺度が目標となった時、それはよい尺度ではなくなる
指標はビジネス仮説の検証やリリースのインパクトの検証に役立つ
価値には見えるものと見えないものがある
リリースはネガティブな価値を生むこともある

検証

試乗に対してテストするまではすべてが仮説にすぎない
ステークホルダーがフィードバックをすればするほど、プロダクトの方向性に責任を持つようになる

2章：スクラム

スクラムのイベントをプロダクトオーナーを中心にまとめた章

・スクラムはフレームワーク
・スクラムチームがスクラムのフレームワークを変更したらそれはスクラムとは言えない
・スクラムチームがスクラムのフレームワークに追加するのはよい

3章：戦術

プロダクトバックログ

プロダクトバックログはあらゆる種類の作業を受け付ける（機能要求、非機能要求、実験、ユーザーストーリー、バグ・欠陥、ユースケース、ケイパビリティ）
スプリントの終わりまでに完成できないなら大きすぎる、適切な大きさになるまでリファインメントする

スパイク

技術やドメインに対するチームの知識が不十分な時に、PBIを分割できない。スパイクとは、要求された機能を完了させるのに何が必要かを学ぶことを目的とした調査用のプロダクトバックログアイテム
注意：スパイクはビジネスに直接の価値をもたらさないので乱用に注意

プロダクトバックログの並び順

ビジネス価値、リスク、コスト/サイズ、依存関係を意識して決定
（ビジネス価値＋リスク）÷サイズ＝並び順

完成

完成を定義する必要がある（例）
バリー・オーフレイム
・設計されている
・ドキュメントが更新されている
・テストが実施されている
・プロダクトオーナーにより受け入れられている
・スプリントレビューでの「デモ手順」が明確化されている

プロダクトのスケーリング

・一つのプロダクトに1つの開発チーム
スクラムの基本

・複数のプロダクトに一つの開発チーム
NGと考えてよさそう

・複数のプロダクトに複数の開発チーム
一つのプロダクトにつき、一つ以上の開発チームの体制に移行すべき

・一つのプロダクトに複数の開発チーム
大規模なプロダクトに対するアプローチ