読者です 読者をやめる 読者になる 読者になる

Product Managerについて考える

Team

Roleについて考えてみようと思ったので考えてみる。今日はProduct Manager。Product OwnerじゃなくてProduct Managerと呼んでみることにする。深く自分に問いかけてないけど、単純にProduct Managerと呼んだ方が組織受けが良さげという理由かもしれない。

さて。Essential ScrumのProduct Ownerの章を読んでみる。

概要

まずは、組織内のステークホルダー、顧客、ユーザーが持つニーズや優先順位について、彼らの代理として行動できるくらい深く理解しなければならない。この意味では、プロダクトオーナーはプロダクトマネージャーとして行動し、正しいソリューションが開発されていることを保証するのである。

次に、開発チームに何をどの順番で構築するのかを伝えなければならない。それから、機能が完成しているかどうかを判断できるように、受け入れ条件を明確にして、その条件を満たすテストが実行されるようにしなければならない。プロダクトオーナーが詳細レベルのテストを書くことはないが、どうすればそのフィーチャーが完成したと言えるのかがチームにわかるように、抽象的なテストは書くようにする。つまり、プロダクトオーナーはビジネスアナリストであると同時に、テスターでもあるということだ。

  • 経済的意思決定の管理
  • 受け入れ条件の定義と検証

かな。まぁ、これを読んだだけでもハードな仕事だなーと思うのであった。

経済的意思決定の管理

スコープ・納期・予算・品質のトレードオフ。ROIとか。機能の優先順位とか。
意思決定力が必要だな。それとそれに対する責任。
誰かに決めてもらいたい人とか、100%大丈夫な橋じゃないと渡れない人だと辛いなー。からいなー。

受け入れ条件の定義と検証

最近、これ大切だなーってのが実感できてきた。今までチームのセンスに頼ってしまってたけど、プロセスに落としこんでヨコ展開するなら大切だなーと。ま、チームと協力して良い落とし所を見つけるすね。興味深いのが以下の点、完全に同意ですなー。

プロダクトオーナーによる受け入れ条件の検証は、スプリントレビューまで待たずに、スプリント実施のときに行うことが大切である。機能が実装された時点でテストを行えば、プロダクトオーナーはミスや誤解を指摘できるし、チームもスプリントレビュー前に修正できる。スプリントレビューでデモが許されているのは完成した機能だけである。したがって、チームがどの機能が「完成の定義」を満たしているかがわかるように、プロダクトオーナーはレビュー前に受け入れテストが実施されるようにしなければならない。

スキル

ってことでProductManagerとして必要なのは

ってことですね。納得。

プロダクトオーナーチーム

いや、EssentialScrumから引用するんであれば、プロダクトオーナーと呼んだ方が楽だということにそろそろ気づいた。すまん。

最近考えるのは。1人でプロダクトオーナーとしての振る舞いをできる人であればいいんだけど。初めてやる人とか、まだ意思決定力が弱い人とか、経済性に関する視野がまだ広くない人とか、そういう人のことを考えたら、やっぱり同じ役割同士でチーム組むと良さそうだなーと思っている。相談相手的な。

ただ気をつけたいのは「意思決定は1人でやる」ってこと。相談したり、アドバイスをもらったりするのはいいけど、最終的な決定をするのは1人のPOだし、そこに責任を持つのもその人。がいいなと。

情報をオープンにして「僕はこういう風に考えてこんなビジョンやPBLを作ってるんだー」「お。この部分どうしてこの順番なの?」とか。「ちょい悩んでるんだけど、アドバイスくれー」とか。そういう場なのかな。

違うと思うのは「今の進捗はこんな感じですー」っての。これはProjectManagerがやれば良さげ。

すっきり

殴り書きしてすっきりした。次はProjectManager or ScrumMasterについて考えたいな。