どのようにしてユーザーにソフトウェア拡張のニーズをランク付けさせるのですか？
私はレガシーソフトウェアシステムを継承しており、ユーザビリティとシステムアップグレードの実行を任されています。システムには何も悪いことはありませんが、ユーザーとの話し合いから、対処する必要がある「小さな」ユーザビリティの問題があります。
この段階では、私はこのシステムの唯一の開発者であり、テストを除いて、システムをまったく使用していません。そのため、どのような問題が存在するのか、または存在すると思われるのかを知るのは困難です。私はそれらすべてと話をして、彼らがシステムについて良い/悪いまたは無関心であると思うものについて話し合う時間を持ちます。
とりあえず私はとりあえず私だけの時間なので限界です。だから私は彼らに私ができるのは1つの変更しかできないことを想像してもらい、1つの変更にしたいものをすべて非公開で書いてもらい、それらをランク付けするのを手伝うことを彼らに頼むことを考えていましたが、他のことを望んでいますヒントも。
ユーザーに自分の欲求、ニーズ、要件を説明してもらいながら、重要度または望ましさでランク付けさせるためのテクニックは何ですか？
最近、私は会社がレポートに関連する問題に対して3つの個別のプロトタイプソリューションを作成し、上司に提示する「喜び」を感じました。開発時間、パフォーマンス、スケーラビリティー（プロジェクトの開始からレポートの作成を開始できるまでの時間）、クライアントがこれらのレポートを変更する機能などに関して、それぞれに長所と短所があります。
私の上司はこの性質の決定を下すことができないことで有名であるため、私は不思議なことを期待していませんでした。そこで、各プロトタイプの長所と短所を説明した後、どのプロトタイプが必要かを尋ねました。彼らは未定でした（驚き！）。私の上司は、どちらが良いかについての私たちからの提案なしに決定にコミットするつもりはありませんでした（別名、あなたが決定し、それが失敗した場合、あなたに固定されます）。
そこで、私は別のアプローチを取ることにしました。これらの優先順位のどれがより重要であるか（開発時間、パフォーマンス、スケーラビリティなど）を尋ねました。繰り返しになりますが、これらの優先事項はすべて重要であると言うことで、彼らはどういうわけか私の質問のポイントを回避することができました。
最後に、最終的に機能したのは、優先順位を選択できないことをうまくやろうとする私の試みで採用した戦略でした。 X軸に優先度を、Y軸にプロトタイプを記載した表を作成しました。優先度とプロトタイプごとに、その点での「理想」の度合いに基づいて、1から10までの数値を与えました。10が明らかに最高です（特定の側面で10を最悪にしないでください。後で混乱する）。
これを入手したら、1つのプロトタイプの強度を選択し、別のプロトタイプの強度と対比させます。つまり、言い換えると、「どちらがより重要か？開発時間とパフォーマンスのどちらが重要か」という質問を形成し始めます。 「どちらがより重要ですか？パフォーマンスまたはスケーラビリティ？」
この時点で、これらの質問を実際に伸ばして、視点の考え方を理解させます。「どちらがより重要か。6か月で終了するか、クライアントがレポートの半分の時間待つ必要があるか？」 「どちらがより重要ですか？クライアントはレポートを半分待つ必要がありますか、それとも週末にレポートの作成を開始できますか？」
この時点で、私の上司は一口サイズのピースで決定を下すことができ、この情報に基づいてどのプロトタイプが好まれるのかを適切に示すことができます。
逆も同様に機能し、弱点と弱点を比較します。「どちらが悪いですか？終了までに6か月以上かかるか、クライアントがレポートの作成にかかる時間について不満を言うのですか？」
あなたの場合、優先度ではなく機能について話していますが、ここでも同じことが当てはまると思います。 「どちらを選びますか？iPhoneで利用できるようにするか、パフォーマンスを向上させますか？」それぞれの質問に答えるのは簡単で、どの機能がより重要であるかについての洞察を与えることができます。あなたのケースでは、このように選択された各フィーチャに1つのポイントを割り当てて、あるフィーチャを別のフィーチャに対して効果的に測定できるようにします。
あなたはアジャイル/スクラムのアプローチを試すかもしれません：すべての既知の作業（バグ、拡張機能、新機能など）のリストを作成してから、常に最優先で作業することを関係者（ユーザー、ボス、または誰でも）に伝えます-完了するまで、リストのほとんどの項目。彼らが好きなだけ注文できるようにします（そして注文し直します）。
それらを注文する方法は、プロジェクト管理とエンドユーザーの束があるかどうかによって異なります。他に何もない場合、それらを注文するために問題に「投票」することができます。
ただし、依存関係を明確にする必要があります。つまり、Bが必要でAを気にしない場合でも、Bを発行する前にAを実行する必要があります。
このようなことを支援するソフトウェアソリューションは、課題追跡（Trac、JIRA、Rallyなど）のように多数あります。
プログラマーは、ユーザーが次のようなアプローチを取ることを想像します。私が望む機能の長いリストがあり、私たちの唯一のプログラマーは限られた時間を持っているので、要件を苦労して注文することによって開発時間を最大化することを確認する必要があります最も重要なものが最初に完了することを確認してください。
これが事実なら、彼らは出てあなたに言うでしょう。ある機能を別の機能よりランダムに選択すると、誰かが戻ってそれについて不満を言うのではないかと心配しています。それが起こる可能性があるので、何ですか。彼らの意見を取り入れ、適切と思われるものに優先順位を付けることについては、ただオープンにしてください。彼らはあなたに知らせる必要があるだけです。
おそらく、彼らは物事をグループに分類します：高、中、低/優先度なし。会議の前に全員に要件のリストを渡して、何が重要かを示すことができるかどうかを確認してくださいINDIVIDUALY！結果を集計して、会議で共有できます。会議をG8サミットに変えないでください。誰かがテキストボックスのラベルについて継続していきます。
優先順位は変更される可能性があるので、会議ではあまり優先しないでください。また、あなたはアプリの一般的なユーザーではないので、できるだけ早く誰かに使ってもらい、観察してもらいます。
これがどこで発生したのかはわかりませんが、顧客が複数のバグ/拡張リクエストを持っている場合は、100ドル（または同等の通貨）を持っていることを伝えます。彼らはどのようにそれを過ごしたいですか？ 1つの問題に向けたすべてですか？ 2つに分けても？これは、すべてが優先度が高いという通常の応答をブロックするのに役立ち、各問題に重みを与えます。