プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。
プロダクトオーナーがやる仕事は結構あります。
- ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む
- なるべくROIを高められるようにプロダクトバックログを優先順位付けする。
- 直近の数スプリント分は準備完了(チームが着手可能)にする
- チームと定期的に話し合ってバックログを見直す(リファインメント)
- すべてのステークホルダーと話す
- 予算を取る
- バックログの内容についてチームからの質問を受けつけ、明確化する
- チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする
- 受け入れた成果物をリリースすべきときにリリースする
プロダクトオーナーは一人、もしくは複数人でやる場合にもチーフを置き、最終決定責任を明確にします。
で、これって顧客側でカバーできるんでしょうか?日本でウォーターフォールが多いのは、顧客側が曖昧な要件と厳しい予算/納期を要求し、それを受注側がカバーする構造のために、事前に受注側で様々なリスクヘッジが発生することに起因する気がしています。顧客側が十分な要件や仕様を提示するケースは極めて少ないのではないでしょうか。
「スクラムがうまく行かないのはお客さん(PO)が仕様をくれないから」だとすると、デスマーチになるウォーターフォールとだいたい同じような問題を抱えてしまうように思います。
組織を跨ぐのがベストではないとしても、なにかうまくやる方法はないのでしょうか?
共犯者モデル
一つの考え方は、共犯者モデルと呼んでいるものです。顧客側と開発側にプロダクトオーナーを置いて、緊密に連携する。お互いに背中を預けて、説明していく。会社を跨いでしまうとそこ(会社間)で交渉してしまいがちなんだけど、それは全体の価値を考えればムダ。POはあらゆるステークホルダーと話す必要があるので、ペア/チームを組んで360°をカバーします。
顧客側がカバーしやすいこと
- ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む
- なるべくROIを高められるようにプロダクトバックログを優先順位付けする。
- すべてのステークホルダーと話す
- 予算を取る
- チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする。
- 受け入れた成果物をリリースすべきときにリリースする
受注側がカバーしやすいこと
- 直近の数スプリント分は準備完了(チームが着手可能)にする
- すべてのステークホルダーと話す
- チームと定期的に話し合ってバックログを見直す(リファインメント)
- バックログの内容についてチームからの質問を受けつけ、明確化する
もちろんこれは協調してカバーしましょうというだけの話です。役割分担ではありません。開発チームが最も高いROIを利用者に届けられるように、ベストをつくします。
以上、2009年くらいに思いついた話でした。
信頼に基づく
共犯者が裏切ったら終わり、というところですので、信頼が大事です。
@goking 2人の認識がずれたり、片方が「お客様」になってしまったりするとうまくいかなくて。2人で世界を変えてやろう、くらいの目的と共感が、うまくいくケースには存在しているのではないかという仮説です。
— Yasunobu Kawaguchi (@kawaguti) May 18, 2010
このエントリもRSGT2020のアドベントカレンダーに向けて投稿してみます。