私たちの主な製品には、数年前から存在している機能要求があり、それはかなりの回数要求されています。実装は技術的に簡単です。問題は、ツールの機能の概念が根本的に変更され、人々が新しい機能を新しい概念と一致させるために誤用するため、バグレポートが増える可能性があることです（これはできません）。回避するために）。この問題をうまく回避する別の機能がありますが、それでも新しい機能を実装するように要求されます。
我々がすべき
プラグインとして実装します。
この機能が製品の哲学に反する場合は、製品がユーザーのメンタルモデルに準拠していないことを示しています。その結果は、1つの欠落している機能よりもはるかに大きくなります。ユーザーの頭の中に入って、モデルをユーザーの期待に合わせる方法を理解するか、ユーザーの期待をモデルに導く必要があります。
これに十分な考えを入れてください、そしてそれはあなたにとって素晴らしい機会になるかもしれません。
「TheMythicalManMonth」（あなたが読んだことはありませんか？）で、ブルックスは「アーキテクチャの概念的な完全性が最も重要なこと」という趣旨の言葉を述べています。つまり、要求された機能が製品の全体的な設計の概念的な整合性を損なう場合は、要求された量に関係なく、おそらくそれを実装することを避け続ける必要があります。または、要求された機能が改訂されたアーキテクチャに適合するように、アーキテクチャを再形成する必要があります。
私が取り組んでいる製品の1つに、「非常に要望の多かった機能」が追加されました。製品の他の機能とは異なり、動作します。恐ろしいいぼです。しかし、競争がそれをするので、私たちはそれをしなければなりませんでした。しかし、私たちのアーキテクチャ（この分野の競合他社とは根本的に異なる）を忠実に保つ代わりに、競合他社の機能をばかげた詳細に落とし込みました。
私はまだ、機能が製品の残りの部分で壊れたセマンティクスでシステムに組み込まれているという事実にひどく憤慨しています。傷口に塩をこすりつけるために、私は新しい機能を「スライスされたパン以来の最高のもの」として顧客ベースに提示しなければなりませんでした-それは本当に痛いです。
そうは言っても、この機能について（私が思うに）誰も文句を言っていません。たまに使われることもあるでしょう。競合他社が私たちに対して使用できる違いは1つ少なくなります。
（注：私は、製品の通常の動作方法と一致するスタイルで実装されている機能に反対していませんでした。競合他社が使用しているスタイルで実装されていることに反対しました。他の関連機能は、壊れた実装と同様に機能するためです。彼らのシステムでは、私たちのシステムはより正気で友好的です。）
硬いです。時々市場が勝ちます。
あなたが何について話しているのか正確にはわからないので、これに答えることはほとんど不可能です。
いくつかのポイントを言った：
これはあなたの顧客を幸せにするので、私はそれを実装する傾向があります。
オプションは、両方の方法に誘導するメニューオプションを提供することです。
おそらく、ある種のウィザードで、使用する回避策を決定するのに役立ちます。
ユーザーにとってより簡単でわかりやすいように、回避策のUIを再設計しようと思います。一日の終わりに、顧客が請求書を支払うので、私たちは彼らのニーズを満たす義務があります。彼らが求めるものがより多くの問題を引き起こすとき、私たちが将来のバグを作成しないように別の解決策を提供することが私たちに戻ってきます、そして私たちはまだ顧客を幸せに保ちます。
プログラミングの問題ではありませんが、私は何年にもわたってこの種の問題に苦しんでいる人をかなり多く見ました。
あなたは自分自身にいくつかの質問をする必要があります
1）あなたまたは経営陣は費用便益分析を行いましたか？「機能はどうなりますか」と自問してください。
2）製品が大幅に変更される場合、まったく新しいSKUにスピンオフするのは理にかなっていますか？
3）経営陣は最終的に彼らが望むものを手に入れるでしょう。彼らと協力して、顧客に可能な限り最高の体験を提供し、ヒーローになることを望みますか、それとも彼らに反対して他の機会を探しますか。
少なくとも重要な要素として、コスト（使いやすさの観点から）とメリットを簡単に推測します。たとえば、この機能がユーザーの45％に役立つ可能性が高いが、他の55％はプログラムを使いにくくする場合は、それを行わないでください。
「ユーザー」を定義します。ユーザーベースの5％、80％、95％ですか？これがユーザーの大多数が望んでいるものなのか、それとも単なる不正なユーザーグループなのかを知るために十分に調査しましたか（彼らは最も困難で満足するのが難しい場合があります）。
それを最初に確立する必要があると思います。それがユーザーベースの大部分であり、それが彼らの目に付加価値をもたらす場合、私はあなたが真ん中で出会う妥協点に到達しようとします。あなたの製品の完全性を損なうことはありませんが、それでも顧客に代替ソリューションを提供します。彼らのニーズを満たす。
リクエストの解決策として回避策をリクエストした人に発表します。UIで回避策をより目立たせ、使いやすくします。
ROIの可能性が高いものなら何でも使用します。この機能を実装することで利益を増やしますか？もしそうなら、それは新機能をサポートするコストを超えていますか？潜在的な利益がサポートコストよりも大きい場合は、この機能を使用することをお勧めします。
財政的に、または支援のためのコストを下げることによって得られる利益がない場合、それを行うことは意味がありません。