在我们的主要产品中，我们已经有了一个功能请求，这个功能请求已经存在好几年了，现在已经被要求了很多次。这在技术上很容易实现，问题在于它将从根本上改变工具的概念，并且可能会导致更多的错误报告，因为人们错误地使用新功能来匹配新概念（我们无法使用解决问题）。我们有一个单独的功能，可以很好地解决问题，但我们仍然会收到实施新功能的请求。是否应该包含一个很重要的功能，这个功能根本上是错误的？
我们应该
将其实施为插件。
根据Joel的说法，Fog Creek正是因为这个原因才将插件添加到FogBugz中。这种辅助功能可以作为插件实施，而无需从根本上改变他们的产品。 – 2009-12-09 18:39:44
更重要的是，将它作为一个可以收费的插件来实现。这种功能也成为收入来源。平衡插件的成本，以阻止那些会“滥用”该功能的临时用户，但对于认真考虑过为什么他们希望以这种替代方式来做事情的用户而言，这些用户的价格是可以接受的。 – 2009-12-09 18:47:46
我会尝试重新设计用于您的工作的用户界面，以便让用户更轻松，更明显。在一天结束时，客户支付账单，因此我们有义务满足他们的需求。当他们所要求的会导致更多的问题时，我们会回过头来提供一个不同的解决方案，以便我们不会创造更多的未来错误，并且我们仍然让客户满意。
回答这个问题几乎是不可能的，因为我们不知道你在说什么。
说了这么几点：
我倾向于实施它，因为这会让您的客户满意。
一个选项是给他们一个菜单选项，它将它们指向两个方法。
可能是某种向导，帮助他们决定使用哪种解决方法。
定义“我们的用户”。它是5％的用户群，80％，95％？你是否调查了足够多的人以确定这是绝大多数用户想要的东西，还是仅仅是一群流氓用户（他们可能是最困难和最难取悦的）。
我认为需要先建立。如果这是用户群中的大多数，并且增加了他们的价值，那么我会尝试在中间遇到的地方达成妥协，而不会影响产品的完整性，但仍然为客户提供一种替代解决方案满足他们的需求。
它是前5名中最热门的功能 – thecoop 2009-12-09 18:44:21
宣布解决方法作为对请求的请求的解决方案。在用户界面中更加突出的解决方法/更易于使用。
我会带着更多的潜在投资回报。通过实施此功能你会增加利润吗？如果是这样，是否超过支持新功能的成本？如果潜在利润高于您的支持成本，我会建议使用该功能。
如果没有收益或者降低支持成本，那么这样做是没有意义的。
虽然不是一个编程问题，但我多年来见过很多人与这类问题斗争。
你要问自己几个问题
1）你，还是管理都有，做了成本效益分析？ 问问自己“功能如何？”
2）如果产品将发生根本性的改变 - 将其转换为全新的SKU是否有意义？
3）管理层最终会得到他们想要的。你想与他们合作，为你的客户提供最好的体验&成为英雄，或者反对他们并寻找其他机会。
如果此功能与您产品的理念背道而驰，则表示该产品不符合用户的心理模型。这样做的后果远远大于单一缺少的功能。你需要进入你的用户头脑，找出如何根据他们的期望调整你的模型，或指导他们对你的模型的期望。
把足够的想法放在这里，它可能成为你的好机会。
+1好点。用户会制造或破坏你。但是，客户并不总是对的。 – 2009-12-10 02:10:40
他们并不总是对的，但他们总是值得理解。如果他们的想法与你的想法不同，那是一个危险的差距 - 要么你应该改变你的想法，要么弄清楚如何让他们理解你的想法。 – 2009-12-10 03:37:43
在'神话人月'（你已经读过，是不是吗？），布鲁克斯说了一句话，说'架构的概念完整性是最重要的事情'。这意味着，如果请求的功能打破了产品整体设计的概念完整性，那么无论请求的数量多少，您都应该继续避免实施。或者，您需要重新构建体系结构，以便所请求的功能适合修改后的体系结构。
我工作的产品之一就是添加了“很多要求的功能”。它的行为不同于产品中的其他功能。这是一个可怕的疣。但是，由于竞争做到了，我们必须这样做。但是我们的体系结构（与这个领域的竞争对手存在根本差异）并没有保持真实，而是把竞争对手的特征加到了愚蠢的细节上。
我仍然非常痛恨这一事实，该功能被破坏到系统中的破坏语义w.r.t产品的其余部分。为了将盐擦入伤口，我不得不将新功能作为我们客户群中“自切片面包以来最伟大的东西” - 真正受伤。
话虽如此，没有人抱怨（我认为他们应该）关于该功能。它有时可能会被使用。竞争对我们可能会有一点不同。 （并且注意：我并没有反对与我们产品的正常工作方式一致的风格;我只是反对它按照我们的竞争对手使用的风格实施 - 因为其他相关功能类似地工作到他们系统中的破坏实施，而我们的系统更加理智和友好。）
这很难。有时市场胜出。
+1我每天都会体验一次。仅仅因为别人以一种方式来做，并不意味着你需要以同样的方式去做。皮肤有很多种方法去皮肤 – 2009-12-10 02:10:03
我会用一个简单的猜测来衡量成本（就可用性而言）与收益之间的关系，至少作为衡量一个主要因素。例如，如果该功能可能有助于45％的用户，但使该程序难以用于其他55％，则不要这样做。
假设您问的是商业产品，您是否真的会根据互联网上几个随机的人做出商业决定，他们会认识您的产品？如果不是，这不是一个真正的问题。它也不是编程相关的。 – 2009-12-09 18:35:56
但程序员（特别是在小公司和OSS项目中）会碰到并且必须处理的事情。 – thecoop 2009-12-09 18:39:09
我很抱歉地说，程序员不会做出产品级别的决定：产品经理会这样做。 – jldupont 2009-12-09 18:40:04