Roleについて考えてみようと思ったので考えてみる。今日はProduct Manager。Product OwnerじゃなくてProduct Managerと呼んでみることにする。深く自分に問いかけてないけど、単純にProduct Managerと呼んだ方が組織受けが良さげという理由かもしれない。
さて。Essential ScrumのProduct Ownerの章を読んでみる。
概要
まずは、組織内のステークホルダー、顧客、ユーザーが持つニーズや優先順位について、彼らの代理として行動できるくらい深く理解しなければならない。この意味では、プロダクトオーナーはプロダクトマネージャーとして行動し、正しいソリューションが開発されていることを保証するのである。
次に、開発チームに何をどの順番で構築するのかを伝えなければならない。それから、機能が完成しているかどうかを判断できるように、受け入れ条件を明確にして、その条件を満たすテストが実行されるようにしなければならない。プロダクトオーナーが詳細レベルのテストを書くことはないが、どうすればそのフィーチャーが完成したと言えるのかがチームにわかるように、抽象的なテストは書くようにする。つまり、プロダクトオーナーはビジネスアナリストであると同時に、テスターでもあるということだ。
- 経済的意思決定の管理
- 受け入れ条件の定義と検証
かな。まぁ、これを読んだだけでもハードな仕事だなーと思うのであった。
経済的意思決定の管理
スコープ・納期・予算・品質のトレードオフ。ROIとか。機能の優先順位とか。
意思決定力が必要だな。それとそれに対する責任。
誰かに決めてもらいたい人とか、100%大丈夫な橋じゃないと渡れない人だと辛いなー。からいなー。
受け入れ条件の定義と検証
最近、これ大切だなーってのが実感できてきた。今までチームのセンスに頼ってしまってたけど、プロセスに落としこんでヨコ展開するなら大切だなーと。ま、チームと協力して良い落とし所を見つけるすね。興味深いのが以下の点、完全に同意ですなー。
プロダクトオーナーによる受け入れ条件の検証は、スプリントレビューまで待たずに、スプリント実施のときに行うことが大切である。機能が実装された時点でテストを行えば、プロダクトオーナーはミスや誤解を指摘できるし、チームもスプリントレビュー前に修正できる。スプリントレビューでデモが許されているのは完成した機能だけである。したがって、チームがどの機能が「完成の定義」を満たしているかがわかるように、プロダクトオーナーはレビュー前に受け入れテストが実施されるようにしなければならない。
プロダクトオーナーチーム
いや、EssentialScrumから引用するんであれば、プロダクトオーナーと呼んだ方が楽だということにそろそろ気づいた。すまん。
最近考えるのは。１人でプロダクトオーナーとしての振る舞いをできる人であればいいんだけど。初めてやる人とか、まだ意思決定力が弱い人とか、経済性に関する視野がまだ広くない人とか、そういう人のことを考えたら、やっぱり同じ役割同士でチーム組むと良さそうだなーと思っている。相談相手的な。
ただ気をつけたいのは「意思決定は１人でやる」ってこと。相談したり、アドバイスをもらったりするのはいいけど、最終的な決定をするのは１人のPOだし、そこに責任を持つのもその人。がいいなと。
情報をオープンにして「僕はこういう風に考えてこんなビジョンやPBLを作ってるんだー」「お。この部分どうしてこの順番なの？」とか。「ちょい悩んでるんだけど、アドバイスくれー」とか。そういう場なのかな。
違うと思うのは「今の進捗はこんな感じですー」っての。これはProjectManagerがやれば良さげ。
すっきり
殴り書きしてすっきりした。次はProjectManager or ScrumMasterについて考えたいな。
