需求优先级排序是影响交付价值及研发团队交付速率的重要因素，当需求较少且简单的情况下，很容易根据“重要事情先做”的原则排序并达成共识，但是通常情况下，需求量大且复杂，我们不能仅仅依靠主观判断（拍脑袋）来决定需求的优先级顺序，除了指导原则，我们需要一些可以量化的工具，辅助我们对需求进行调整排序。

一、敏捷怎么说

1.主题法

需求和功能的表现形式很多，最终体现是能为客户或用户带来价值的产品或成果。那么对非常细节具体的需求点、用户故事进行优先级排序有时候可能很困难。

所以 Mike Cohn 建议是对“主题”进行优先级排序。将单个的用户故事和功能聚集到一些主题中，而这些主题都能分别独立地定义一组对用户或客户有价值的功能。这样，对主题进行价值的确认更为容易，进行优先级排序也就水到渠成。

确定优先级时通常会从4个方面考虑：

• 经济价值
• 所需成本
• 学习和获取知识的重要性和数量
• 风险

在其中，如何考虑风险，以及风险和价值之间的关系来排定优先级是一个难点。独立的只考虑追求价值或回避风险而进行优先级排序，都会带来很多问题。

所以要最优化地确定工作优先级，就需要同时考虑风险和价值。

下图中将风险和价值的关系映射到一个4象限模型中，通过进一步的分类和分析可以展示对功能的正确开发顺序：

对于高价值-高风险的功能：优先处理，即考虑到优先获得高价值回报，同时尽早进行处理可以有效消除显著的风险。

而高价值-低风险的功能：提供价值相当，但由于风险较低，可以稍晚进行。

低价值-低风险：排在第三位，放弃他们对产品总价值影响较小，风险也很低。

低价值-高风险：显然最好是避免开发，或尽可能推迟这上面的工作。

风险值是通过概率乘以影响计算的风险成本的估计值。

$Risk = Probability × Impact$

示例： 一个花费 $100，000 的项目，若有 15% 的失败机率. 风险值为？

$Risk = 100，000 × 0.15 = 15，000$

结合对知识学习和风险的考虑，产品负责人可以与团队一起坐下来评估及调整。 针对风险-价值矩阵，还需要持续监督，因为价值和风险随着项目进行是会动态变化的。

2.WSJF

著名的 Scrum大型架构 SAFE 的创始人 Dean Leffingwell 以反向以终为始的思维方式，不以客户的利益为导向，反过来以万一延迟了要付出多少代价来作预估，创新了另一种排序的依据，简称为 WSJF： Weight Short Job First 直接翻译就是"加权最短作业优先法"，用项目如果延期的时候要付出的代价来作加权数据的估算，公式如下：

$WSJF = 任务权重 / 任务时长$

估算任务时长

相对来说这两个参数中，任务的持续时长是比较好估算的，这个时长往往代表的任务的复杂程度（不考虑和其他任务的依赖）。

用 Cost of Delay 来估算任务权重

给出一个任务的权重是一个复杂且有争议的课题，但在产品开发领域，知名专家 Don Reinertsen 给出了一个衡量方式：

不同的人，从不同的角度，对同一件事情会得出不同的重要程度理解，这里我们推荐使用 Cost of Delay, 即 “延期成本 “来代表任务的权重。

Cost of delay 又该怎么确定

一般我们认为延期成本由 3 个因素组成：

1. 基于用户的商业价值
   • 我们的用户是不是真的非常想要这个？
   • 这个对我们业务的收入有什么影响？
   • 如果延误我们会收到什么样的惩罚和其他影响？
2. 时机关键性
   • 这个有确定的 deadline 吗？
   • 用户会为此等待我们还是会转移到其他的解决方案上去？
   • 有其他关键里程碑会被我们的延期影响吗？
3. 降低风险 / 增加机会的可能性
   • 这个能帮助我们降低未来发布的风险吗？
   • 它能帮助我们开启新业务领域的机会吗？

不管怎么样，我们的组织如果处在持续交付的状态，并且我们的需求池列表中有足够多的任务供选择，所以我们不需要纠结于每一个参数的精确值是否正确，我们只需要使用相对值的方式比较不同的任务，就像使用估算扑克那样。

对这个表中WSJF公式中的每个因子，采用与用户故事的故事点相对估算类似的方法做估算。比如，对于工作规模这一项，选择一个工作规模最小的特性作为基准，它的工作规模设为1，其他特性的工作规模与之相对比, 采用近似斐波那契数列1, 2,3, 5, 8,13, 20…为单位。如果特性A是基准特性的3倍，那么特性A的工作规模就是3。

WSJF 效果图例

基于 Cost of delay 的 WSJF 算法本质上就是让延期成本高，花费时间短的任务先被调度，从而降低整个系统的延期成本，下图一个基于 A、B、C 三个任务的示例图，上半部分是一个正面的列子，下半部分是一个反面的例子。

WSJF 提供了一套来确定需求列队顺序的算法，但是在实际工作中我们不需要关注是不是每个任务都能算出一个确定的值，进而进行排序。更重要的是我们需要理解这套算法背后的原理，并且当遇到争论和解释不清的时候可以利用这个算法帮助我们梳理自己的思路，尽快让大家找到共识。

二、其他常见方法

1.RICE 方法

RICE：评估优先级的四个因素

RICE 是评估每个项目的四个因素首字母缩写：Reach（接触数量），Impact（影响程度），Confidence（信心指数）和 Effort（投入精力）。

Reach（接触数量）

为避免因自己的使用习惯造成的偏差，请估计每个项目在一定时间段内会影响多少用户。对于我的团队来说，这意味着「一个季度内，有多少个用户会受到这个项目的影响」。

接触数量用每个时间段的用户数或事件数来衡量。这可能是「每季度客户数量」或「每月交易数量」。尽可能使用产品指标的实际测量结果，而不是随机去拍一个数。

举例：

• 项目 1：500 个客户每月在注册漏斗中达到此点，30％ 选择此选项。每季度的接触数量是 500×30％×3 = 450 个客户。
• 项目 2：每季度使用此功能的每个客户都将看到这一变化。每季度的接触数量是 2000 个客户。
• 项目 3：这一变化将对 800 个现有客户产生一次性影响，而且没有持续的影响。每季度的接触数量是 800 个客户。

Impact（影响程度）

要专注于那些能对你的目标产生可观影响的项目，预估这个项目对个人产生的影响。对于我的团队来说，这就是「当客户遇到这个项目时，能够提高多少转换率？」。你的团队可能会用另一个目标，比如「提高采用率」，或者「最大化满意度」。

影响程度难以准确度量。因此，我设置了一些选项来衡量：3 为「巨大影响」，2 为「高」，1 为「中」，0.5 为「低」，最后 0.25 为「最低」。我们在计算最后 RICE 得分时会乘以这些数字来按比例放大 / 减小。

选择一个数字来预估影响程度看起来可能不太科学。但是别忘了它替代的是另一种估算方式：拍脑袋。

举例：

• 项目 1：对于每个看到它的客户，这将产生很大的影响。影响程度是 3。
• 项目 2：这将对每个客户产生较小的影响。影响程度是 1。
• 项目 3：这在影响方面处于中间位置。影响程度是 2。

Confidence（信心指数）

有些主意非常激动人心但是并不明确，为了遏制住马上去实践它们热情，在评估时请把信心指数考虑进去（我们认为这个功能能实现 R 和 I 的自信程度）。如果你认为一个项目可能会产生巨大的影响，但没有数据可以支撑，那么信心指数会让你更有掌控力。

信心指数是一个百分比，我设置了另一种选项来避免决策瘫痪。 100％ 是「高信心度」，80％ 是「中等」，50％ 是「低」。比这更低的信心指数都可以认为是「登月计划」。对自己诚实一点：你的预估真的可靠吗，有多少论据支撑呢？

举例：

• 项目 1：我们有定量指标来衡量接触数量，有用户研究来证明影响程度，还有工程预估会投入的精力。这个项目的信心指数是 100％。
• 项目 2：我有数据支撑接触数量和投入精力，但我不确定项目的影响会是什么程度。这个项目获的信心指数是 80％。
• 项目 3：这个项目的接触数量和影响程度可能低于预期，需要投入的精力则高于预期。这个项目的信心指数是 50％。

Effort（投入精力）

为了迅速行动并且事半功倍，请估算项目需要团队的所有成员（产品，设计和工程）的总时间。

投入精力的预估单位是「人 / 月」 ： 一个团队成员可以在一个月内做的工作。这里有很多未知数，所以我用整数来预估（一个月以下的任何事情都用 0.5 来预估）。不像其他的积极因素，需要投入更多的精力是一件「坏事」，它会作为整体影响力的分母。

举例：

• 项目 1：这个项目需要约一周时间做计划，1- 2 周的设计和 2-4 周的研发时间。预估的精力投入是 2 人 / 月。
• 项目 2：这个项目需要几周时间做计划，大量的设计时间和一个工程师至少两个月的时间。预估的精力投入是 4 人 / 月。
• 项目 3：这只需要一个星期的计划，不需要新的设计，几周的工程时间。预估的精力投入是 1 人 / 月。

结合所有因素得到 RICE 分数

快速总结我们的四个因素：

• R 接触数量：这个项目会影响多少用户？ （在限定的时间内估计）
• I 影响程度：对每个用户的影响程度是怎样的？ （巨大影响 = 3x，高 = 2x，中 = 1x，低 = 0.5x，极低 = 0.25x。）
• C 自信指数：你对自己的预估有多少信心？ （高 = 100％，中 = 80％，低 = 50％）。
• E 投入精力：项目需要多少人 / 月？ （使用整数，最少为 0.5 人 / 月）

一旦你完成了这些因素的预估，把它们合并成一个单一的得分，这样你就能一目了然的比较不同项目的分数了。这是简单的公式：

可以用电子表单来记录：

一旦最初的评分完成，排序你的项目表单，并重新评估。有没有哪些项目的分数似乎太高或太低？如果是的话，重新考虑你的估算并做出调整，或者接受你的直觉可能是错误的。

在决定难以比较的项目想法时，RICE 可以提供极大的帮助。它迫使你思考为什么一个项目的想法会产生影响力，并且诚实地估计为达到目标所需的努力。

有效地使用 RICE

当然，RICE 分数不应该作为一个硬性规定。有很多原因可以让你先去做一个得分较低的项目上。一个项目可能是另一个项目的依赖项，所以它需要先发生，或者另一个项目可能是我们为了卖给某些用户的「赌注」。

有时你可能想要或者需要去做那些「无序」的项目。使用评分系统，你可以清楚地确定你什么时候可以做这些取舍。

2.BCG 矩阵分析（瘦狗金牛）

波士顿矩阵是由波士顿咨询公司创始人布鲁斯 · 亨德森于 20 世纪 60 年代首创，被视为企业战略策划时代的一个节点。作为分析企业成长（企业实力）与市场份额（市场引力）之间的关系的工具，它高度概括了企业战略决策的一般方法，最早用于分析企业的市场增长率和市场份额（市场占有率），又称为「市场增长率 - 相对市场份额矩阵分析、产品系列结构管理法等」。

虽然波士顿矩阵方法最初并非应用于互联网领域，但是后来经过变化升级，渐渐的开始在互联网领域应用。特别是在产品需求优先级的判断上。

产品层筛选

依据当前公司或者团队产品偏向，或者新的业务场景需求对于当前公司产品的增长率或者市场占有率影响性，初步区分需求池中真伪需求存在。此时，有些内容需求恐怕需要进行完整的报告文档，比较偏向战略层的决策，都是上层推动的。你的意见建议，必须拿出有力的证据，才可以让管理层认识到你的建议是对的。

例如在「易出行」（已隐去真实项目名称）中，当时涉及到几个新的业务场景接入的问题，涵盖扫码、维保、充电等，那么到底优先接入哪个场景的业务？关于战略层的决策，一般做为产品经理或者交互设计师，是没有权限参与的，除非你已经达到总监级别了。当时，比较看好的是维保和充电，主要是结合市场层热度以及结合我们内部项目主营业务来决定的。但是，却忽略了团队的资源配置以及所处阶段的更为重要的任务是抢占垂直市场，而不是去和其他已有实力的人抢份额。

当然，关于最终的建议和讨论是我们 UED 部分大佬去和老板说明的。但是关键点你是可以和老大去表明的。

产品功能层筛选

正如上图所示，对用户有价值的需求，一般属于用户需求；对公司有价值的需求，一般偏向产品需求。这个时候，就看一下，其需求的本质是偏向哪一种类型了。

明星功能需求

即对用户有价值，同时对公司也有价值的产品功能需求。可以既满足用户的部分需求，又可以实现产品的部分目标需求。和在企业规划中一样，处于双高级别，是优先级最高的需求。例如，在我们某一个场景的门店列表中是否增加导航入口这一功能，一方面，用户购买之后，可以快速方便的去到附近门店消费，一方面门店提升了营业额，对我们平台的信任度增加，这个功能就可以划归明星类产品需求。

问题功能需求

问题类需求虽然表面对公司没有直接的商业价值，但是从对用户价值角度而言，可以提升用户的满意度和忠诚度，综合来说，这类需求从本质上来说也是对公司有价值，只是不直接。之所以是问题需求，因为会随着时间或者业务变化，会变成明星需求或者现金牛需求，甚至会变为疯狗需求。最终走向，存在不确定性，有很大的风险。

例如，扫码挪车这个需求，这个是一个不高也不低的需求，但是对于用户而言，很多时候，又是一个非常必要的存在。特别是一二三线城市，因为各种原因，总有需要联系车主挪车的情况。它短期内，对于公司产品来说，其实算是一个鸡肋的功能，和主营业务没有强相关。但是对用户的确有价值的，所以，我们在前期推广的时候，很多人还是比较乐意注册，但是出现了一个小失误，就是没有处理好注册使用的流程限制门槛，比较繁琐。结果可想而知。

现金牛类需求，这类需求比较明显的自然就是对公司有明显的价值，但是从用户角度而言，多少会有一些负面影响。从理论上来说，应该尽量避免对用户体验造成不良的影响。但是，需要看公司产品的情况的。

例如，当前各种游戏非常火热，当然，似乎游戏一直都是比较热的。但是在你玩游戏的过程中，会常常引导你去看直播，这种体验，你应该不陌生。那么像是某易或 TX 为啥这么做呢？之前公众号也有文章说明，这种就属于现金牛类需求，公司的目的就是希望引流赚钱以盈利。

疯狗类需求，最后这种需求，就是和第一类需求相反的「双低」需求，也就是我们常说的伪需求。需要你判断出，并尽量去排除掉。

其实从以上几个需求类型的分类阐述，就可以看出对于问题类需求和现金牛需求，考虑的时候，需要多考虑一步。在产品成长初期，例如我们之前的「易出行」，获取用户增长和提升用户的留存率是第一要考虑的，那个时候，我们并没有去考虑如何去盈利。所以，问题类需求优先级高于现金牛需求。

但是如果产品处于稳定成熟期，例如，现在的很多超级 APP，公司的目标自然都是以提升盈利水平为第一要务，像是「拼多多、瑞幸」等。

3.KANO 模型

KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和排序的有用工具通过分析用户对产品功能的满意程度，对产品功能进行分级，从而确定产品实现过程中的优先级。

KANO 模型是一个典型的定性分析模型，一般不直接用来测量用户的满意度，常用于识别用户对新功能的接受度。

帮助企业了解不同层次的用户需求，找出顾客和企业的接触点，挖掘出让顾客满意至关重要的因素。

KANO 模型的需求分类

在 KANO 模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：基本型需求、期望型需求、兴奋型需求、无差异需求、反向型需求。

1）兴奋型需求

所谓暗处，用户意想不到的，需要挖掘 / 洞察。若不提供此需求，用户满意度不会降低；若提供此需求，用户满意度会有很大的提升。

当用户对一些产品或服务没有表达出明确的需求时，企业提供给顾客一些完全出乎意料的产品属性或服务行为，使用户产生惊喜，用户就会表现出非常满意，从而提高用户忠诚度。

这类需求往往是代表顾客的潜在需求，企业的做法就是去寻找发掘这样的需求，领先对手。

2）期望型需求

所谓痒处。当提供此需求，用户满意度会提升；当不提供此需求，用户满意度会降低。

它是处于成长期的需求，客户、竞争对手和企业自身都关注的需求，也是体现竞争能力的需求。对于这类需求，企业的做法应该是注重提高这方面的质量，力争超过竞争对手。

3）基本型需求

所谓痛点，对于用户而言，这些需求是必须满足的，理所当然的。当不提供此需求，用户满意度会大幅降低，但优化此需求，用户满意度不会得到显著提升。

对于这类需求，是核心需求，也是产品必做功能，企业的做法应该是注重不要在这方面减分，需要企业不断地调查和了解用户需求，并通过合适的方法在产品中体现这些要求。

4）无差异需求

用户根本不在意的需求，对用户体验毫无影响。

无论提供或不提供此需求，用户满意度都不会有改变。对于这类需求，企业的做法应该是尽量避免。

5）反向型需求

用户根本都没有此需求，提供后用户满意度反而下降。

总而言之，我们做产品设计时，需要尽量避免无差异型需求、反向型需求，至少做好基本型需求、期望型需求，如果可以的话再努力挖掘兴奋型需求。

KANO 模型的使用

KANO 模型分析方法主要是通过标准化问卷进行调研，根据调研结果对各因素属性归类，解决需求属性的定位问题，以提高用户满意度。

1. 明确目的

做之前，必须明白调研的目的是什么，是否合适用 KANO 模型解决，为什么要用 KANO 模型解决。

例如：企业为卖家开发的 CRM 工具，随着卖家客户的不断增长，CRM 系统中需引入一些新的功能满足其管理需求。而我们作为产品开发设计者，需要知道这些功能哪些是基本功能，哪些是增值功能，功能的优先级又该如何排列等等。

KANO 模型就可以帮助我们很好地贴合业务需求，从具备程度和满意程度这两个维度出发，将 CRM 中新增的功能进行区分和排序，从而知道：哪些功能是一定要有，否则会直接影响用户体验的（基础属性、期望属性）；哪些功能是没有时不会造成负向影响，拥有时会给用户带来惊喜的（兴奋属性）；哪些功能是可有可无，具备与否对用户都不会有大影响的（无差异因素）。

2. 设计问卷

此问卷调查表划分维度有两个：提供时的满意程度、不提供时的满意程度。

而满意程度被划分为 5 级（非常满意、满意、一般、不满意、很不满意），因为人的满意程度往往是渐变的，而不是突变的。

满意程度的文案可根据实际问题灵活修改，如使用（非常喜欢、理应如此、无所谓、勉强接受、很不喜欢 或者 非常有用、挺实用、无所谓、不实用、很不实用 ）更加形象的描述。

例如：在【通讯录】中，是否需要直接提供「拨打电话」的按钮？问卷设置正反两题：

为了更加形象且一目了然，我们可以如下设计。填问卷的人只需要在空白处打勾打叉就好了，非常方便。

设计问卷的过程中，有几点要注意：

• 问卷中的每道题都涉及到正反两面，应适当给予强调，防止用户看错（比如正反对立词字体加粗 / 标红等等）；
• 在设计问卷时，尽量做到清晰易懂、语言尽量简单具体，避免语意产生歧义；
• 选项给予说明：由于每个人对 “非常喜欢、理应如此、无所谓、勉强接受、很不喜欢” 等形容词的理解都不一样，所以最好有一个明确统一的说明，让用户可以有个对照，方便填写。

例如：

• 非常喜欢：让你感到满意、开心、惊喜。
• 理应如此：你觉得是应该的、必备的功能 / 服务。
• 无所谓：无所谓喜不喜欢，都可以接受。
• 勉强接受：你不喜欢，最好是没有，有的话就勉强凑活。
• 很不喜欢：让你感到不开心、甚至沮丧，无法接受。

3. 清洗数据

在收集所有问卷之后，注意清洗掉个别的明显胡乱回答的个例。如全部问题都选择 “我很喜欢” 或“很不喜欢”的，这种回答毫无参考价值。

4. 整理分类

为了能够将需求区分为基本型需求、期望型需求和兴奋需求，需按照正向和负向问题的回答对属性进行分类，具体分类对照下表。

当正向问题的回答是 “我喜欢”，负向问题的回答是 “我不喜欢”，那么 KANO 评价表中，这项功能特性就为 “O”，即期望型。

如果将用户正负向问题的回答结合后，为 “M” 或“A”，则该功能被分为基本型需求或兴奋型需求。其中，R 表示用户不需要这种功能，甚至对该功能有反感；I 类表示无差异需求，用户对这一功能无所谓。Q 表示有疑问的结果，一般不会出现这个结果（除非这个问题的问法不合理，或者是用户没有很好的理解问题，或者是用户在填写问题答案时出现错误）。

简单来说就是：

• A：兴奋型；
• O：期望型；
• M：必备型；
• I：无差异型；
• R：反向型；
• Q：可疑结果。

注意：以上对照表只是的最常见的一种归类方式。实际操作中，可因人而异，因产品、公司、地域而异（尤其是关于 “R” 和“O”的定义），因为满意度本身就难以衡量。

5. 量化表格

1）判断 KANO 属性

记录所有合理的数据，计算出各项占比，填写在下面的对照表里面。

从上表中不难看出，“通讯录中「拨打电话」“这个功能在 6 个维度上均可能有得分，将相同维度的比例相加后，可得到 6 个属性维度的占比总和。总和最大的一个属性维度，便是该功能的属性归属。

可看出 “在通讯录中提供「拨打电话」功能 “属于兴奋型需求。即说明没有这个功能，用户不会有强烈的负面情绪，但是有了这个功能，会让用户感受到满意和惊喜。

如果你只判断这一个需求，那么进行到这一步就可以到此为止了。如果涉及到多个需求的排序分级，你还需进行下一步。

2）计算 better-worse 系数

Better-worse 系数，表示某功能可以增加满意或者消除不喜欢的影响程度。

Better，可以解读为增加后的满意系数。Better 的数值通常为正，代表如果产品提供某种功能或服务，用户满意度会提升。正值越大 / 越接近 1，则表示用户满意度提升的效果会越强，满意度上升的越快。

Worse，可以叫做消除后的不满意系数。Worse 的数值通常为负，代表产品如果不提供某种功能或服务，用户的满意度会降低。其负值越大 / 越接近 - 1，则表示对用户不满意度的影响最大，满意度降低的影响效果越强，下降的越快。

因此，根据 better-worse 系数，对两者系数绝对分值较高的项目应当优先实施。

其计算公式如下：

• 增加后的满意系数 Better/SI=（A+O）/（A+O+M+I）
• 消除后的不满意系数 Worse/DSI= -1 *（O+M）/（A+O+M+I）

3）结果产出

例如：某产品希望优化 5 项功能，但是不知道哪些是用户需要的。通过 KANO 调研分析，可以分别计算出 5 项功能的 better-worse 系数。

根据 5 项功能的 better-worse 系数值，将散点图划分为四个象限，以确立需求优先级。

• 第一象限表示：better 系数值高，worse 系数绝对值也很高的情况。落入这一象限的因素，称之为期望型因素（一维因素）。功能 2 落入此象限，即表示产品提供此功能，用户满意度会提升，当不提供此功能，用户满意度就会降低。
• 第二象限表示：better 系数值高，worse 系数绝对值低的情况。落入这一象限的因素，称之为兴奋型因素。功能 1 落入此象限，即表示不提供此功能，用户满意度不会降低，但当提供此功能，用户满意度会有很大提升。
• 第三象限表示：better 系数值低，worse 系数绝对值也低的情况。落入这一象限的因素，称之为无差异因素。功能 3 落入此象限，即无论提供或不提供这些功能，用户满意度都不会有改变，这些功能点是用户并不在意的功能。
• 第四象限表示：better 系数值低，worse 系数绝对值高的情况。落入这一象限的因素，称之为必备型因素。功能 4 落入此象限，即表示当产品提供此功能，用户满意度不会提升，当不提供此功能，用户满意度会大幅降低；说明落入此象限的功能是最基本的功能。

在实际项目中：

• 我们首先要全力以赴地满足用户最基本的需求，即第四象限表示的必备型因素，这些需求是用户认为我们有义务做到的事情。
• 在满足最基本的需求之后，再尽力去满足用户的期望型需求，即第一象限表示的期望因素，这是质量的竞争性因素。提供用户喜爱的额外服务或产品功能，使其产品和服务优于竞争对手并有所不同，引导用户加强对本产品的良好印象。
• 最后争取实现用户的兴奋型需求，即第二象限表示的兴奋型因素，提升用户的忠诚度。

结论

根据 KANO 模型计算出的 better-worse 系数值，说明该产品先满足功能 5 和 4，再优化功能 2，最后满足功能 1。

而功能 3 对用户来说有或者没有都无所谓，属无差异型需求，并没有必要花大力气去实现。

总结

KANO 模型定义了三个层次的需求：基本型需求、期望型需求和兴奋型需求。

• 基本型需求：产品 “必须有” 的功能，也是 MVP 产品要求具有的功能；
• 期望型需求：非必须功能需求，但通常作为竞品之间比较的重点；
• 兴奋型需求：属于惊喜型产品功能，超出用户预期，往往能带来较高的忠诚度。

根据 KANO 模型建立产品需求分析优先级，运用到产品设计中就是要抓住用户的核心需求，解决用户痛点（基本型需求），抓住用户痒点（期望型需求）。在确保这两者都解决的前提下，再给用户一些 high 点（兴奋型需求）。

严格来说，KANO 模型并不是一个测量用户满意度的模型，而是对用户需求的分类，通常在满意度评价工作前期作为辅助研究的典型定性分析模型。

KANO 模型的目的是通过对用户的不同需求进行区分处理，了解不同层次的用户需求，帮助企业找出提高产品用户满意度的切入点，或者识别出使用户满意至关重要的因素。

但需求会因人而异，会因文化差异而不同；也会随着时间变化。可能前段时间的期望型需求，甚至兴奋型需求，到如今已变成了基础型需求。

所以，作为产品设计者，我们应该持续调研需求，对产品进行迭代优化。

4.MoSCoW 法则

莫斯科法（MoSCoW）是一种排列优先级的方法，在产品开发的时候用来决定哪些是最应该受到关注。其缩略词代表的是：

• Must have：必须有。如果不包含，则产品不可行。
• Should have: 应该有。这些功能很重要，但不是必需的。虽然’应该有’的要求与’必须有’一样重要，但它们通常可以用另一种方式来代替。
• Could have： 可以有。这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许就做，或者会挪到下一阶段再做。
• Won’t have：这次不会有。 最不重要，最低回报项目，或在当下是不适合的要求。 “不会有” 会被要求删除，或重新考虑。

这种方法与敏捷项目管理中进度安排的时间盒的方法密切相关。在每个时间盒（或冲刺）中，要对目标进行优先级排序，以便

• “必须具有”的要求是正在开发的系统的基础，没有这些需求，开发是行不通的；
• “应该具有”的要求很重要，但如果没有完成，可以有可替代方案；
• “可以具有”的要求在当前时间盒中并不重要，可以留到下一个时间盒；
• “想具有”是那些如果它们可以在当下这个时间盒里完成，就具有价值的要求，但预期它们要在后续的时间盒里才能完成。

5.四象限法则

现在在很多互联网公司，除了将四象限法则作为任务管理方法，还经常用来评估产品需求优先级。产品经理在实际需求管理中，评估需求时会将需求分类然后分别对应四个象限，最后得出需求优先级排序，并按照 P0、P1、P2、P3 依次标注。

1. 重要且紧急的需求

通常是线上产品故障，当前问题已影响用户正常使用需紧急修复，以及产品上线后与政策冲突，宣传文案与产品定义违背扭曲，产品监管有漏洞等严重影响公司品牌和产品利益的事情；

比如在放假期间，经常会看到微博因明星热点爆发导致服务器崩溃；受疫情影响，远程办公软件钉钉因高并发出现使用故障等，严重影响用户使用的事情，通常需要紧急优先处理。

2. 重要不紧急的需求

可以是对产品有重大改善的机会，甚至引领竞争对手的重大决策，也可以是一些对产品可以有显著改善的需求，可以增加产品亮点的需求；

但是因为市场上有竞品做类似功能，我们做了固然可以锦上添花，提升产品竞争力，但此类需求通常需要花费投入一定时间和精力，不会很快就上线，因此建议可以着重规划。

3. 紧急不重要的需求

可以定义为是用户在当下使用产品时遇到的一些小问题，可以快速解决，但又不足以影响他完成整个任务的且影响范围较少的需求点。如非功能性优化卡顿、信息流显示加载慢等，虽然在当下没有达到完美的操作预期，但是想想似乎又对整个产品造成的影响很少；

此类需求应根据实际情况安排计划完成，但不应作为需求规划的重点去重点关注，对于产品经理来讲，还是需要去挖掘和发现真正可以带来产品和用户价值的需求。如果现实中此类需求较多，可合理分配给团队成员或产品助力专员去跟进，同时自己要为结果负责。

4. 不重要且不紧急需求

此类需求既不影响正常功能使用，又无需现在立即完成的任务。如视觉排版略不完美、极限条件下发现的产品性能、交互问题，且同时没有用户反馈的需求点。

此类需求并不是说真的不重要，而是相对以上几种，这类需求优先级要靠后。因为对于用户来讲，产品可以实现的价值是可以为他们解决实际问题，因此他们更关注产品的可用性和易用性，因此此类需求可等到团队人力、资源充足时再安排跟进。

6.ICE 模型

• Impact：需求上线后的预期影响有多大；
• Confidence：需求成功的概率有多大；
• Ease：需求需要多少成本才能上线。

应用举例

[Mike Cohn 优先级排序主题分享][1]

[1]: https://www.jianguoyun.com/p/DVrB_ywQoKahChjIh70EIAA