评估需求的价值

通过“业务-用户-竞争-运营”四维模型进行评估

根据不同维度细化出评估因子，再构建与业务部门达成共识的评估表，从而确定必须做、应该做、可以做、可不做这四个等级。

不应该按四个维度分别评估后再加权得出最终优先级，因为很多需求可能在某个维度低价值，而在其他维度高价值，平均之后就会被埋没。

正确的做法应该是按产品或系统所处的阶段选择主评维度：

0~1 的建设期，通常使用业务维。
1~10 的发展期，通常重点关注用户维、竞争维。
10~100 的成熟期，通常重点关注运营维。

也可以组合使用维度，针对每个维度进行排序，然后按一定比例选择不同维度的高价值需求。

业务维上，与重要业务关联的需求优先级更高，需要尽快实现业务上线。最常用的评估办法是价值频率双维评估法。

用户维是指能让越多用户满意，或让用户满意度提升越大的需求，优先级越高。通常应该先进行用户分类，然后根据不同用户类型进行综合评估。

运营维是指与产品运营价值、业绩、企业业绩提升越相关的需求，优先级越高。通常应该结合产品系统的类型，选择合适的模型。

竞争维是指对产品系统竞争力提升越大的需求，优先级越高。最常用的评估方法是 KANO 模型。

KANO 模型通常用来分析单一用户视角下需求的接受度。严格来讲，KANO 模型研究的是产品功能点和用户满意度之间的关系，但结论可以作为优先级排序依据。另外需要注意：KANO 模型并不完全适用于 B 端产品，因为 B 端产品背后隐藏着多角色和多利益方，不同利益方之间可能存在利益互反的特点。所以使用 KANO 模型一定要明确场景，切记盲目使用。

使用 KANO 模型的步骤如下：

通过调研问卷，以正反两问的方式获取用户对功能点的反馈。
对用户反馈进行统计，获得不同答案结果的占比。
拿到统计数据后，经过一系列计算，分析出功能点的属性特征。

具体来说，有 6 种属性：

A，魅力属性：提供功能，用户会很喜欢；不提供，也无所谓。
O，期望属性：提供功能，用户很喜欢；不提供，用户则不喜欢，对功能有强烈期待。
M，必备属性：提供功能，用户感受一般；不提供，用户则强烈不喜欢，说明是必备功能。
I，无差异属性：无论是否提供功能，用户感受都趋于平和。
R，反向属性：提供功能，用户不开心；不提供功能，用户反而开心。
Q，可疑结果：结论逻辑相背，属于脏数据。

这六种属性具有天然的优先级顺序：M>O>A>I>R>Q。

通过 RICE 模型进行评估

Reach 是指需求可能触达的客户数量。Impact 是指需求的价值评分。Confidence 表示产品经理对需求的信心，这是一个基于主观判断的修正参数。Effort 是指需求需要投入的研发人天。

所以，优先级 RICE 得分的计算公式就等于：RICE score = (Research × Impact × Confidence) / Effort。

但是这里要注意，Impact 表示的产品价值本身就是一个很难量化的因子，所以 RICE 模型并不能解决成本价值模型中面临的困境，即该如何定义需求的价值。

对于 SaaS 软件，在判断需求价值的时候，还可以把受影响的客户数量考虑进来。但在实际商业运作里，不能简单地认为其他变量相同的情况下，受需求影响的客户数量多，优先级就高。有些需求可能只针对某个头部客户，却具有标杆效应和示范效应，这本身就有很高的商业价值。

通过价值范围模型进行评估

将一个软件产品所能提供的价值，包括规模、成本、效率、风险、品质，以及产品本身的用户体验，列在纵轴上；再把业务相关的利益方都列在横轴上，这样就得到一个多象限矩阵。

和业务方达成一致之后，设计好这张表格，后续所有需求在表格中都有对应的位置及对应的优先级。价值范围模型更适用于企业对内产品研发中的需求优先级打分，在实际应用中可以有很多种变化。

同时，设计一张所有人认可、意见统一的价值范围模型打分表，还能避免未来和业务方扯皮的问题。

通过拆解指标进行评估

B 端产品对业务的价值无外乎五点：规模、效率、成本、品质、风险。任何一个产品需求都应该尽可能聚焦某一个价值点，从而集中研发资源，控制项目风险，提高迭代效率。

这 5 个价值点里，效率、成本、风险是软件产品相对容易优化，并且容易评估收益的。不论是操作效率、运营效率的提升，还是人力减少、工作量减少、风险事件减少，都相对更容易找到量化指标进行跟踪分析。

规模和品质这两个价值点，与前三个价值点相比更难评估。其中，规模主要是指营收；品质包括产品品质和服务品质。整体来讲，凡是受到人为因素影响较大的业务价值点，评估起来都有难度。

遇到这种情况，可以考虑将相关业务指标尽量拆解成更细粒度的子指标，找到相关性最强的二级指标、三级指标，来尝试论证产品对业务的影响程度。

通过 NPS 进行评估

用户需求来自终端用户，可能包括业务诉求，但更多的是体验优化方面的需求。

如果是体验优化类诉求，一方面可以衡量操作效率的提升，另一方面还可以通过净推荐值 NPS 来考核用户对功能优化的满意度变化情况。

NPS 的使用很简单：设置一道问卷题目，然后选择 9 分和 10 分的百分比，减去选择 0~6 分的百分比，7 和 8 分的数据被丢弃，最终就得到了 NPS 分数。

但是分析 NPS 的时候，要跟踪分析指标的变化趋势，而不应该关心绝对值本身，因为绝对值本身没有可比性和参考性。

通过考核使用人数进行评估

无论能否找到评估产品价值的方式，都应该持续跟踪评估产品的使用情况。这是一种既简单又有实际意义的评估方式。如果不能证明产品的业务价值，至少可以考虑产品的使用人数。

通过需求的价值类型进行评估

如果是商业化售卖的产品，产品经理首先要判断需求的商业价值是否符合产品本身的定位和规划，是否遵循产品商业化售卖的战略诉求和经营要求。

如果是对内使用的产品，商业价值则针对企业自身经营价值。B 端产品除了承载商业价值，更需要帮助客户在业务上取得成功，这就是 B 端产品的业务价值。B 端产品对企业来讲，承担着提升收入、降低成本、提高效率、保证品质、控制风险的任务，这些都是 B 端产品的业务价值。

B 端产品本质上也是为了解决业务问题而存在的，但在设计过程中要考虑终端用户的体验问题，包括是否能够提升一线员工的效率和满意度，这是产品的用户价值。有些时候，赋能用户其实也是赋能业务，因为提升了用户价值，也就提升了业务价值。提升整体使用体验还可以提高员工的工作效率，实际上也提升了企业整体运作效率，尤其是针对工具型、基础服务型产品。

最后是技术价值。软件产品在构建过程中，自身也存在技术层面的优化点。在整个产品规划、建成过程中，价值的优先级并不是一成不变的，不同的产品阶段可能会有不同的优先级策略。

通过综合方案进行评估

B 端产品的运作离不开多种类型软件功能的组合。对业务没有明显价值和收益，但软件系统又非常需要的功能，属于基础功能。对于这种功能，只需要正常考核交付质量和交付时间就可以。没有必要为了评估而非要生搬硬套某些业务价值，造成没必要的麻烦。

中台的目的是抽象建设可以复用的软件系统或模块，其中很重要的一个目标是避免重复造轮子。可以通过考核中台产品接入的客户端数量、接口的调用数量，来估算研发人力成本的节省度。

纯技术优化的需求和项目，都是为了保证系统能够运行得更加稳定、高效，架构更加合理，灵活性更强。对于这类需求，可以考虑衡量系统的稳定性、安全性等非功能性指标。当然，相关工作更多是由技术团队参与决策，产品经理了解即可。

总而言之，这种评估方式更适合于技术需求。