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