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