当然,大多数情况下,这种类型的请求来自管理层,既没有关于用户真正想要的东西的线索,也没有关于构建特定软件项目或软件的技术方面的线索.有关详细信息,请参阅Dilbert的Pointy-Haired Boss.
然而,这只是一个方面.如果您知道的项目请求会损害您正在构建的系统的整体性能？或者那个愚蠢地获得权威的技术白痴怎么样呢？他们几乎所做的一切都变成了什么？(有关一个很棒的例子,请参阅这篇文章)
最后,您如何雄辩,专业和轻柔地处理您正在构建的要求或法令,您知道这最终会损害项目？
Pau*_*non 14
始终将任何请求与金钱相关联.提出这些要求的人通常更关心金钱,所以要确保他们知道这会花费更多钱,因为:
tee*_*yay 12
我找到了"我们在第二阶段会这样做吗？" 创造奇迹,可能支持"我认为我们可以在没有它的情况下开始管理 - 让我们首先得到一些东西".
如果是客户并且技术上可以做到，并且您可以做到，请获取工作说明书 - 并执行。
如果这是你的工作，你就会像做其他事情一样做。你说，“是的，先生（或女士），我很乐意这样做。而且我根本不介意这样做。我只是想你可能想知道这将如何影响我们的其他系统或预算。并不是说你错了，只是说也许我们应该考虑一下这个问题。可以吗？”
如果他们拒绝，那么，他们就签字了，你就去做。如果您真的担心，请记录您的建议未被听取的谈话。 请记住，如果您不记录它，那么它就不会发生。 如果他们倾听，那么您就赢得了一个朋友。
这对于任何工作都是一样的——计算机、建筑工人等等。
编辑：
我从下面的评论中摘取了这一点：
现在没人看《星际迷航》TNG 或 TOS 了吗？请记住，一号会让皮卡德船长知道任何错误，有时让-吕克会同意，有时则不会。这就是我要说的
优秀的软件设计师不会认为功能请求是可笑的。你必须相信你的直觉，但这只是一个很好的迹象，表明你想仔细考虑这个问题。
我建议一个简单的模型：
尝试了解实际问题是什么，而不是用户要求的解决方案。黄金设计规则“不要与客户讨论解决方案，而是讨论需求”。
能够解释您认为所提议的功能的问题所在。保罗·格雷厄姆（Paul Graham）有一篇出色的文章，名为“如何表达不同意见”。
这两个简单的步骤将帮助您和用户加深对实际问题的理解。没有用户，软件就没有意义，我们大多数人都依赖用户为其付费。与用户合作，而不是以一种可能显得侮辱性的态度疏远他们。
一些“荒谬的”功能请求的根源在于非常有趣且难以解决的问题。