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