当用户要求您将不实现的功能时，您该怎么办？

当用户要求您可以实现的复杂功能时您会怎么做，但是您不会这样做，因为1）它给其他用户增加了不必要的复杂性2）您也不想将其作为一种选择您不希望您的设置面板过于复杂。

我写了一个iOS应用程序，由于上述原因，有一些用户问我一些无法使用的复杂功能。大多数时候，我只是回答他们：“我们会考虑到这一点。” 向他们解释说他们属于少数族裔，希望获得此功能也无济于事。那么，在这种情况下您该怎么办？

我认为您做对了。您不能取悦所有人，也不应该！要有礼貌和专业，但是您不必执行要求您做的所有事情。

您需要妥协。您的用户（应用存在的原因）说它不满足他/她的需求之一。

满足用户需求与允许最终用户设计您的应用程序之间是有区别的。与用户开会并询问很多“为什么？” 问题，直到您了解该人正在尝试执行和无法完成的任务的核心，或者在当前用户界面中执行该任务太麻烦了。记下这些笔记，并模拟一些您可以使用的替代方法，然后将其呈现给用户。

最重要的是：请记住，该应用程序并不存在，它可以简化您作为程序员的生活。该应用程序在那里为用户服务。

如果您阅读Seth Godins博客（http://sethgodin.typepad.com/），您将一遍又一遍地看到相同的消息：

1. 运送东西（并听取反馈）
2. 不要试图一直取悦所有人。

我销售的产品与您有类似的问题。我对各种功能都有各种各样的要求。该应用程序变得比我真正想要的还要复杂。每个选项都会增加复杂性，这是我想避免的。现在，我的复杂性超出了我的期望。

这样做会使更多用户满意。并赶走了发现它太难设置的用户。

具有简单/高级设置是摆脱束缚的一种方法。在一定程度上。但是，这会使您的开发更加复杂。

在收到请求的所有情况下，我总是礼貌地回覆。有时我会完全拒绝，尽管这种情况很少见。在此，我解释了为什么，通常是响应于要求对整个UI进行修改的请求，这项工作如此艰巨，以至于我不会去那里。在这种情况下，我解释了我的原因，但是感谢用户的要求。

在所有情况下，包括那些我立即拒绝的情况，我都会将它们记录在功能和缺陷数据库中，以考虑下一个版本。这使您有更多的时间来考虑这一切，并且可能稍后提出另一种选择，即请求不完全相同，但可能会增加一些价值。

如果已考虑并注释了功能请求，并最终（在开发时）做出了杀死该请求的决定，那么我将其关闭。否则，他们将留待以后再考虑。

这不是一个完美的方法，但最终，作为软件作者，您必须遵循或放弃某些设计原则。应仔细考虑每种方法的选择。

我认为您应该对用户诚实。如果您已经决定不这样做，请不要告诉他们“我们将考虑在内”。这将使用户相信该功能会在某天到来，并因为它永远不会来而感到失望。

我相信，从长远来看，这将使您受益最大。

我只想感谢他们的建议，但请说现在不在您的路线图中。人们会最了解您的资源有限。

在这种情况下，我通常会做三件事：

1. 如果用户的想法毕竟可能是个好主意，我会三思而后行。我学会了不相信自己的第一本能。有时用户是正确的，而我是错误的。
2. 向用户解释为什么您不能包含该功能。
3. 向用户说明她如何使用所拥有的软件满足自己的需求

我认为最后一点是最重要的。大多数用户不希望他们的建议完全实施。他们只需要一个问题的解决方案，他们建议他们可以想到的最简单的解决方案。也许您可以找到可以实施的更好的解决方案。

对于我们的每种产品，我们都有一个“未来版本的想法清单”。因此，我们告诉用户的是“我们会将您的建议列入该列表”-坦白地说，我们实际上是这样做的。

该列表没有优先级，但我们会定期从中挑选事物，并用它们来补充我们的积压工作。我们不会“按顺序”对待它们，而是尝试找出哪些想法能带来“最大的收益”-在合理的开发努力下，尽可能多地为我们的用户带来最大的收益。

针对产品概念完整性的功能要求可能会永远存在。但是有时候，偶然的情况是，至少可以隐含在这些功能请求中的某些想法可以实现，也许不完全是提出它的人所想的那样，而是以更适合产品体系结构的方式实现的。

因此，我的建议是：不要只说“我们会考虑到这一点”。并在结束通话后就忘记了这个主意。取而代之的是，拥有一个可以在其中存储想法和功能请求的工具，无论是在问题跟踪器中还是在Wiki中，或者在电子表格中，它都能最适合您的需求。