“什么该做，什么能等等”是产品经理的灵魂拷问，而不是简单打个分就能解决的事。 本篇文章将带你跳出“拍脑袋优先级”的陷阱，帮你真正建立一套“既能说服他人也能说服自己”的决策体系。
排需求优先级，本质上其实就是决定做什么、不做什么，先做什么、后做什么。
核心目标就是利用有限的时间、人力和资金等等这些资源，来获得最大的价值。
最终排出来的需求优先级是一种结果，要想达到这种结果，需要产品经理从各个维度来综合考虑，这个过程不管采用什么方法，都充满了主观性。
但是，我们可以通过一些系统化的方法，让这个决定的过程，更加的合理和可控。
毕竟排需求优先级，其实也可以算是更细粒度的产品规划，不管是在哪个层级上，都至关重要。
评估需求优先级的维度有很多，下面主要是列举一些比较常见的维度，可以在实践的时候进行参考：
有多少用户会有这个需求？可以是一个大概的用户数百分比；
这个需求或者是问题，出现的频率如何？
问题是否严重？是严重影响用户使用，还是无关痛痒？
影响面和频率越高，或者问题越严重，需求对应的优先级也要提高。
例如：
登录验证码改版：影响 100% 用户且高频，不改版严重影响用户使用——高优。
企业版专用审批流： 0.3% 用户——低优。
需求做了的话，能有多大价值？
价值分为两个方面，一个是能赚多少钱，另一个是能省多少钱；
钱也就是经济效益，这是价值的最终表现形式，但是在转化为钱之前，价值也有可能是一些指标。
比如用户投诉率、留存率，或者是一些风险的降低和规避，这些都可以算是业务价值。
业务价值越高，需求优先级也要越高。
例如：
电商平台的“先用后付”功能需求，预计可以提升5%的支付转化率，年增收大约3000 万——妥妥的高优。
电商运营后台把“导出数据”按钮换个颜色，没有客户会因为这多付钱——下个版本再说，低优。
得投入多少成本才能做这个需求？
成本包括人力成本、资金、时间等等各种方面。
成本和价值这两个维度要综合来看，优先做那种投入低价值高的需求。
除了关注投入产出比，也要关注投入产出的绝对值，可能会有那种投入很多，价值也很高的需求，需要慎重考虑是否能够承担前期的成本投入。
例如：
系统重构需求，人力成本投入巨大，虽然能提升用户体验，但现有系统也还可以用——低优；
后台数据列表查询需求，能显著提高用户数据查询的准确率和效率，投入人力较少——可以高优。
需求的紧急程度，是否有明确的时间截点，限期内不做的是否会出大问题？
越是紧急重要的需求，越要高优。
例如：
今天8月1号，但APP在8月30号之前必须上线隐私弹窗，否则就得下架 ——火烧眉毛的需求，还这么大影响，必须高优。
老板随口提了个需求：“我觉得加个暗黑模式挺酷” ——又不是不能用，低优！（老板强硬要求的除外）
需求在领导的OKR里吗？跟老板新年演讲有没有对上？符不符合公司的战略定位？
例如：
公司今年 All in AI，做 AI 客服助手——高优。
边缘业务中的“积分商城”优化——可以暂时靠边站。
是否会涉及法律、舆情、安全、财务等各种风险？不做的话，会不会被罚钱、下架、上热搜？
例如：
数据不合规的话会被工信部通报——高优。
数据的展示方式查看起来比较费劲，需要升级优化——该有的数据都有，先凑活儿用吧，低优。
竞争对手是不是都有这个功能了？用户会不会以这个功能来做产品的对比，导致我们的用户流失？
例如：
竞对支持“扫码点餐”，导致我们流失 5% 的用户——高优 。
竞对做了个花里胡哨的签到功能，用户感知不明显——低优。
要做某个需求，是否依赖什么前置条件，否则就没法做，比如需要别的团队支撑、第三方、硬件到位等等。
例如：
要增加优惠券发放功能，内部优惠券系统已经有现成的接口可以使用——前置条件ready，高优。
做需求需要的新接口10月才开放——先排10月，现在低优。
不做这个需求，会不会导致后续需要回来填坑？会不会对后面其他需求有影响？
例如：
电商平台数据库分表需求，不做的话下个月大促必挂——高优。
某个模块功能升级后，用户体验更好，但是最近没什么风险——低优。
上面这些评估维度，在需求很多的情况下，全部去对照评估一遍，会耗费比较多的时间，可以从用户、成本、价值、紧急程度这四个主要方面来快速评估，提高效率。
把需求分成 4 类 —— 重要且紧急、重要不紧急、紧急不重要、不紧急不重要，按这个顺序排需求优先级。
重要且紧急：必须马上要做的需求，比如支付功能崩了，用户想付钱却付不了。
重要不紧急：需要规划来做的需求，比如优化用户注册的流程，降低新用户的流失率。
紧急不重要：很紧急，但是影响不大的需求，比如老板临时要一个数据报表模块，但是报表模块有没有其实没啥区别。这类需求大部分都是一些临时性的需求，不做不行，但是做了也没啥实际太大的价值。
不紧急不重要：这种需求直接往后排，比如APP主题换个更亮眼的颜色，但是实际没什么用户提这个需求。
跟紧急重要四象限法类似，MoSow法也是将需求分为四类，分别是：
Must have（必须做）
从紧急程度、重要程度、需求价值等各个方面上来说，都必须要做的需求，一般比较核心的需求，或者是风险合规类的需求，总之就是不做不行的需求。
比如社交APP加好友的需求。
Should have（应该做）
时间或人力等资源具备的情况下，就要做的需求，这种需求很重要，但是没有重要到不做不行的地步，不做也不影响核心功能的使用。
可以理解为是次核心需求，比如社交APP的动态点赞功能。
Could have（可以做）
做了会让产品更好，但是不做的话，也不影响用户使用的需求。
比如朋友圈动态中发动图的需求，微信也是刚做了这个需求没多久呢。
Won’t have（暂时不做）
明确先不做的需求，后续版本可能再考虑。一般是一些开发成本很高，或者是当下做了没啥实际用处的需求，也有可能是一些不太重要的需求
比如在用户量很少的时候，增加社区动态功能的需求，成本高，用户少，就不适合立即就做。
这个方法相对MoSow法和紧急重要四象限法，会显得更客观一点，因为加入了数字评分，但是客观只是表象，核心还是一种主观性的方法。
这个方法有四个指标，每个指标都有相应的分数、百分比或者是其他单位。
Reach（覆盖面）
需求的影响面。
比如新功能预计3个月内影响10000名用户，那么Reach就等于10000。
Impact（影响力）
影响力有多大，有多严重。
影响力这个指标不像覆盖面那样有大概的数量，所以可以通过定性分档量化。比如分为高（3分）、中（2分）、低（1分）三档分数。
confidence（信心度）
对以上Reach和Impact有多大程度的信心，一般用百分比来表示。
比如以上两个指标的结果，来源于市场调研，但是数据有限，信心程度可以打个80%。
Effort（工作量/投入成本）
完成需求需要多少人力资源，一般都是说多少人天，大需求的话，可能会说多少人月。
比如2人天，就是2个人干一天，也可以是一个人干2天。
但2个人干一天有个前提，就是工作量得能明确拆分，并且不会有额外太多的协作成本，要不然不如一个人干2天效率高。
以上四个指标的数据都明确之后，就可以套入公式了：
RICE Score = (Reach × Impact × Confidence) ÷ Effort
得分越高，说明单位投入带来的综合价值越大，所以得分高的需求要把优先级排的更高。
将需求分为五类，有助于理解其对用户满意度的不同影响：
基本型需求: 必须要有，满足时用户其实并不会觉得特别满意，但不满足时会极度不满。优先级最高（比如登录这种基础且必须的功能）。
期望型需求: 越多越好，满足这种需求用户满意度会有比较明显的提升。优先级次高（比如性能提升、搜索功能增强这些优化的需求）。
兴奋型需求: 用户没有明确预期的需求，提供时能带来惊喜和很高的满意度，但不提供也不会不满。优先级可以看资源情况来定，要是排期不紧张可以纳入排期。
无差异型需求： 做不做用户都不关心的需求。优先级排低。
反向型需求： 不做没事，但是做了用户反而会不满意。这种需求不能做，避免挨喷。
加权打分法比RICE评分法更加的复杂，需要确定的维度更多，但再怎么量化，实际上也是基于主观评价的方法。
第一步，首先需要定义几个比较重要的维度，比如影响面、严重程度、需求价值、投入成本等等。
第二步，为每个维度赋予权重，权重总和等于100%。
第三步，给每个维度打分，比如总分1-5分。
第四步，计算加权总分，这里也有个公式：
(维度1分数 * 权重1) + (维度2分数 * 权重2) + …
第五步，最后再按总分排序，按分数高低排出优先级。
这个方法相对其他方法来说，太复杂了，不太适合快速决策。如果是比较重要的规划，可以考虑使用。
其实在实际需求排期过程中，大部分情况下还是依赖产品经理的主观评价，上面说的这些方法，只是不同的工具而已。
建议在实际排期时，可以把这些方法结合着使用。既要快速决策，也要保证排期的合理性。
当你这些工具用的多了以后，慢慢的就会成为一种思维习惯，就不再需要每次都得对照着各种方法、维度来判断优先级了。
记住：没有 “绝对正确” 的排序，只有 “当前最合理” 的排序，根据数据和反馈随时调整就行。
作者：向上的小霍，现任某厂AI产品经理，公众号：向上的小霍。
本文由 @向上的小霍 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Pexels，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。