製品所有者は初期プロトタイプを担当する必要がありますか？
プロダクトオーナー（またはBA）が要件ドキュメントに基づいてシステムの高レベルのプロトタイプ/ワイヤーフレームを作成し、要件がUXおよび開発チームのユーザーストーリーの作業を開始するのに十分なほど明確であることを確認するのは一般的ですか？
私は現在、開発者からUXデザイナーに「昇格」しており、要件ドキュメントから直接モックアップを作成する任務を負っていますが、ドキュメントはいくつかの点で不明確であり、これまでの私の時間のほとんどを、私がより多くのPOと見なすことに費やしてきました。/BA要件ドキュメントで基本的なことを明確にする作業。このプロセスは反復的であり、UX /開発チームはおそらく設計と開発中に項目を議論/明確化する必要があることを認識していますが、これが発生する前にPOが提供することが期待されるある種の「最低限実行可能な要件」段階があり、その方法これは決定されましたか？
明確にするために編集します。ここでのプロトタイプとは、コードの最初のリビジョン実装ではなく、Sketchなどで作成された高レベルの視覚補助を指します。さらに、私の例では、ユーザーストーリーは存在せず、未加工の不完全な要件ドキュメントのみが存在します。
私はノーと言うでしょう。 POはビジネス価値の定義に重点を置く必要があることを考慮します。 POがプロトタイプを作成することは、技術的な観点からチームの開発に影響を与えます。チームがそれを実装できるように、ビジネス価値が明確に定義されていることが重要だと思います。また、プロトタイプを作成することは、ビジネスバリューを実装する方法を理解するための学習体験です。チームがプロトタイピングを行わない機会を逃します。チームとPO間のインターフェースは、ユーザーストーリーと定義されたビジネス価値です。 POにプロトタイピングの種類を実行させることで、それを和らげます。
これは、POが以前は開発者であったように思えますが、私はその経験をしました。
スクラムマスターとして、POを開発すべきではないと私は信じています。ビジネスバリューの定義とバックログの維持に焦点を当てることは、チームとコミュニケーションをとるプロダクトオーナーの方法です。 （もちろん、口頭でも常に、アジャイルの原則を使用しています）
POは、チームが作業できるように、ストーリーが十分に明確で明確になっていることを確認するために必要なことを何でも行う必要があります。それが類似の製品のスクリーンショット、ワイヤーフレーム、ナプキンの背面に描かれた落書き、テキストの壁などを意味している場合は、そうです。
これは、製品/機能の複雑さと、チームの経験に大きく依存します。機能の外観/動作に関するPOのビジョンもこれに関係します。ユーザーが[はい]または[いいえ]の選択を入力する方法は数十通りの方法で実装できるため、POが特定のアイデアを念頭に置いている場合は、ワイヤーフレームまたはモックアップがその明確さを支援します。
そして、それはほぼ間違いなく反復プロセスになります（少なくとも開始するには）。ストーリーの最初の回覧はチームにとって完全に不明瞭な場合があるため、いくつかの詳細が追加または明確化されています。 2番目の処理はまだ少し不明確なので、POがモックアップを追加すると、チームがスコアリングして作業するのに十分なほど明確になります。
とにかく、最終的に重要なのは受け入れ基準です。モックアップとスクリーンショットは開発をガイドするのに役立ちますが、チームは、POが想定していたものとは異なるアプローチを使用して、受け入れ基準を満たす場合があります。
プロダクトオーナーは通常、ビジネスの側にいるため、おそらく任意のコードを任意の方法で作成することはできません。彼は期待するべきではありません。
彼にボード（またはVisioのようなもの）に線を引くように依頼することはできますが、技術的な作業をするように彼に頼むことは意味がありません。ただし、「紙のプロトタイプ」をボード上で一緒に開発し、理解したことを描いて、彼が意味するところや好みに応じて修正することもできます。
POがデザインを描画することはできません。
たとえば、CEOであり、会社のウィジェットを販売するWebサイトにそれをごまかしているとしましょう。それは小さな会社なので、私はプロジェクトのPOです。私が行くことができる2つの方法があります
高レベルのビジネス要件のみを指定し、専門家に詳細を記入してもらいます
- 要件A.このサイトにはあります。に。売る。ウィジェット！
- 要件B.ホスティングには年間100ポンドしか持てません。
ウィジェットの販売に適したサイトになると私が思うものを正確に指定してください
- 要件A.パート1セクションiii：サイトには、炎をアニメーション化したgif形式の会社ロゴが必要です。ユーザーの画面全体に表示する必要があります
- など...
方法1では、マーケティングとUIの担当者が、最も多くのウィジェットを販売することが証明されている驚くべき炎のようなgifアイデアを思い付くと信じています
方法2では、マーケティングやUIの担当者は必要ありません。どんなフレノフレミングGIFも最高で、開発者は1日の料金を請求しながら、私の仕様に正確に対応します。
それはいくつかの要因に依存します：
- どんな商品か
- UI
- 次のスプリントの要件は何ですか
- 関係者とそのスキル
これは間違いなく「はい」または「いいえ」の問題ではありません。
ユーザーインターフェイスには、多くの場合、技術的なデザインの側面だけでなく、多くのビジネスの側面もあります。そのため、UIにはWord interfaceが存在します。チームにビジネス要件を伝えるのはプロジェクトオーナーの役割であり、コミュニケーションは多くの場合例で最も効果的です、UIのスケッチまたは既存のUIを変更して新しい機能を追加するためのアイデア-利用可能なツールを使用することにより、POにとって貴重な手段となります。
POはすべての残酷な技術的詳細を解決することを期待されるべきではなく、彼/彼女はチームが彼/彼女の提案すべてを文字通り構築することを期待すべきではありません。理想的には、複雑なUI要件を設計するために、UXの専門家と「ユーザー」側の誰かが同じ部屋で話し合いを行う必要があります。特定の種類のソフトウェアでは、POは「代表的なユーザー」の役割を果たすことができます。
ただし、非常に機敏なチームでは、チームは特定の製品や環境に最適なコミュニケーションの方法を考え出す必要があります。 POにスケッチを任せれば、UIはチームで機能します。それが必要ではない、または口頭による説明よりも効率が悪いことが判明した場合は、後者を使用する必要があります。