実装しない機能をユーザーから求められたらどうしますか？

ユーザーが実装できる複雑な機能を要求したときに何をしますか。ただし、1）他のユーザーに不必要な複雑さを追加するため2）オプションとして実行しないため設定パネルを複雑にしたくない。

私はiOSアプリを作成しましたが、上記の理由により実行できない複雑な機能を要求するユーザーが何人かいます。ほとんどの場合、私は彼らに「私たちはそれを考慮に入れます」と答えました。彼らがこの機能を望んでいる少数派であることを彼らに説明することも助けにならないでしょう。では、このような場合はどうしますか？

あなたは正しいことをしていると思います。みんなを喜ばせることはできませんし、そうすべきではありません。礼儀正しくプロフェッショナルでありながら、求められているすべてのことを行う必要はありません。

妥協する必要があります。ユーザー（アプリが存在する理由）は、ユーザーのニーズの1つを満たさないと言っています。

ユーザーのニーズに対処することと、エンドユーザーがアプリケーションを設計できるようにすることには違いがあります。ユーザーとミーティングをして、「なぜ」と多くのことを尋ねます。ユーザーが実行しようとしているタスクの核心にたどり着くまで、または現在のUIで実行するには面倒すぎるまで質問します。これらのメモを取り、一緒に使用できるいくつかの代替アプローチを模擬して、ユーザーに提示します。

何よりも、プログラマーとしての生活を楽にするためのアプリは存在しないことを忘れないでください。アプリはユーザーにサービスを提供するためにあります。

Seth Godinsブログ（http://sethgodin.typepad.com/）を読むと、同じメッセージが繰り返し表示されます。

1. 何かを出荷する（そしてフィードバックを聞く）
2. いつもすべての人を喜ばせないでください。

私が販売している製品で同様の問題がありました。私はあらゆる種類の機能に対するあらゆる種類のリクエストを受け取りました。アプリケーションは、私が本当に望んでいたよりも複雑になりました。すべてのオプションは複雑さを増し、私が避けたかったものです。そして今、私は思ったよりも複雑になっています。

これを行うと、より多くのユーザーを喜ばせます。また、設定が難しいと感じるユーザーを遠ざけます。

シンプルな/高度なセットアップは、束縛から抜け出す方法です。ある程度まで。ただし、開発がより複雑になります。

依頼があれば必ず丁寧に返事をします。まれですが、断る場合もあります。そして、これを行う場所を説明します。通常は、UI全体を修正する必要があるリクエストへの応答であり、非常に大規模な取り組みであるため、そこには行きません。その場合、私は私の理由を説明しますが、リクエストをユーザーに感謝します。

私がすぐに拒否したものも含め、すべての場合において、私はそれらを機能と欠陥のデータベースに記録し、次のリリースのために考慮します。これにより、すべてについて考える時間が少し増えます。おそらく後で、要求されたものとは異なるが、何らかの価値を追加する可能性のある代替案が考えられます。

機能リクエストが検討され、注釈が付けられ、最終的に（開発時に）削除する決定が下された場合は、それを閉じます。それ以外の場合は、後で再検討するために開いたままにします。

これは完璧なアプローチではありませんが、最終的にはソフトウェア作成者として、固執するか放棄する必要がある特定の設計原則があります。各アプローチの選択は慎重に検討する必要があります。

ユーザーに正直であるべきだと思います。「考慮に入れます」と言わないでください。それはユーザーが機能がいつか来ると信じて、そしてそれが決して来ないので失望するように導くでしょう。

長い目で見れば、それはあなたに最も利益をもたらすと私は信じています。

私は提案を彼らに感謝しますが、あなたの現在のロードマップには載っていないと言います。人々はほとんどあなたが限られた資源を持っていることを理解するでしょう。

このような状況にあるとき、私は通常3つのことを行います。

1. 結局のところ、ユーザーのアイデアが良いアイデアかもしれないかどうか、私は二度考えます。最初の本能を信用しないことを学びました。時々ユーザーは正しいです、そして私は間違っています。
2. その機能を含めることができない理由をユーザーに説明します。
3. 持っているソフトウェアで必要なものを実現する方法をユーザーに説明する

最後のポイントが最も重要だと思います。ほとんどのユーザーは、自分の提案を正確に実装することを望んでいません。彼らは問題の解決策を必要としているだけであり、考えられる最も簡単な解決策を提案しています。多分あなたはあなたが実装できるより良い解決策を見つけることができます。

当社の製品ごとに、「将来のバージョンのアイデアのリスト」があります。したがって、ユーザーに伝えることは、「あなたの提案をそのリストに載せます」ということです。そして、それは正直なところ、私たちは実際にそうします。

リストには優先順位はありませんが、定期的にリストから選択し、それらを使用してバックログにフィードします。私たちはそれらを「順番に」とらえるのではなく、代わりに、どのアイデアが「費用対効果」を与えるかを特定しようとします-合理的な開発努力のために、できるだけ多くのユーザーにとって最大の利益。

製品の概念的な整合性に対する機能要求は、そこに永久に残る可能性があります。しかし、たまに、それらの機能リクエストに埋め込まれているアイデアの少なくとも一部が実現している可能性があります。それは、提案した人が考えていた方法ではないかもしれませんが、製品のアーキテクチャによりよく適合しています。

したがって、ここでの私の提案は、「私たちはそれを考慮に入れます」と言うだけではありません。電話をかけるとすぐにアイデアを忘れてしまいます。代わりに、アイデアや機能のリクエストを、おそらく問題追跡、Wiki、スプレッドシートなど、ニーズに最も適したものを保存するツールを用意してください。