最近、プロジェクトがあり、クライアントはツアーで忙しかった。通常のスクラムチームが結成されたため、経営陣はクライアントが積極的に参加できないため、アナリストをプロダクトオーナーとして任命することにしました。アナリストは、要件分析と仕様の草案作成のためにクライアントと密接に協力した人でした。
クライアントには、最初の2つのリリースをレビューする時間がありません。クライアントが3番目のリリースを見るまで、すべてが順調に進みました。彼はいくつかの機能に満足していませんでしたが、それらはmake shiftプロダクトオーナー（私たちのアナリスト）によって導入されました。
設計チームがすべてのページのモックアップを完了し、クライアントが各ページをチェックし、作業を継続することを承認するまで待つように言われました。スクラムチームは存在しますが、スプリントはありません。従来のウォーターフォール方式とほぼ同じように作業を終了しました。
スクラムチームメンバーまたはマスターをプロダクトオーナーとして任命するのは良い考えですか？クライアント/製品所有者の参加がない場合、スクラムに従う必要がありますか？
回答:
Mike Cohnがブログでスクラムマスターとプロダクトオーナーの役割を組み合わせることについて書いたのはほんの数週間前です。 私は彼よりも良いとは思いませんが、彼の投稿の私の短い要約はこれです：
スクラムチームのメンバーを連れてプロダクトオーナーに移動すること自体に問題はないと思います。しかし、それは昇進または内部移転のようなものであることを認識しなければなりません。チームに穴を開け、穴を埋める必要があります。おそらく、チームは「自己組織化」して穴を埋めることができます。空き地を埋めるために新しい従業員を雇う必要があるかもしれません。
あなたのプロセスは私には問題ないようです。詳細には説明しませんでしたが、少なくとも、役割は尊重されます（これは重要です）。
しかし、私が持っているいくつかの詳細では、製品所有者レベルでいくつかの問題を見ることができます。
顧客は、進捗状況を適切に通知する必要があります。彼は顧客と外部で「ウォーターフォール」を行い、あなたと内部で「スクラム」をしているように見えます。
結果：顧客は王様なので、滝が勝ちます。この場合でも、顧客には責任があります...
現在のチーム（スクラムマスターを含む）は、スプリントバックログの提供に集中する必要があります。ただし、製品所有者（アナリスト）は、バックログの内容が顧客の希望を反映していることを確認する必要があります。また、コミュニケーションが良好であり、顧客が参加することを確認する必要があります。
考えられる解決策：プロダクトオーナー（アナリスト）をスクラムプロダクトオーナーコースに送るか、彼/彼女にこの本を読んで（そして理解して）ください：Scrumによるアジャイルプロダクトマネジメント。
スクラムは、実際のクライアントが適切に配置されている場合に最適に機能します。反復的な製品設計に慣れていないクライアントに対処するには、いくつかの現実的な課題があります。
空白のシートを使用した設計段階では、すぐに空に飛び出しがちになり、通常、いくつかの側面の問題が深くなり、必要なコア機能の深さが不十分になります。設計会議を成功させるためにクライアントがばらばらに選ぶためには、本当にストローマンが必要です。一度に1つの側面のみに焦点を当てることにより、クライアントが反復設計を学習するのを支援します。
怖がっているクライアント（あなたが経験したように）は、アジャイルプロジェクトがプロセスの一部として一定の（制御された）量の再作業を予測していることに気づきません。彼らが把握するのに苦労しているのは、製品開発が進むにつれて、「Oh my god」の瞬間が少なくなることです。さらに重要なことは、ほとんどのクライアントが苦労しているのは、レビュー/計画サイクル間の時間が短いため、「ああ、なんてこと」の瞬間を修正するのに膨大なお金を必要としないことです。
クライアントの期待を管理することは非常に困難です。顧客教育、配置、そして「ノー」と言うことの学習の素晴らしいバランス。クライアントは毎週または隔週に来ることができません。時々彼らは月に一度だけ来ることができます。それで大丈夫です。前月に彼らの懸念に対処するために何をしたかを見せ、今月の仕事に集中すれば、プロジェクトをよりスムーズに進めるのに大いに役立ちます。一番下の行は、顧客が不在の場合、いくつかの質問に対して合理的な提案を行える人がいることです。クライアントが達成しようとしている目標に精通している必要があります。
投稿いただきありがとうございます。私はそれが古いことを知っていますが、あなたは素晴らしいケースを提起したと思います。ここに私の$ .02があります：
問題1：アナリストをPOとして任命すると、スクラムフレームワークが大幅に短絡します。どうして？なぜなら、POだけが価値判断、ROI評価、優先順位付け、そして決定的な選択を行うことができるのは、技術からではなく、製品に精通していてもからであるからです。私はあなたのsrを確信しています。アナリストはPOをまねた素晴らしい仕事をしましたが、最終的にはPOから生じる欲求、価値、選択肢を推測する必要がありました。参照http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/。アナリストがクライアントからPOAを許可されない限り（可能性は低い）、彼らはスプリントレビューで何かを受け入れたり拒否したりする立場にはありません。
このアプローチはおそらく機能しますか？はい。ただし、クライアントが外出中に責任を完全に移転する必要があります。クライアントの上司は代理に同意する必要があり、合理的な決定は取り消されません。聞こえそう？クライアントの組織から一時的なPOを取得する可能性が高くなります（確かにその欠点がないわけではありません！）。アナリストは一時的なPOで作業しましたが、ビジネスから間違った決定が行われるため、チームの役割をクリーンに保ちます。
問題2：「クライアントには確認する時間がありません」。大きな問題（そして最近私が遭遇した問題）。製品を受け入れるにはPOが必要です。誰も「小切手に署名」できません。POの不在は、後で不満が生じ、再作業が増える可能性があり、信頼が失われることを意味します。より基本的には、クライアントがあなたのプロジェクトに積極的に関与していないことを感じています：毎日立ち上がる時間がない、質問に答える時間がない、など
問題3：「設計チームがモックアップを完了するまで待つように言われた」。そして今、スクラムは完全にオフになっています。モックアップを行う人々は、職域を超えたチームの一員でなければなりません。これがスクラムの管理者の理解不足によるものなのか、3回目のリリースへのショック反応によるものなのかはわかりません。
質問：このすべてにおいて、スクラムマスターはどこにいましたか？SMは通常、対処すべき障害/危険の両方である、役割の対立とPOの参加不足の危険を認識します。