顧客はプロジェクトのスクラムプロダクトオーナーになれますか？
プロダクトオーナーの役割について同僚と話し合ったところです。顧客の組織がソフトウェア開発組織（サプライヤー）を招いたプロジェクトで、プロダクトオーナーの役割を顧客の組織が成功させることはできますか。サプライヤーによって開催されますか？
私はいつも、POはサプライヤー組織の男だと想像していました。顧客が満足していることを保証し、ビジネス価値の高い新しい機能を継続的に提供しているが、依然として開発者組織の不可欠な部分です。ただし、POの役割をウォーターフォールプロジェクトマネージャーのように考えすぎた可能性があります。
私の同僚は私に考えさせました：顧客の組織が十分に成熟していて専門的であるなら、キャンプの人にバックログを優先させてはどうですか？これにより、POの役割がビジネスにはるかに近くなり、（理論的には）バックログ項目のビジネス価値を評価するのに優れたものになります。私にとって、それは興味深い考えです。しかし、そのような設定の意味は何ですか???
ご意見をお待ちしております。
@Thomas Owensが説明しているのは、POの一般的な説明です。私はそれをナイス理論として同意しますが、実践は私の経験ではしばしば遠く離れています。どうして？なぜなら：
- 意欲的な参加者-少なくともプロジェクトの期間中、POはフルタイムの仕事です。これは、ほとんどの顧客にとって深刻な問題になる可能性があります。 5〜7人のメンバーのチームと連携する場合、POは現在チームが開発しているユーザーストーリーについて話し合うことで半日（ユーザーストーリーは将来のコミュニケーションの約束に過ぎないことを忘れないでください）、ユーザーストーリーを定義するために製品のバックログを維持および調整することで半日を費やすことができます。今後のスプリント用。また、私見POは、スプリント中に完成したユーザーストーリーを「完了」し、これらの完成した機能を顧客や関係者（POではなく）に提示するレビュー会議の準備をするために必要な手順として検証する必要もあります。
- さらに、POは実際の職位と見なすことができます（スクラムマスターと同じように）。このような場合、99％の顧客で優れたスキルのPOを期待することはできません。
- 財政的責任-POはプロジェクトに対して財政的責任を負います。スクラムでさえ誰かに責任があり、通常は製品マネージャーやプロジェクトマネージャーがいないため、通常はPOに対して責任があります。財務上の責任とは、プロジェクトの成功、顧客のニーズ、期待、要件の正しい実装と理解に対する責任を意味します。これは、顧客側のPOにとって理想的な状況のように見えますが、デリバリー組織は、プロジェクトに関与して経済的責任を負う誰かも必要とします。
スクラムは標準化されたアプローチではありません-それは多くのバリエーションを持つ単なる青写真です。そのため、POが顧客側から、またはPOが配送組織からのものであるプロジェクトを見つけることができます。顧客側からPOを受け取ったら、彼が本当に仕事をしていることを確認してください。私は公式のPOが顧客側である状況を見てきましたが、結局それは配達組織からの管理の期待を満たすための空のタイトルであり、彼の仕事のほとんどは彼の代理を密かに演じたチームメンバーによって実行されました。スプリントの結果は顧客のビジネスニーズに対するプロキシの理解に依存することが多かったため、それは明らかに悪いことでした。
顧客との私の経験（これはローカルのみである可能性があります）から、顧客が自分のPOを実際に要求すると、それは彼ら自身がプロジェクトを主導することを意味します-彼らはプロジェクトを主導するデリバリー組織を探しません。彼らは、開発者を販売できる組織を探しています。実装を提供するのではなく、労働力を提供します。
可能な限り、プロダクトオーナーをお客様の代表者にすることをお勧めします。 POの役割は、お客様の声であり、チームが生み出しているものがビジネス価値を確実に追加し、ユーザーストーリーを作成して優先順位を付けることです。顧客の組織の意欲的な参加者よりも、これらの役割を実行するのに優れているのは誰ですか？キーワードは意欲的な参加者です。チームが使用するプロセス方法論である場合、スクラム環境に意欲的で参加できる必要があります。
これもスクラムに固有のものではありません。顧客担当者の概念（オンサイト担当者が好むことが多い）も、Extreme Programmingの一部です。
優れた製品オーナーは、いくつかの基本的な質問に答える必要があります。
- 計画とレビューを行うのに十分なチームが利用できますか？
- 次のリリースとスプリントの準備に常に取り組むことができますか？
- 実装された機能を十分に速く承認できますか？理想的には、機能がすぐに完了することを意味します。
私の経験では、あなたのチームメンバーである製品所有者がいる方が良いです。
- 開発者の発言だけでなく、顧客のニーズも理解できる人が必要です。
- プロダクトオーナーはあなたの経理、販売などと協力するべきです。
- 開発者は、製品の所有者が「同じボート」にいることを見て、感じる必要があります
- 時々、あなたは彼の心を開くために顧客にNOと言わなければならないでしょう。
顧客がPOになることを許可することについて考慮するいくつかの事柄：
それらが完全にコミットされていない場合は、開発プロセス全体が行き詰まって停止することがあります。大多数の顧客はこの種の関与を望んでいないと考える人もいますが、実際にはそうした関与を望まない人もいます。
あなたはあなたのコントロール下にあるプロセスを取り、そのコントロールを顧客に与えます。 notクライアントのプロジェクトを100％制御することは、クライアントが求めているものを正確に提供しないリスクよりも危険であるというのが私の経験です。 OTOH要件の不在が発生した場合、この要件の不在に対する責任は完全に顧客にあり、彼らはあなたに責任を負わせることはできません。
あなたやあなたの組織が好転したり、他の顧客に転用したり、他の顧客に販売したりする権利や権利を持っていない製品を開発しているなら、これはうまくいくかもしれません。それ以外の場合、将来的に他の顧客に合わせてカスタマイズおよび調整したい自社向けの製品を開発している場合は、将来自分自身に大災害をもたらす可能性があります。この場合のPOは、複数の顧客に再利用することを目的とした製品を開発しているため、社内の誰かである必要があります。