もちろん、ほとんどの場合、この種の要求は、ユーザーが本当に望んでいるものについての手がかりも、特定のソフトウェア プロジェクトまたはソフトウェア全般を構築する技術的側面についての手がかりもない経営陣からのものです。詳細については、ディルバートのとんがり髪のボスを参照してください。
ただし、それは 1 つの側面にすぎません。構築しているシステムの全体的なパフォーマンスに悪影響を与えることがわかっている項目の要求についてはどうでしょうか? あるいは、ばかげて権限を与えられたにもかかわらず、彼らが行うことのほとんどすべてが失敗に終わっている技術的な愚か者はどうですか? （素晴らしい例については、この投稿を参照してください）
最終的に、最終的にプロジェクトに損害を与えることがわかっている構築中のものに対する要求や命令に、どのように雄弁に、専門的に、そして穏やかに対処しますか?
Dupe :クライアントがばかげたことを要求し、主張するとき
どんな要求も常にお金に関連付けてください。これらの要求を思いついた人々は通常、お金のことをより心配しているため、次の理由により、より多くの費用がかかることを認識しておいてください。
「フェーズ2でそれをやろうか」というフレーズを見つけました。おそらく、「最初はそれがなくても管理できると思います-最初に何かをドアから出しましょう」でバックアップされます。
選択する武器は見積もりである必要があります。ばかげた機能は、通常、ばかげた見積もりが付属しています。フィーチャーXが3人年の見積もりを取得する必要がある場合、それは魔法のようになり、フィーチャーXがあると便利です。
時間をかけて丁寧に耳を傾けます。複数のリクエストがある場合は、優先順位を付けて、書面でリクエストを受け取るように依頼します。理想的には、「サインオフ」またはその他の手順を実行します。次に、上司/顧客に、リクエストを確認し、見積もりとそれがスケジュールに与える影響を返信することを伝えます。これらのデータを生成するためだけにX時間（または日）かかる必要があるため、他の作業が遅れることを説明します...
次に、見積もりを返します-リクエストがばかげていた場合、見積もりはそれを反映している可能性があります:-)
あなたのマネージャー/顧客が先に進み、多くの時間とお金を浪費したいのであれば、少なくともあなたはそれを前もって明確にし、あなたは彼らを助けるためにあなたができることをしました。
可能であれば、そのような要求を将来のフェーズまで延期するように依頼する必要があります。次のバージョンでそれを確認することをお勧めします（他のいくつかの回答でこのアイデアについてはすでに言及されていると思います）。
それが顧客であり、技術的に可能であり、あなたがそれを実行できる場合は、作業明細書を入手して実行してください。
それがあなたが持っている仕事であれば、あなたは他のものと同じことをします。あなたは、「はい、サー（または奥様）、私は喜んでそうします。私はそれをすることをまったく気にしません。これが私たちの他のシステムにどのように影響するか、または予算です。あなたが間違っていると言っているのではなく、少し考えたほうがいいのではないかと言っているだけです。よろしいですか？」
彼らがノーと言ったら、まあ、彼らはそれを承認し、あなたはそれをします。本当に心配なら、あなたのアドバイスが聞き入れられなかった会話を記録してください。 文書化しなければ、それは起こらなかったことを忘れないでください。 彼らが耳を傾けるなら、あなたは友達を獲得します。
これは、コンピューター、建設作業員など、どのような仕事でも同じです。
編集：
私は以下の私のコメントからこれを取りました：
スター・トレックの TNG や TOS を見ている人はもういないのですか? ナンバーワンはピカード艦長に何か悪いことを知らせ、ジャン=リュックが同意することもあれば、同意しないこともあるということを覚えておいてください. 私が言っているのはそれだけです
優れたソフトウェア設計者は、機能要求をばかげたものと呼ぶことを控えます。あなたは自分の腸の感覚を信頼しなければなりませんが、それはあなたが問題を注意深く検討したいという良い兆候です。
簡単なモデルを提案します。
ユーザーが求めている解決策ではなく、実際の問題が何であるかを理解するようにしてください。黄金の設計ルール「クライアントとソリューションについて話し合うのではなく、要件について話し合う」。
提案された機能の問題がどこにあるかをあなたの意見で説明できるようにしてください。ポール・グレアムは「同意しない方法」と呼ばれる優れた作品を持っています。
これらの2つの簡単な手順は、実際の問題の理解を深めるのに役立ちます。ソフトウェアはユーザーなしでは意味がありません。私たちのほとんどは、ユーザーがソフトウェアにお金を払うことに依存しています。侮辱的に見えるかもしれない態度でユーザーを遠ざけるのではなく、ユーザーと協力してください。
一部の「ばかげた」機能要求は、非常に興味深く、問題を解決するのが難しいことにルーツがあります。
ばかばかしい機能要求は、応答するときに 2 つの陣営に分類されます。
タイプ 1 については、リクエストを分析し、確固たる事実または専門家の意見のいずれかで対応します。分析の結果、既存のコードに追加の作業を加えれば可能であることが示された場合は、見積もって高く見積もってください。
タイプ 2 については、最初にリクエスタに機能の詳細を説明してもらいます。元のアプリケーション仕様の問題領域を超えて、私が明確に理解していないビジネスの分野で彼らが働いている可能性があるからです。それでも理解できず、機能の目的が本当にわからない場合は、彼らを思いとどまらせるために高く評価します。
彼らが見積もりを受け入れるか、私が受け入れた場合、最終的にそれを取得してから、私はそれを行います。
結局のところ、彼らは顧客であり、顧客が仕立て屋に行き、4 本足のズボンを求めた場合、仕立て屋はしばらくの間議論するかもしれませんが、最終的にはカスタム作業であり、はるかに高価です. そのため、機能に十分な価値があり、喜んで支払う場合は、喜んでお金を受け取ります。値が見えないからといって、値が間違っているわけではありません。
これらはすべて良い答えです。確かなデータ (生成できる場合)、「信じられないほどばかげた」見積もり、そして何よりも尊重が必要です。
ジョニーの答えは、正確な言葉ではないにしても、本質的に正しかったです（十分な担当者を作成した場合はコメントします）。ただし、場合によっては、これらの正確な言葉を使用すると、要求者が異議の内容を再確認するのに十分な不協和音を生み出す可能性があります。はい、これは、ソフトウェア、広告デザイン、さらには (あえぎ!) 建設など、あらゆるプロジェクトベースの取り組みに当てはまります。迫撃砲を運んでいるうなり声が、欠陥のある設計に異議を唱える理由や影響力を持っているわけではありませんが、建設主任は、彼の計画が建設不可能であるかどうかを建築家に伝える義務があります。
他のすべてが失敗した場合は、議論を文書化してとにかく構築してください。それはもはやあなたの責任ではありません。
I think the only thing you can do is very concisely describe the major issues that the change request will bring up to the people involved. At my place of work we have the same problem as you do.
Some of the change requests force the developers to jump through hoops just to get it done and in the end it results in less maintainable code for a feature someone upstairs thought would be a good feature.
In my experience there is really nothing you can do to stop this and eventually management will start complaining about how long development is taking etc etc. It's a horrible crappy cycle which will either end in the site being re-built or your team spending eternity in code hell.
Good luck.
There are different kinds of "ridiculousity".
I like to discuss about requirements :-)
Edit:
A Typical discussion
ほとんどの場合、不可能なことを求めている人は、求めているものがなぜそんなに問題なのかを理解していません。
一般的には、次のようになるまで、要件の明確化と詳細の追加をお願いするだけです。
頭の中に電球が浮かび、彼らが何をしようとしているのかがわかり、「ああ、あなたが本当に欲しいのは Y ではなく X です」と言うことができます。その時点で、彼らは一般的に「ええ、それは私がずっと言っていたことです」と言うでしょう.
彼らは自分たちがいかに非現実的であるかに気づき、要求を撤回します
あなたはそれが本当に良いだろうが、それは不可能であることを共同で認識しています. 通常、私の経験では、大規模なクローズドソース アプリケーションに変更を加える必要がある場合に発生します。技術者向け。Microsoft は、ある小さな会社に依頼されたので、Excel に変更を加えません!
お客様が作成した要件が、この問題の主な原因である可能性があります。問題は、顧客が時々ソフトウェア開発者の仕事をしようとすることです。
彼らは問題を抱えており、その問題を解決する機能を考え出します。残念ながら、これらの貧しい人々の一部 (ほとんど) は、ソフトウェアの設計があまり得意ではないため、最後に非常に興味深い機能が得られます。
この種の遅延機能の一部を削除する方法は、再帰的な .Why() 関数を使用するだけです。問題が見つかるまで理由を尋ね続けてから、自分で機能を設計してください。多くのシナリオでは、シンプルで安価で、すべての関係者を満足させる方法で再設計できます。
ばかげた機能要求のように見えるものが、実際には良いものになる場合もあります。ソフトウェア開発者 (そして私自身も過去にそうしていたことがあります) は、会社に多額の利益をもたらすかなり複雑だが非常に便利な機能にノーと言うことがあります。したがって、「ばかげた」機能に遭遇した場合は、すぐにそれを却下する前に、ビジネスに対する潜在的な価値を計算してください。
時々、プロダクト マネージャーからそのような要求が寄せられます。
あるケースでは、パフォーマンスの問題が発生するだろうと説明し、上級管理職がそれを確認したので、私たちは勝ちました。
次回も同様の懸念を提起しましたが、年配の男性が利用できなかったので、誰も本当に気にかけなかったので、私は彼らが望むことをしました. 私も断りました。
おそらく、複数基準のリクエストをデータベースに送信し、結果を表示すると同時に、これらすべての基準のどれがヒットしたかを示すことを意味しています。推測しましたか？
機能がばかげている理由を説明できる場合があり、機能が削除されます。
場合によっては、より年上の人に「いいえ」と言ってもらうこともできます。
時々、あなたは自分自身に「ノー」と言うのに十分な上級者（または影響力のある人）です。
場合によっては、「はい」と言うことができますが、タスクの優先度を低くします (決して実行しないでください)。
時々、あなたはそれを続けなければなりません。
後者の場合、タスクを非常にうまく実行する必要があります。なんで？あなたは輝き、そうすることで、ばかげたものの影に焦点が当てられます.