如何进行产品优先级排序？带你掌握 5 种好用的排序框架

▲点击 "TCC翻译情报局" 关注，回复 "社群" 加入我们

本文共 3893 字，预计阅读 10 分钟

TCC 情报局的 第 83 篇 干货分享

2021 年的 第 71 篇

你是否经历过需求优先级排序的困难时刻？对于功能的开发排序，通常是在脑海中构想衡量，还是将其系统化的拆解梳理？这里为大家介绍了几种常用优先级排序框架，希望可以让你的产品在资源受限的世界中把握机会，实现功能的有效、有序开发。另外，这里还总结了各种框架的特点及使用场景，希望大家可以理解运用，找到产品的商业价值和用户价值的平衡点，实现双赢。一起来学习下吧，如果你还有更好的方法或实践心得，欢迎分享～

这是一个无限机遇和有限资源并存的时代。我们所做的大部分事情和创新无关，而是不断使用排除法来筛选出最佳道路，公司发展和软件建设亦是如此。

我们应该如何建设？自软件诞生起，这都是一个很重要的问题，也是产品经理存在的原因之一。我们并不缺乏建设方向，大量选择和有限资源之间的抉择，才是需要优先考虑的问题。随着时间的推移，这个问题催生了许多框架和流程，来帮助我们理解和衡量选项，从而找到最有成效的方案。

通常，我们会自然而然地衡量和排序各种选择的优先级，但大多只是下意识进行，没有将这个过程体系化。这在某些情况下可能行得通，但对于产品经理来说，没有理由的优先级排序是行不通的。对某件事进行优先级排序，意味着我们要延缓处理某些事情。如果我正在和负责人讨论功能推迟开发，最好有充分的理由来解释原因。接下来，我们将探讨一些常见的优先级排序框架，以及每个框架的优缺点。如果你需要，我们可以分享更多资源，以便进一步研究。

1. MoSCoW

1. MoSCoW

MoSCoW[1] 是一个简单且有效的工具，可以帮助产品发现用户需求，让目标用户从中获益并找到价值。它将潜在的功能分为几个关键类别：必须拥有、应该拥有、可能拥有 和 不会拥有。

（[1]莫斯科（MoSCoW）：Mo - S - Co - W，是四个优先级别的首字母的缩写，再加上 O 以使单词能够发音。）

M（Must have requirement）：必须有的功能。如果不包含，则产品不可行，通常是指最小可行产品（MVP）的功能。比如支付宝的转账、收款。

S（Should have if at all possible）：应该有的功能。这些功能很重要，但不是必需的。虽然与‘必须有’一样重要，但它们通常可以用另一种方式来代替，去满足客户要求。

C（Could have but not critical）：可以有的功能。可以提高用户体验，或提高客户满意度，但不是必需的。

W（Would be good to have...）：现在没有资源开发，或许以后会考虑的功能。

优点：

• 适用于初期产品，可以定义产品的 MVP 形态，而非渐进式优化现有产品

• 易于理解、使用并展开讨论

缺点：

• 没有考虑每个功能的成本

• 不能量化每个功能的好处

• 比起讨论 “我们现在应该做什么”，更应该关心 “MVP是否已就绪”

总结：

MoSCoW 可以很容易被利益相关者理解和认可，最棒的是这个框架以用户为中心。对弄清楚用户如何评价每个潜在功能很有效，并利用这些信息去排序用户需要的和想要的事情，并对不能为用户生活增值的功能降级。

2. KANO

2. KANO

KANO 在一些方面比 MoSCoW 更简单，它同样以用户为中心，可以识别功能和用户满意度之间的关系，并将功能划分成几个类别：

1、基础或必备型功能：理所当然的需求，如果没有这类功能特性，你的用户甚至不会考虑使用该产品。

2、期望型功能：指顾客的满意状况与需求的满足程度成比例关系的需求，在这方面投入的越多，用户的满意度就会更高。

3、兴奋型功能：指没有被用户期望的功能需求，但一旦得到满足，即使表现并不完善，用户仍然会产生愉悦的反馈。

4、无差异型功能（Indifferent Quality/Neutral Quality）：不论提供与否，对用户体验无影响的需求。

5、反向（逆向）型功能（Reverse Quality）：指引起强烈不满的质量特性和导致低水平满意的功能特性，因为并非所有的消费者都有相似的喜好。

（p.s. 4、5点为译者补充知识点）

优点：

• 将用户的需求放在首位

• 可以纠正对 “期望型” 和 “基础型” 功能的错误理解

缺点：

• 没有考虑成本

• 客户可能会对问题和方案产生混淆

• 耗时，需要从用户那里收集信息

总结：

KANO 模型 能够验证那些对用户体验至关重要、庞大且复杂的需求的合理性，从中筛选出期待型需求，对其进行降级处理。这个模型最大的缺点是需要将用户价值提前分配给每个功能，而不是由用户定义功能，并且忽略了成本、工作量、确定性及其他业务指标，例如 MAU、收益等。

3. 执行 & 收益矩阵

3. Effort / Impact Matrix

执行 & 收益矩阵是确定优先级最简单、最直接的框架之一（Effort 可以理解为工时或执行难度）。首先，定义每个功能的执行度和收益值，然后将其绘制在一个四象限图上。这个矩阵可以将执行难、收益低，以及执行易、收益高的功能筛选出来，为优先级排序提供充分的理由。而位于中间值的功能可以用多种方式评估，一个简单的方法是通过其在矩阵中的位置，用收益弥补成本，以此衡量优先级；或者利用其他优先级框架进行确定。

优点：

• 容易理解

• 容易建立

• 可以得到一个明确的功能列表，来确定高优先级和低优先级

• 有机会将 “收益” 指标 “落实到” 到组织内部

缺点：

• 对影响或成本缺乏清晰的理解会拖慢进程

• 忽略了时间、信心度、竞争等因素

• 没有为机遇和优化项目提供清晰的指导

这是我经常使用的排序框架，它不仅易于利益相关者理解，还可以有效识别那些 “快速制胜” 的功能。这种方法适用于回答 “我们下一步应该做什么”，而不是 “MVP是什么”。由于没有涵盖利益相关者通常希望增加的因素，它的简洁性有时也是缺点。

4. 延迟成本 / 工期（CD3）

4. Cost of delay divided by duration

CD3 或许是最能说明优先级紧迫性的框架。它不仅可以有效对比功能价值，还可以回答 “如果开发此功能，它的价值是多少”，以及 “没有这个功能，我们需要付出多少”。

优点：

• 用成本量化工作

• 很容易将功能映射到公司或业务 OKRs[2] 

• 展示排序事项的时间紧迫性

• 有助于请求资源和人员分配

（[2]OKRs（Objectives & Key Results）：目标和主要结果，定义和跟踪目标及其完成情况的管理工具和方法，为创建公司 、团队、个人结构，提供了简便途径。）

缺点：

• 成本通常是预估出来的，因此可能会导致冗长的讨论

• 初次使用门槛较高

预估功能成本是一件困难的事情，相比其他方法，这个框架过于抽象。当然，CD3 的优势也很明显，它 可以展示时间的价值，让团队快速向价值靠拢，而不是利用其他无价值的衡量标准。

5. RICE

5. reach，impact，confidence，divided by effort

RICE 是用来评估各项目需求四大因素的首字母缩写：触达（Reach），影响力（Impact），信心度（Confidence）和 努力（Effort）。将每个功能的影响范围和影响力估值，与信心度分数相乘，可以得到触达范围和影响力关联系数的基准线，然后除以时间总量，即 RICE 法则得分公式。

优点：

• 加入信心度因素，有利于降低影响范围和影响力的评估误差

• 有机会将 “收益” 指标 “落实到” 到组织内部

• 有助于成长期产品发展

缺点：

• 不适用于启动阶段的产品

• 难以测量产品的影响范围

总结：

作为影响力驱动框架，RICE 试图通过量化工作项目完成优先级排序。这个框架更适用于现有产品，尤其是基于成功业务数据而得出的影响范围指标，会使得排序结果更加合理。因此，当产品还未上市时，评估影响范围会是一件很困难的事情。

我们了解了不同的优先级排序方法，但要如何选择呢？简而言之，没有终极的排序方法，甚至没有 “最佳” 方法。但有好坏之分，这取决于你的应用场景与框架是否匹配。例如，一些框架仅适用于产品生命周期的某个特定点，另一些仅在特定的数据点有效。显然，现实中会存在很多不同的场景，这些框架或多或少有所帮助，尽管很难比较哪种更好，但可以通过对共性要素的考量，描绘出它们的适用范围。

最后，在不同的行业和公司中，框架产生的结果不尽相同。在选择框架前，需要评估公司的目标、可用数据、项目时间、对用户的触达程度、框架的熟悉度，并与利益相关者达成共识，然后选择一个框架进行尝试，记录它的缺点和优点，以及使用限制。逐渐地，你将拥有自己的框架库，并且更加自如地运用它们，从而产出最佳结果。

分享你的经验，告诉更多人这些框架的使用效果，以及交叉使用的利弊。你还用了哪些优先级排序方法？

往期精选文章：