私のPMはユーザーストーリーのリストを持っています。基本的に、これらのユーザーストーリーがそれらをサポートする証拠を持っているかどうか、つまり「真」であるかどうかを確認したいと思います。
すでに使用状況データを取得しています。また、カスタマーサポートチームに連絡して、カスタマーサポートコールからカスタマーサポートチケット/メモを調べます(実際に、お客様が新機能の必要性を表明しているかどうかを確認します)。
ユーザーストーリーを検証(または反駁)するためにインタビューを使用したことがありますか?もしそうなら、主要な質問をせずにどのように良い面接を実施しましたか? (さらに悪いことに、非常に役に立たない「この機能を使用しますか?」)
ユーザーストーリーを調査する他の定性的な方法は?
アイデア?
プロジェクトマネージャーとプロダクトオーナーが事前にユーザーストーリーのリストを持っていることは非常に一般的です。ユーザーストーリーは、製品開発の方向性を決定するために使用されます。これらの先入観のあるストーリーはassumptionsです。
あなたの仕事はこれらの仮定を検証することです。
最初のステップとして、顧客フィードバックデータを提供できるサポートチームがいることを知っておくと役に立ちます。しかし、あなたは少し注意する必要があります-なぜなら
ただし、独自のユーザー調査を実施する方がより有用で実りあるものになる場合があります。研究を行うために使用できるいくつかの方法がありますが、それはあなたが利用できる時間/予算に依存します-
無向インタビュー-機能に固有の質問を直接尋ねたくない場合に適しています。これは、仮定をテストしたい場合に役立ちます。たとえば、「この機能を使用しますか?」と尋ねる代わりに、「1日の過ごし方について少し話せますか?」。主な目的は、ユーザーの行動、習慣、期待、環境、文化的背景などを理解することです。これらはすべて、ユーザーのニーズを理解するのに役立ちます。面接は知識をテストするためではなく、製品の改善に役立つことを参加者に明確に伝えます。
広く分散した調査-これは、時間が少なく、非常に大規模なユーザーベースで、想定を迅速に検証する必要がある場合に役立ちます。質問を具体的なものと具体的でないものに混ぜて、多くのユーザーからすばやく洞察を得ることができます。ただし、インタビューが提供する人間的なタッチを見落とす可能性があります。また、ユーザーのニーズをさらに理解する必要がある場合にフォローアップすることは困難です。
時間に制約のある環境では、ユーザーから十分な情報が得られる限り、両方を少しずつ行うことになりますが、それでも問題ありません。
このアプローチは少し逆のようで、間違いなく首相から指示されています。一般的に、リサーチを使用して、どのようなユーザーストーリーが存在するかを発見します。この場合、私は調査をふるいにかけて、どのようなユーザーストーリーがあり、その頻度を見つけます。その後、かなり簡潔で便利なリストが作成されます。次に、実際のストーリーリストとPMが示唆する内容)を照合します。
これは、調査をスキャンしてそれらが存在するかどうかを確認するだけの場合よりも優れたアプローチです。これは、PMのユーザーストーリーが実際には存在しないことがわかった場合に、実際に存在するもののリストがあるためです。確かに一致があり、頻度もマークしているので、PMに話していないことをユーザーに通知するだけでなく、ユーザーの間でより一般的であると伝えることもできます。知っている。
このモデルは非常に効果的であることがわかりました。
PMが実際には存在しない問題を解決するための要件を提供する場合は、兆候が表示されます。ユーザーのテスト中に、ユーザーは「それは私が必要とするものではない」、または「かっこいいけど...」
これらの「誤った」問題の設計を回避するために、私はまず以下に焦点を合わせます。
ユーザーが実際に達成しようとしている仕事が私が解決している問題と一致しない場合、私は首相に明快さを求めます。
最後に、あなたのPMが問題の解決策を提供している場合、彼は彼の仕事の範囲外である可能性があります。この問題を解決することは難しいかもしれませんが、それは可能です。