需求优先级排序 如何区分需求优先级

一、判断需求优先级的误区产品经理每天都在不断的接手需求与解决需求，这些需求可能来自于各个业务方，比如：客户、销售部门、运营部门、设计部门、以及老板的战略规划需求，我来为大家科普一下关于需求优先级排序 如何区分需求优先级?下面希望有你要的答案，我们一起来看看吧!

需求优先级排序 如何区分需求优先级

一、判断需求优先级的误区

产品经理每天都在不断的接手需求与解决需求，这些需求可能来自于各个业务方，比如：客户、销售部门、运营部门、设计部门、以及老板的战略规划需求。

在面对这些复杂多样的需求时，产品经理的一些日常工作就是判断需求的优先级，做与不做，什么时候做，需要进行分析判断，并非所有的需求都要做，研发资源一定是用在解决有价值且持续带来价值的需求。

在这些需求中找到最应该做的需求的时候会出现以下问题：

1 老板的需求

在很大一部分情况下产品经理很难拒绝掉一个需求，毕竟需求肯定会不断的出现，对于一些本身正在快速迭代的产品会更频繁。这时候如果老板来一个需求，可能就推掉后面其他的需求来处理了。

如果老板懂产品的话，对产品的发展方向及策略的制定是有极大的帮助的，如果老板不懂产品，天马行空想法可能会造成这个产品的产品力遭到质疑或者偏离主干道。

因为产品的逻辑和线下的业务逻辑是有很大的差别，实际的业务在线下跑的时候很正常，直接搬运到线上可能就会存在问题，就会造成产出与回报不成正比，所以一些没有真正跑起来的业务或者脑门一热就提出来的想法直接搬到产品上，会极大的造成技术资源浪费。

2 需求来源竞品

我们的竞品都有这个功能，我们也要这个功能。并不能完全解决此类型问题，实际上不同阶段对于功能优先级判断肯定不一样，对于已经比较完善的产品就不要对一些低频发生的操作进行优化迭代，一个月也出现不了几次，出现了也不会造成很大的问题，在技术资源紧缺的情况下优先级就往后排一排，在解决完主线问题之后 在来处理一些日常简单的问题。

3 分析行业数据判断优先级

很多产品经理都会去做分析竞品，做功能拆解然后移植到自己的产品上并附加适用于自己业务的能力升级，但是有些东西都是没有得到验证的，借鉴要有但发展主线任务才是重中之重，不能丢掉自己产品的大方向。

需求的优先级的判断是没有答案的，需要考虑很多实际的因素-----短期方案与长期方案、功能所带来的的价值、开发周期、功能成功的可行性等多方面的因素。从单个角度去判断需求的优先级肯定会出现问题，为此在思考问题的时候需要考虑全面从多个角度考虑。

二、需求优先级判断原则

1价值体现/实现成本

我们要在众多需求中找到找到能给业务带来实际业务增长的，工作量相对小的需求。之后在去做工作量中等，但实际影响业务不是很严重的需求，通过这样去评估会让团队都参与进来，最后达成统一的意见。

需求的价值等于用户使用的价值（是否是易用的，是否是好用的，是否是解决了用户诉求，是否符合老板意志，是否是产品未来发展方向）

这里引入四象限法

四象限法则将需求分为：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类。选择的两个维度是：紧急和重要。

2 RICE方式

有时候判断比较复杂，很难用简单的二维图来解决问题，这个时候RICE就是一个很好的打分判断优先级的方式。

· R就是Reach， Reach指的是多少客户在固定期间内会被这个功能影响到，这个数据可以用一个季度内使用的客户数，或者一个月内客户操作的次数来衡量。

· I就是Impact，Impact就是这个功能对产品目标以及战略的影响，可以用1，2，3分数来评估，分数越高，影响越大。

· C就是confidence，就是有多大的把握这个功能会成功，100%表示很大把握，80%表示适中，50%表示比较低。

· E就是Effort，Effort可以用人月的单位来计算。

可以让团队评估这四个维度上面每一个维度的数字，然后用下面这个公司R*I*C/E. 这个就是功能的RICE分数，分数越高，优先级越高

三、总结

常见的几种分析模型就可以很好的解决需求的优先级问题，但是实际操作中还会遇到一些解决不掉的问题，那就需要根据实际情况针对性的考虑，要包含以下内容：所有需求是基于产品主线发展为核心，切勿盲目增加需求及投入开发，针对已经提出很久的需求重新排定优先级。

,