もちろん、このタイプの要求は、ユーザーが実際に何を望んでいるかについての手がかりもなく、特定のソフトウェアプロジェクトやソフトウェアを構築する技術的側面についての手掛かりもない一般的です。詳細はDilbert's Pointy-Haired Bossを参照してください。あなたのソフトウェアでばかげた機能の要求に対処するには？
ただし、これは1つの側面にすぎません。作成しているシステムの全体的なパフォーマンスが低下することがわかっているアイテムのリクエストはどうですか？あるいは、愚かに権威を与えられている技術的な馬鹿はどうですか？そして、彼らのほとんどすべてがドゥークに変わります。 （素晴らしい例については、this postを参照してください）
最終的には、最終的にプロジェクトを傷つけることになっている建物に、要望や勅令をどのように丁寧に扱っていますか？
デュープ：When the Client asks for something ludicrous and insists
優れたソフトウェア設計者は、奇妙な機能要求を呼び出すことを控えます。あなたは腸の感情を信じなければならないが、問題を慎重に検討したいという徴候に過ぎない。
私は単純なモデルを提案：
は、実際の問題は、ユーザーが求めているソリューションではありませんかを理解するようにしてください。黄金のデザインルール "Don't discuss solution with the client, discuss requirements"。
あなたの意見では、提案された機能の問題がどこにあるのかを説明することができます。 Paul Grahamは優れた作品 "How to Disagree"を持っています。
これらの2つの簡単な手順は、実際の問題の理解を深めさせるのに役立ちます。ソフトウェアはユーザーがいなくても無意味ですが、私たちの大部分はそれを支払っているユーザーに依存しています。侮辱的な態度で疎外させるのではなく、ユーザーと協力して作業してください。
いくつかの "ばかげた"機能要求は、非常にintrestingに根を持ち、問題を解決するのが難しいです。
あなたの優れた投稿+1！ – Hideo
常にお金にすべての要求を関連付けます。
に関連する新機能の開発を遅くするメンテナンス
変更要求の中には、開発者がフープを実行して終了させるだけのものがあり、最終的には、階段を上ることが良い機能であると思われる機能の保守が難しいコードになります。
私の経験ではこれをやめるために何もできませんし、最終的に管理者は開発がどれくらいの時間を費やしているか不満を募らせます。それはサイトの再構築やコード地獄で永遠に過ごすチーム。
幸運。
"馬鹿げさ"にはさまざまな種類があります。
私は:-)要件について議論したいと
編集：
典型的な議論
+1 "Rediculosity"という言葉に+1！驚くばかり！！！ – Boydski
それを行うために、顧客と技術的に可能である、とあなたがそれを行うことができれば、仕事の声明を得る - そしてそれを行います。
あなたが持っている仕事であれば、他のものと同じことをします。 「そうです、私はそれをして嬉しいです。私はそれをやっても構わないのですが、これが他のシステムにどのように影響するかを知りたいと思っただけです。あなたが間違っていると言っているのではなく、ちょっと考えなければならないかもしれません。
もし彼らがいいえと言うなら、まあ、彼らはそれで署名し、あなたはそれをする。あなたが本当に心配しているなら、あなたのアドバイスが耳を傾けなかったところであなたの会話を文書化してください。 文書化していないと、それは起こらなかったことを覚えておいてください。彼らが聴くならば、あなたは友人に勝つ。
これは、コンピュータ、建設作業者などどんな仕事でも同じです。
EDIT：
私は以下の私のコメントから、これを取った：
することは誰もがTNGやTOSもうスタートレックを見ませんか？ナンバーワンはピカード大尉に何か間違ったことを知らせ、時にはジャン=リュックは同意し、時にはそうではないと思います。それは私が言っていることのすべてです。
誰かがこれを控えめにしていて、理由を言うのに苦労しなかったのは残念です。これは面白い答えであり、質問の主観的な性質から、この回答は「役に立たない」とは言えません。 downvoteは実際にここでいくつかの説明が必要です。 –
私もそう思っていましたが、泣きたくありませんでした。私はウェブサイトが気に入っていますが、宗教的議論の価値はありません。私はそれは良い古い敬意が割り引かれていることが悲しいです。要求よりも道徳的な問題でなければ、プロジェクトよりも多くの人が関わっていると思うのですが、私は上司に思い出させてから、私が話したことをしています。誰が知っている...彼らは正しいかもしれない。 – johnny
-1ここにある理由：a）人々はそれのように振る舞いません。従順であることは軍隊にのみ役立ちます。もし誰かがあなたのように扱うことを期待すれば、彼らは解雇されるべきです。 b）建設労働者は、ソフトウェア開発者と比較して悪い。申し訳ありませんが、すべてのジョブが等しく作成されていません –
このような要求は、プロダクトマネージャーから寄せられることがあります。
パフォーマンス上の問題が発生する可能性があると説明し、上級者が勝ったことを確認しました。
次回は同様の懸念を提起しましたが、上級者は利用できませんでしたので、誰も本当に気にしなかったので、私は彼らが望んだことをやっただけです。私もそうしないことに決めました。
おそらく、複数基準のリクエストをデータベースに送信して結果を表示すると同時に、それらの基準のどれにヒットしたかを示すことなどを意味します。それを推測した？
あなたの武器はの推定である必要があります。ばかばかしい機能性は、通常、ばかげた見積もりを伴います。 に機能が必要な場合Xは3人年の見積もりを取得すると、魔法のように、になり、機能Xが得られます。
複数のリクエストがある場合は、優先順位をつけて書面でリクエストしてください。理想的には「サインオフ」などの手続きをしてください。あなたのマネージャー/顧客に、リクエストを見直して見積もりとそれがあなたのスケジュールに与える影響を元に戻すことを伝えます。これらのデータを作成するだけでX時間（または日）かかる必要があるため、他の作業が遅れる可能性があることを説明してください...
次に、リクエストがばかげていたら、
あなたのマネージャー/顧客が時間とお金を浪費したい場合、少なくともあなたはそれを明確にして、あなたがそれらを助けるためにできることをしたのです。
将来のフェーズまでこのような要求を延期するように依頼する必要がある場合は、次のバージョンでそれを見ることをお勧めします（他のいくつかの回答が既にこのアイデアを述べたと思います）。
これらはすべて良い答えです。ハード・データ（生成することが可能であれば）、「信じられないほどばかげた」見積もり、そして何よりも尊敬する必要があります。
ジョニーの答えは本質的に正しいとは言えませんが、正確な言葉ではありません（私は十分な担当者を作っていればコメントします）。しかし、場合によっては、これらの正確な単語を使用すると、リクエスターに異議の内容をもう一度見てもらうのに十分な不協和音が生じることがあります。はい、これはプロジェクトベースの取り組みに適用されます：ソフトウェア、広告デザイン、さらには（気になる！）構築。迫撃砲を運んでいる不快感は、欠陥のある設計に反対する根拠や影響力を持っているわけではありませんが、建設責任者は、彼の計画が構築不能であるかどうかを建築家に伝える義務があります。
その他すべてが失敗した場合は、議論&を作成してくださいとにかく文書化してください。もはやあなたの責任ではありません。
わかりやすい機能リクエストは、私には2つのキャンプに分かれています。予想通り
私はリクエストを分析し、厳しい事実や専門的意見で回答します。分析で、既存のコードに追加の努力を払って可能である可能性があることが示された場合は、
タイプ2の場合、最初に、要求者に機能を詳細に説明するように依頼します。ビジネスの領域で機能している可能性があります。元のアプリケーション仕様。私はまだそれを取得しないと、私は本当に機能の目的を見ることができない場合は、私はそれらを落胆するために高いと推定します。
彼らが推定を受け入れるか、私がしたら、ついにそれを得ます。
顧客は顧客であり、顧客がテーラーに入り4脚のズボンを尋ねると、テーラーはしばらく議論するかもしれませんが、最終的にはカスタム仕事であり、はるかに高価です。だから、彼らが支払う意思のある機能で十分な価値を見れば、彼らのお金を払う意思がある。あなたが値を見てもそれが間違っているとは限りませんからです。
なぜ機能がばかげているのか説明でき、機能が無効になることがあります。
時にはあなたに「ノー」と言ってもらうために、もっと上級者になることがあります。
あなた自身が「いいえ」と言ってもいいほど上級者（または有力者）であることがあります。
「はい」と言うこともできますが、タスクには低い優先度を与えます（決して実行しないでください）。
時々、あなたはそれを乗り越える必要があります。
後者の場合は、非常にうまくその作業を行う必要があります。どうして？あなたは輝き、あなたがそうするように、ばかげた者の影に焦点が当てられます。
私は、不可能なことを求める人々のほとんどが、なぜ彼らが求めているのがそのような問題であるか分からないことが分かっています。
まで一般的に、私はちょうど要件とより多くの細部のより多くの明確化を求める：電球が私の頭の中に来て
、私は彼らがしようとしていると私が言うことができるものを実現"ああ、あなたが本当に欲しいのはX、Yではない"。どちらの時点で、彼らは一般的に "ええ、それは私が全面的に言っていることです"と言うだろう。
は、彼らがされており、彼らはあなたが共同で、それは本当に良いだろうと実感が、それが不可能な要求
を撤回するか非現実的実現します。通常、私の経験では、大きなクローズドソースアプリケーションに変更を加える必要があるため、そのようなことが起こります。その場合、サプライヤに機能要求を行うだけです。技術者のための;ある小さな会社が彼らに尋ねたので、MicrosoftはExcelに変更を加えません！
お客様が作成した要件がこの問題の大きな原因となる可能性があります。問題は、顧客がソフトウェア開発者の仕事をしばしばやろうとしていることです。
彼らは問題を抱えていて、その問題を解決する機能を見つけ出します。残念なことに、これらの貧しい人々のいくつか（ほとんど）はソフトウェア設計にあまり良くないので、あなたはそれの最後に非常に興味深い機能を得ます。
これらの遅延機能の一部を削除するには、再帰的な.Why（）関数を使用するだけです。なぜあなたは自分の問題を見つけてから自分でそのフィーチャを設計するかを尋ね続けます。多くのシナリオでは、シンプルで安価で、すべての関係者を満足させる方法で再設計することができます。
また、ばかげた機能要求であると思われるものが、実際には良いものになることもあります。 ソフトウエア開発者（そして過去にこれをやっていることに気付いたことがあります）は、合理的に複雑ではあるが非常に有用な機能ではないと言っています。だから、あなたが "ばかげた"機能に遭遇したときには、直ちにそれを却下する前に、ビジネスへの潜在的価値を計算してください。
U Rawk JeeBee。 {-o} – Boydski
良い質問ですが、私は恐れています – annakata
投稿する前にかなり調べました。時には、他の人が同じ言葉でマッチを見つけることができない場合もあります。 – Boydski