我们应该如何订购需求？

摘要：需求管理是一门艺术。

在开发产品时，我们每天都面临着各种各样的需求，一些来自外部用户的反馈，一些来自内部团队的想法，一些是产品错误，一些是新功能.

似乎只要满足所有要求，产品就会变得更好，然后吸引更多用户，然后赚更多钱，然后招募更多人，然后完成更多需求.

问题是需求会不断涌现，我们永远无法清空所有的要求，996无法完成，这样的生活是不可能的。

我们可以做的是不断对需求进行排序并实现最高优先级。然后问题来了，我们应该如何给需求排序？

以用户为核心确定优先级

乔布斯曾说过：

在你向他们展示之前，人们不知道他们想要什么。

用户真的不知道他们想要什么？多次不是这种情况。

我负责产品，每天都会和用户交流，他们知道他们想要什么功能，有时他们做简单的交互设计，帮助思考算法，甚至给我开源代码。

问题是用户只是产品的用户，他们对产品的理解并不像我们那么深刻，因此他们要求的要求有时会偏离问题的性质，需要进一步分析和挖掘。

我们不是乔布斯，我们没有创造需求的能力;我们不是张小龙，没有一亿人教我们制作产品。因此，我们应该与用户进行更多沟通，并优先考虑用户的需求：

当用户反馈或吐痰，保持耐心，更深入地交谈，并记录修复错误，优化功能或添加新功能，并积极与感兴趣的用户联系时，他们会给您更多反馈并定期为用户服务。研究，倾听大多数沉默是用户需要说的，根据反馈用户的数量，影响范围，难度等级

当我们制造产品时，创造的欲望非常惊人。总会有一些令我们兴奋的新想法，我们迫不及待地想明天上网。但是，我们应该克制自己的创作欲望，尊重用户的意见。我们的产品面向客户，而非为自己。

在交通红利枯竭的时代，获得新用户比保留旧用户要困难得多，因此提高保留率非常重要。关注每个用户的反馈，及时修复他们发现的错误，并优先考虑他们想要的功能是提高保留率的最有效方法。

BUG 的优先级高于新功能

墨菲定律是这样的：

任何可能出错的事都会出错。

程序员应该知道代码怎么可能没有 BUG 呢？通常不是我们发现的，或者它是已知的，但不是及时修复的。

但是，对于当前的产品错误，我们倾向于忽略它。可能是错误太深了，我们和用户都没有找到它;可能是用户发现了错误，但没有反馈;可能是我们是盲目的，有选择性的，并且觉得问题不大。

事实上，用户对产品质量有着非常严格的要求。如果它们很小，就会发现它们也会呕吐。我们仍然可以知道用户是否反馈，否则我们可能会发现错误，如果没有监控。

还有一个微妙的情况。当用户反馈看似不可能的BUG时，我们会本能地觉得产品应该没问题。问题应该是用户，可能是他的浏览器或网络，或者一些无法解释的问题。由原因引起的。事实上，这只是我们正在逃避问题。代码的工作方式是肯定的。没有什么是无法解释的。如果事情不太正确，那基本上就是一个bug。在这里分享我们的经验之一：

用户反馈，当他邀请成员加入团队时，发现偶尔会有一个邀请失败。

我们检查了监控数据，发现确实存在故障，影响了多个用户，但很少。

然后，我们检查了前后代码，发现没有问题。

由于业务代码没有问题，因此应该没有错误。这可能是由于奇怪的原因造成的。我们不需要做任何事.

后来，几个用户反馈了同样的问题，报告的错误越来越多，我们不能骗自己！

再次检查，业务代码确实没问题，但错误代码位置的行号和列号是否有偏移，那么感到惊讶吗？

不难猜测生产环境正在运行旧代码！看看它是不是。

然后，找到部署的Docker配置文件的问题并不困难，导致部署在节点上的后端代码变旧.

我们总是这样，不断前进，不断追求新的成就，摆脱当前的问题。听着是不是很像我们的生活？

对于产品漏洞，我们应该先修复它，或者设置一个截止日期，新功能可以略微为软件公司

延迟之后。

如果我们不停地开发新功能，那当初开发这个有BUG的旧功能究竟是为了什么？如果我们忽略当前用户反馈的问题，那我们费这么大劲拉新是是什么？

结论

需求管理是一门艺术，需要考虑和权衡的东西很多，暂时给大家一个简单的优先级排序，仅供参考：

用户反馈的BUG自己发现的BUG用户反馈的需求自己想出的需求

严格按照这个顺序操作是不可能的，这是给大家提供2个思考维度。实际工作中，每个需求的影响范围，紧急程度，难易程度也需要考虑。

你有什么更好的想法吗？欢迎留言讨论！本文作者为Fundebug的技术总监，欢迎添加微信交流：KiwenLau。

参考产品需求优先级的艺术 – Kano 模型如何成为优秀的技术主管？你要做到这三点为什么美国程序员工作比中国程序员工作轻松、加班少？

XX