最流行的7大优先级划分技术和方法

在软件开发领域，尤其是在敏捷框架的应用过程中，待办事项清单扮演着至关重要的角色。它是下一个迭代周期（冲刺）中需要完成的任务或故事点的重要来源。然而，在这些任务正式进入冲刺的待办事项清单之前，它们必须确定优先级，确保团队能够首先着手完成那些最具价值或看起来最合理的任务。

在软件项目中，决定哪些任务应该优先完成是产品经理工作的一部分。而依靠直觉来做这个决定，通常会带来风险。因此，我们在这篇文章里会介绍一些常见的任务优先级设定的技术和方法，解释它们的主要特点，并推荐在哪些情境下使用它们最合适。

选择优先级设定方法时，需要考虑几个重要的因素：

1.简单性：方法越简单，设定优先级的速度就越快。

2.数据驱动：有的方法更依赖于假设，而有的方法则是基于已经验证的数据。虽然基于数据来设定优先级看起来是一个比较好的方向，但有时候我们可能没有足够的数据，或者没有时间去做复杂的数据分析来支持我们的决策。

3.技术限制与商业价值之间的平衡：创造出用户喜欢并愿意支付的产品是很好的，所以有的方法特别强调商业价值。但这样有时会忽略技术上的考虑。有的功能在商业上可能看起来非常重要，但在技术实现上却非常困难。如果某个方法建议我们优先选择那些能快速带来价值的“低垂果实”任务，那么这个方法可能是值得考虑的。

4.最佳使用场景：对于最小可行产品（MVP）和成熟产品来说，优先级的设定可能会有很大的不同。

尽管如此，这些方法并不是相互排斥的。在产品开发的整个生命周期中，它们可以在不同阶段互相补充。

1.MoSCoW 方法：小型产品中最简单、最广泛的方法

MoSCoW 方法是一种用于评估每个任务的相对重要性的简单方法，其中MoSCoW是“必须(Must)、应该(Should)、可以(Could)、不会(Won’t)”这四个词的首字母缩写。这个方法是动态系统开发方法(DSDM)技术的一部分，旨在帮助公司实施业务敏捷实践，并且在那些使用瀑布模型的企业中也颇受欢迎。

特点：

MoSCoW 方法需要将所有的故事点分为四个组别。

“必须”(Must)类别中的功能是必须要有的。如果忽略了这些功能，当前的冲刺项目很可能就会失败。
“应该”(Should)类别中的功能虽然很好，但并不是最优先考虑的。简而言之，这些功能现在对项目成功完成的影响不大，但最终这些功能是需要被实施的。
“可以”(Could)类别中的功能是一些不需要占用太多资源就能进行的小改进，虽然这些功能不是必需的，但它们的缺失几乎不会对任何事情产生影响，至少不会对产品的发布造成任何损害。
“不会”(Won’t)类别中的项目是最不重要的。这些项目不符合当前利益相关者的挑战、需求和要求。因此，这些项目可以被轻松地忽略，或者推迟到将来的版本中。

MoSCoW 优先级设定的优点：

MoSCoW优先级设定的优势非常明显，因为它操作简单。

这种方法简单，不需要深刻的理解或复杂的计算，所以团队可以使用简单的语言来保持与整个优先级设定过程的一致性。这促进了团队与利益相关者之间的相互理解。使用MoSCoW进行调度既快速又透明。

由于这种优先级设定方法在“必须”类别之外没有严格的时间限制，它为按功能调整合适的时间框架提供了灵活性。这样，团队可以在有利的条件下调整功能交付或发布。

MoSCoW 方法的缺点：

尽管优先级可能很容易设置，但MoSCoW方法没有引入任务的顺序，并且缺乏计划。最终，这可能会将整个发布置于风险之中。

尽管MoSCoW提出了从最关键到最不关键的要求或功能，但利益相关者仍可能看不到优先级的完整画面。如果需要集中关注对业务至关重要的关键功能，MoSCoW可能会误导团队。因此，利益相关者必须自己设定业务目标。

类别之间模糊的界限经常使得确定哪些功能应该进入“必须”和“应该”列表变得困难。这就是为什么在所有类别之间浮动任务时需要谨慎行事。

何时使用MoSCoW方法

尽管它简单，但并不总是有效。例如，如果你有一个复杂的待办事项清单，并且有很多时间敏感的发布，你可能需要考虑选择其他方法，或者将MoSCoW与两到三种更全面的方法结合使用。另一方面，对于那些没有很多技术限制和依赖性的小型产品，使用MoSCoW是相当合理的。

2.Kano模型：更适合客户导向型产品的优先级方法

Kano技术是由一位来自日本的研究员狩野紀昭在1980年代开发出来的。这个方法的核心思想是分析和理解用户对于产品的不同特性和行为的满意度，这些满意度是有多个不同层次的。

特点：Kano模型提供了多种实施的方法，其中最基本且常用的一个版本建议将用户需求按照五个标准进行分类：必须有的、吸引人的、一维的、冷漠的和反向的。这个方法主要围绕着用户的满意度，并且是建立在用户意见的基础上的，因此在进行优先级设置之前，需要进行Kano调查和用户访谈。

“必须有的”特性指的是，只有当这些特性被包含在产品中时，客户才会认为这个产品是有功能的。
“一维的”特性具有双重性质，虽然它们不是让产品正常工作的必需品，但客户仍然非常渴望拥有它们。这一类别与预测客户的需求和期望息息相关。当产品包含了客户希望得到的内容时，他们会感到满意；但如果没能提供这些内容，用户就很可能会感到失望。
“吸引人的”特性可以给客户带来额外的满意度，甚至是愉悦和满足感。它们通常是意料之外但又让人觉得“有了它更好”的特性。然而，它们的缺失并不会让客户感到不满。
“冷漠的”特性对客户的满意度影响最小，简单来说，它们几乎没有任何价值。
“反作用”特性被认为是最令人不悦的，它们的存在通常会对客户的满意度产生负面影响。相反，当这些特性没有被引入时，客户通常会认为这是一个好事。

Kano模型的优点：

使用Kano模型的好处包括能够突出产品的潜在优势和劣势，通过用户反馈，Kano问卷的结果有助于了解未来产品的优缺点，这使得产品经理能够在开发初期就确定产品与市场的契合度。此外，Kano模型还可以帮助按照客户价值来对产品特性进行排名，并根据用户需求进行调整。

Kano模型也有其缺点：

它没有提供关于实现某个功能或发布某个版本所需资源的详细信息；它的实践过程可能会非常耗时，因为Kano调查可能需要面向大量的潜在客户，处理和评估结果可能需要相当大的努力，这会减缓产品上市的时间，从而分散团队的注意力；此外，Kano模型受限于客户的意见和知识，可能会导致需求列表仅仅是一个普通的愿望列表，局限于那些没有技术背景的客户的期望，这可能导致不稳定的发布，为了使Kano方法更加高效，需要单独讨论技术概念。

何时使用Kano模型

如果你是一家正努力为初步的用户体验设计生成用户反馈的创业公司，将你的概念与Kano调查结合使用将会非常有效。因为展示总比描述更能说服人，所以原型和问卷的结合将帮助提炼价值。但是，如果你的产品涉及技术复杂性和各种隐藏的障碍，你可能需要权衡Kano，或者完全用更具体的方法来替代它。

3.RICE：为成熟产品设定优先级的全面但费时的方法

RICE方法是一种涉及到计算的方法，并且它为设定优先级提供了一个评分模型。

特点：RICE代表Reach（覆盖范围）、Impact（影响）、Confidence（信心）和Effort（努力）。在优先级设定时，这些因素用来单独评估每个特性。

Reach反映了在一定时间内使用或可能使用某个功能的人数，可以通过查看产品的实际用户活跃度数据来进行评估，如每日或每月活跃用户数。例如，假设正在评估对客户支持页面的改进，那么每月访问这个页面的用户数就是衡量Reach的一个重要指标。
Impact表示了某个特性对整个产品推广的贡献度。为了便于打分，建议使用一个预定义的比例尺，比如巨大影响得3分，高影响得2分，中等影响得1分，低影响得0.5分，最小影响得0.25分。
Confidence是你对某个特性可能带来的好处有多确定的一个度量。根据你所拥有的信息，你需要估计对这个特性可能产生的效益有多大的信心。建议使用一个预定义的比例尺来打分，比如高信心得100%，中等信心得80%，低信心得50%。如果评分低于这个范围，就意味着你对这个特性可能产生的效益不够确定。
Effort衡量的是产品团队、设计团队和工程团队完成某个任务所需要的时间，通常用“人月”来表示，半个月被认为是最小的计量单位。

获得每个类别的评分后，应用以下公式： RICE = Reach * Impact * Confidence / Effort

评分越高，优先级越高。

RICE的优势：

它提供了一种全面评估产品的方法。它综合了多个不同的因素，这有助于从多个角度对产品进行评估，预测产品的成功概率以及它未来可能的推广范围。

此外，RICE方法依赖于可操作的指标和数字，主要基于关键绩效指标（KPIs）。这些数据为产品的进展提供了实证支持，可以在未来的版本中用来作出改进。

RICE方法还强调客户价值的重要性。它使用的指标主要集中在用户的参与度上，并考虑到他们的满意度。这表明RICE方法认为提供优秀的用户体验非常关键。

RICE的缺点主要包括以下几点：

这种方法需要花费大量的时间来进行计算，因为需要考虑所有的指标、进行评级，并对每个待办事项进行详细的计算。

其次，这种方法依赖于可能还没有的数据，这意味着如果你的产品或特性对时间很敏感，但相关数据还没有准备好，你可能需要选择另一种方法，或者推迟项目的截止日期。由于这种方法涉及到对多个因素进行评级，团队需要承担相应的决策责任，但目前还不清楚这个责任应该由谁来承担。是由整个团队共同作出决策，还是由产品负责人或经理单独决定，这个界限目前还比较模糊。

何时使用RICE方法：

虽然这是一种非常有效的技术，可以从多个方面全面了解产品，但它并不适用于所有的优先级设定情况。特别是对于那些已经发布并且已经开始其产品生命周期的应用程序，使用RICE方法进行评级是合适的，因为这时候你已经有了一些数据可以进行分析。然而，对于最小可行产品（MVP），由于缺乏足够的数据支持，使用RICE方法可能就不那么合适了。

4.Eisenhower矩阵：一种直接了当的时间管理方式

这种技术起源于Dwight D. Eisenhower的决策矩阵，后来转变成了一个四象限的可视化图表，一些团队用它来确定待办任务的优先级。这是一种简单直接的优先级确定方法，你可以立即使用，无需准备。

特征：

这个方法推荐将任务划分到一个四分图表的四个不同区域里。矩阵基于两个关键的优先级维度来进行考量——任务的重要性和紧迫性。

高优先级：这类任务既紧迫又重要。
中等优先级：这类任务重要但不紧急。这个区域还可以再细分为两部分：左边部分的任务优先级更高，应该优先执行。紧急但不重要：这里的任务虽然紧急，但对产品的商业层面影响不大，团队需要决定这些任务是否真的必要。这个区域也可以划分为两个部分，左边部分的任务优先级高于右边部分。
低优先级：这类任务既不紧急也不重要。

Eisenhower矩阵的优点：

这个矩阵结构简单，不需要复杂的层次构建，易于理解和应用。它是开放的，没有决策依赖和多种结果的变化，所以产品团队在决定哪个任务应该优先处理时，不需要担心会遇到一些潜在的问题。此外，这种方法以商业利益为中心，优先考虑那些从商业角度来看更加相关和有用的项目。

Eisenhower矩阵的缺点：

这个决策矩阵完全没有依据数据，不涉及任何计算、指标、KPI或其他可行的数据洞察，完全是基于直觉和判断来进行决策的。因此，团队内部可能会因为对某些任务的优先级判断不一致而出现误解或讨论。此外，由于这种方法主要关注产品的商业方面，可能会忽视产品的技术方面，这在一定程度上可能会影响产品的整体流程和性能。

何时使用：

Eisenhower矩阵可以应用于整个待办任务列表的优先级排序，但由于其本质上的简单性，它更适合用于个人时间规划。在使用这个矩阵进行整个产品管理时，前提是需要有一个更加强大和全面的方法作为支撑。如果没有这样的方法，交付团队就必须就所有任务的紧急性和优先级达成一致意见。

5.值与复杂度/努力矩阵：一种轻量级的方法来平衡技术和价值

价值与复杂度是产品经理用来对产品路线图上的功能进行评级的优先级原则之一。价值与复杂度（有时也用努力这个词）的方法采取了一种平衡业务和技术方面的发展的方法。

特点:

这个方法和Eisenhower矩阵相似，它通过两个维度——价值和复杂度——将任务分配到四个不同的区域中。首先，这个方法推荐优先处理那些“低挂的果实”，也就是价值高而复杂度低的任务。然后，它建议考虑实施那些价值高但复杂度也高的任务；对于那些价值低的项目，矩阵会质疑它们的重要性，并建议放弃那些复杂度高而价值低的任务。

价值这里的“价值”是由产品团队从长远的角度来评估一个任务或特性的重要性。而这个“价值”的标准是由团队自己设定的，而不是由这个方法强制规定的。判定价值的标准可能包括市场需求、吸引新客户的潜力、保持现有客户、提升客户参与度、预期的收入等方面。

而“复杂度”则是由产品团队估算出实现某个任务或特性所需要投入的总成本，并用这个成本作为衡量复杂度或所需努力的指标。另外，团队还可以根据不同的类别来对这个“努力”进行评分，比如运营成本、开发人员工作时间、项目日程、客户培训、潜在风险、内部开发能力等。

价值与复杂度/努力矩阵优点：

价值与复杂度/努力矩阵的好处在于，即使没有进行详细的计算，也能够使用。虽然这个矩阵推荐使用一些特定的指标，但并没有强制规定一定要这么做。如果没有足够的时间去详尽地界定价值和复杂度的指标，还是可以依靠大致的判断来评估的。

此外，这个方法的灵活性表现在可以自由设定价值的标准。同理，第二个维度也是可以根据需要自定义的。比如，可以根据项目的风险、成本、所需时间等因素来衡量复杂度，而不仅仅是单一的复杂度指标。

价值与复杂度/努力矩阵缺点：

价值与复杂度矩阵的不足之处在于它比较主观。因为它没有一个固定的评分标准，所以这个优先级定位的方式可能会引起一些争论。

而且对于那些功能众多的大型产品来说，并不是很适用。对于这类产品的大团队使用这种方法可能会花费很多时间，并且可能需要支付高额的协调成本。

何时使用

它更适合用在小型产品的团队中，尤其是在时间或预算有限的情况下，或者从头开始构建产品时。随着应用程序的成熟，你可能会用完低挂的果实，唯一的方法就是着手开发一些更大的功能。这时，这个矩阵就不再那么有效了。

6.加权最短作业优先（WSJF）：高效评估项目优先级的方法，虽精准但费时

加权最短作业优先是适用于中大型公司的SAFe精益敏捷框架的一个要素。这个方法指导团队通过计算每个功能的延迟成本与实施所需时间的比值来进行评分。它在基本理念上与价值与复杂度矩阵相似，但它给出了更为具体的操作指南。

特点：

延迟成本（CoD）。这是一个衡量如果没有实施特定功能，公司将遭受多少损失的指标。通常情况下，延迟成本由三个部分组成：

用户和商业价值 – 这个功能对商务和顾客的重要程度有多高？时间紧迫性 – 这个功能的用户和商业价值会不会随着时间的流逝而减少？风险降低 – 这个功能能否减少商业和技术上的风险？分配给这些变量的数值必须以1作为起始点，其余的数值相对于1来设定。

工作持续时间。工作的持续时间同样以相对值来衡量，用于定义完成工作所需的时间。

所以，你会得到以下公式：

WSJF = 延迟成本 / 工作持续时间

比率越高，优先级就越高。当这个比率计算出来之后，特性按照下列顺序被引入：

具有高附加值的非全面性特性。具有高附加值的复杂特性。具有较低附加值的非全面性特性。具有较低附加值的复杂特性。

加权最短作业优先法的优势确保精确性和一致性。通过更详尽的计算，利益相关方可以期待结果具有更高的一致性和可预测性。

专注于用有限的人力资源提高投资回报率。对于人力资源受限的团队来说，WSJF是非常有帮助的。

加权最短作业优先法的优势：

确保精确性和一致性。更细致的计算过程让那些关心结果的人能够期望到高度的一致和可预见的成果。

关注如何在人力资源有限的情况下提升投资回报。WSJF尤其对人手不足的团队来说十分有利。

加权最短作业优先法的不足：

计算过程耗时。因为WSJF需要为每个待办事项计算多个指标，这就意味着产品团队必须花费大量时间去确定每项任务的优先级。

限制了复杂的任务。如果有人有一个长远的商业计划，但是根据WSJF的计算结果这个计划不是那么紧迫，那么他们可能不得不将其搁置，这样一来，这种方法在实施长期计划时显得有些限制性。

相对规模的问题。虽然提到WSJF能带来精准和一致，但这仅在相对规模设定得当时才成立。要想平衡所有指标和假设是很难的，所以这种方法可能会有误差。

何时使用：

WSJF是一个很好的技术，用来评估和引入最小可市场化功能。但是，不应该总是依赖WSJF。比如，在产品中，有些功能是默认必须实现的，无需任何讨论。

7.行走的骨架：优先考虑MVP故事的最佳方式

行走的骨架方法是一种出现在21世纪初的产品特性优先排序手段。这个方法是由专门从事敏捷软件开发的专家AlistAIr Cockburn博士推广的。应用这种方法时，会确定在最小可行产品（MVP）中，哪些功能特性是产品运作不可或缺的。

特点：

这种方法不要求将需求分成特定的种类。但它有几个明确的特征，专注于用户的故事。

首先是关键功能。当采用行走的骨架法时，团队需要先排出必要的用户故事。

系统必须能够正常运行。这种方法注重实施必要的关键点，因此关键功能能组成一个全面可用的产品，不需要任何额外的功能。

反映出产品未来的商业理念。行走的骨架法强调展示商业价值。因此，故事地图会按顺序排列，即使在技术基础受限的情况下，也要展示出系统的核心元素。

并且进行了测试。行走的骨架法涵盖了全部的生产流程，包括产品的交付和部署，因此也包括了测试工作。

行走的骨架方法的优点包括：

快速决定优先顺序。这种方法对于那些需要快速确定产品核心特性的人来说是一个主要的优点，因为这个过程不会占用太多时间。
仅关注关键功能。在估算一个未来产品的商业价值时，专注于最核心的部分往往很有挑战性，因为很容易想要让产品尽可能地全面。行走的骨架法帮助避免了这个问题，它优先考虑最重要的、运作中的最小可行产品(MVP)。
快速市场反馈。这种方法最显著的优点之一是，它的优先级结果帮助快速获得用户反馈。这样，有关方可以评估产品与市场的契合程度以及商业理念的整体状况，并在之后的版本中进行调整。

行走的骨架方法的缺点包括：

缺少一些重要功能。尽管基本框架已经包含在内，但行走的骨架不会包含其他一些额外的但同样重要的功能，而这在某些情况下可能是关键的。
首次发布可能会延后。尽管行走的骨架是一个相对快速的设置优先顺序的方法，但第一版产品的发布并不会迅速，因为仍需确保产品的基本功能性。
可能会走捷径。在迫切想要尽快推出产品基本版本的情况下，可能会有忽略一些基础功能特性以加快发布的风险。因此，在进行优先级排序时，团队应专注于保持这些基本要素，避免为了快速推向市场而忽视它们，否则最初的、切实可行的产品版本就有变成不适合市场的原型的风险。

何时使用

在发布最小可行产品时，行走的骨架极为有用。这两者搭配使用可以提供切实的结果。然而，行走的骨架不是在交付更可持续、更复杂、具有众多额外特性或附加商业价值的产品时所依赖的。对于后者，利益相关者应该考虑更全面、更详细的东西。