当然，大多数时候这种类型的请求来自管理层，既不知道用户真正想要什么，也不知道构建特定软件项目或软件的技术方面的线索。一般来说。有关详细信息，请参阅Dilbert's Pointy-Haired Boss。
但是，这只是一个方面。如果您知道的项目请求会损害您正在构建的系统的整体性能？或者那个愚蠢地获得权威的技术白痴怎么样呢？他们几乎所做的一切都变成了什么？ （参见this post了解一个很棒的例子）
最终，您如何雄辩，专业和轻柔地处理您正在构建的内容的请求或法令，并且最终会损害项目？
Dupe ：When the Client asks for something ludicrous and insists
答案 0 :(得分：14)
始终将任何请求与金钱联系起来。提出这些要求的人通常更关心金钱，所以要确保他们知道这会花费更多钱，因为：
答案 1 :(得分：12)
我发现短语“我们应该在第二阶段那样做吗？”创造奇迹，可能支持“我认为我们可以在没有它开始的情况下进行管理 - 让我们首先得到一些东西。”
答案 2 :(得分：8)
您选择的武器应该是估计值。荒谬的功能，通常带有荒谬的估计。当必须具有特征X 获得3人年估计时，它会神奇地变成，很高兴有特征X 。
答案 3 :(得分：4)
如果客户在技术上可以做到，并且你可以做到，那么就做一份工作陈述 - 然后去做。
如果这是你的工作，你就会做同样的事情。你说，“是的，先生（或女士），我会很乐意这样做。我根本不介意这样做。我只是想你可能想知道这会对我们的其他系统产生什么影响或者预算。不是说你错了，只是说我们也许应该考虑一下。这样可以吗？“
如果他们拒绝，那么，他们签署了它，你就这样做了。如果您真的担心，请将您的谈话记录在您的建议未被注意的地方。 请记住，如果你没有记录它就没有发生。如果他们听，那么你赢了一个朋友。
这对于任何工作都是一样的 - 计算机，建筑工人，无论如何。
编辑：
我从下面的评论中得到了这个：
是否有人再观看“星际迷航”TNG或TOS？记住第一号会让皮卡德船长知道任何错误，有时候让 - 吕克会同意，有时他也不会。这就是我所说的全部
答案 4 :(得分：4)
我会花时间礼貌地听，如果有多个请求要求他们优先考虑并以书面形式提出请求，理想的是“签字”或者你有任何程序。然后告诉您的经理/客户您将审核这些请求，并通过估算及其对您的日程安排的影响与他们联系。说明只是为了生成这些数据，您需要花费X个小时（或几天），因此您的其他工作将被推迟......
然后回过头来估计 - 如果请求很荒谬，那么你的估计很可能反映出来： - ）
如果您的经理/客户希望继续并且浪费大量时间和金钱，那么至少您已经预先明确了并且已经尽力帮助他们。
如果可能的话，你应该让他们将这些请求推迟到未来阶段，建议你在下一个版本中查看它（我想其他一些回复已经提到了这个想法）。
答案 5 :(得分：4)
一个优秀的软件设计师会限制称一个功能请求荒唐可笑。你必须相信自己的直觉，但这只是一个很好的迹象，你要仔细考虑这个问题。
我建议一个简单的模型：
尝试了解实际问题是什么，而不是用户要求的解决方案。黄金设计规则“Don't discuss solution with the client, discuss requirements”。
能够解释您认为拟议功能的问题在哪里。 Paul Graham有一首名为“How to Disagree”的优秀作品。
这两个简单的步骤将帮助您和用户加深对实际问题的理解。没有用户，软件毫无意义，我们大多数人依靠用户付费。与用户合作，而不是以一种可能显得侮辱的态度疏远他们。
一些“荒谬”的功能请求源于非常有趣且难以解决的问题。
答案 6 :(得分：3)
这些都是很好的答案。你需要硬数据（如果有可能生成它），“可信的荒谬”估计，最重要的是尊重。
Johnny的答案本质上是正确的，如果不是确切的话（我会评论，如果我建立了足够的代表）。但是，在某些情况下，使用这些确切的单词可能会产生足够的不和谐，让请求者再次查看您的异议内容。是的，这适用于任何基于项目的努力：软件，广告设计，甚至（喘息！）建设。并不是说携带迫击炮的咕噜声会有理由或影响力来反对有缺陷的设计，但建筑负责人确实有义务告诉建筑师他的计划是否无法建造。
如果一切都失败了，请记录讨论＆amp;无论如何建造它。这不再是你的责任。
答案 7 :(得分：3)
在回应他们时，可笑的功能请求会分为两个阵营。
对于类型1，我将分析请求并以硬性事实或专业意见作出回应。如果分析表明可以对现有代码进行额外的努力，那么估计并估计高！
对于类型2，首先我会要求请求者更详细地解释该功能，毕竟他们可能在业务领域工作，我不清楚地了解原始问题空间应用规范如果我仍然没有得到它，我真的看不到该功能的目的，那么我估计高，以阻止它们。
如果他们接受了估计，或者我做了，最后，得到它然后我这样做。
在一天结束时，他们是顾客，如果顾客进入裁缝并要求有4条腿的裤子，裁缝可能争论一段时间，但最终这是一个定制工作，而且更昂贵。因此，如果他们看到他们愿意支付的功能中有足够的价值，他们愿意拿走他们的钱;只因为你看不到这个价值并不代表他们错了。
答案 8 :(得分：2)
我认为您唯一能做的就是简明扼要地描述变更请求将给相关人员带来的主要问题。在我工作的地方，我们遇到了和你一样的问题。
一些变更请求迫使开发人员跳过箍只是为了完成它，最终导致代码更少的可维护代码，楼上的人认为这是一个很好的功能。
根据我的经验，你真的没有办法阻止这种情况，最终管理层会开始抱怨开发的持续时间等等。这是一个糟糕的糟糕循环，无论是在网站重建还是你的团队在代码地狱中度过永恒。
祝你好运。答案 9 :(得分：2)
有各种各样的“荒谬”。
我喜欢讨论要求： - ）
编辑：
典型讨论
答案 10 :(得分：2)
我发现人们要求不可能的大多数时间都没有意识到为什么他们要求的是这样的问题。
一般来说，我只是要求对要求进行越来越多的澄清，并提出越来越多的细节，直到：
我头脑中出现了一个灯泡，我意识到他们正在尝试什么，我可以说“啊，你真正想要的是X，而不是Y”。在这一点上，他们通常会说“是的，这就是我一直在说的话。”
他们意识到他们是多么不现实，他们撤回了请求
你们共同意识到这将是非常好的，但这是不可能的。通常，根据我的经验，发生这种情况是因为您需要对大型闭源应用程序进行更改 - 在这种情况下，您只需向供应商提出要求，这对于非技术人员来说更加令人满意。对于技术人员; Microsoft不会对Excel进行更改，因为一家小公司要求他们这样做！
答案 11 :(得分：2)
客户创建的要求可能是导致此问题的主要原因。问题是客户有时会尝试做软件开发人员的工作。
他们有问题然后找出他们将解决该问题的功能。不幸的是，一些（大多数）这些可怜的灵魂并不擅长软件设计，因此你最终会得到一个非常好奇的功能。
通过递归.Why（）函数来删除某些这类延迟功能的方法。继续问为什么直到找到问题，然后自己设计功能。在很多场景中，您可以通过简单，廉价且满足各方的方式重新设计它。
有些时候，似乎是一个荒谬的功能请求实际上已经成为一个好的。 有些时候软件开发人员（我过去曾经发现自己这样做）对一个相当复杂但非常有用的功能说不，会使公司赚很多钱。因此，当您遇到“荒谬”的功能时，请务必在立即解雇之前计算其对业务的潜在价值。
答案 12 :(得分：1)
我们有时会向产品经理提出此类要求。
在一个案例中，我解释说会出现性能问题，而高级家伙证实我们赢了。
下一次并引起了类似的关注，但这位资深人士没有，所以我只是做了他们想要的，因为没有人真正关心。我决定不这样做。
您可能意味着向数据库发送多标准请求，显示结果，同时显示所有这些标准中的哪一个有命中。猜对了吗？
答案 13 :(得分：1)
有时您可以解释为什么功能太荒谬，功能被删除。
有时你可以让更高级的人为你说“不”。
有时你是高级（或有影响力的）足以对自己说“不”。
有时你可以说“是”，但是给任务一个低优先级（永远不要这样做）。
有时你只需继续使用它。
在后一种情况下，你应该确保非常非常好地完成任务。为什么？你会发光，当你这样做时，荒谬的阴影将成为焦点。