需求优先级框架：MoSCoW、RICE、Kano 与价值成本矩阵

需求优先级框架：MoSCoW、RICE、Kano 与价值成本矩阵

需求收集之后，最难的一步是排序。Product School 提醒：你可以做任何事，但不可能做完所有事。优先级框架的意义，就是让团队在客户影响、业务目标、技术可行性与所需投入之间做出有依据的选择，避免"永远在追新功能"。

MoSCoW 法：给需求分四类

MoSCoW 是四个分类的缩写，特别适合向干系人解释"我们在做什么、为什么"：

• Must Have（必须有）：决定产品成败的功能，没有它用户无法获得价值，往往与盈利模式直接相关。
• Should Have（应该有）：重要但非必需，属于"第二优先"，通常是覆盖典型场景的增强项。
• Could Have（可以有）：锦上添花的"维生素"而非"止痛药"，多是集成与扩展。
• Won't Have（不会有）：不值得投入时间与精力去做的功能。

优点：简单，容易让非技术成员参与。缺点：很容易把太多需求塞进 Must Have，导致团队过载。

RICE 评分：用公式量化

RICE 由 Intercom 团队提出，用四个变量量化每个需求：

• Reach（触达）：一段时间内会受到影响的用户数，例如"每月会有多少客户使用这个功能"。
• Impact（影响）：对目标的影响程度，采用多选量表，如 3=巨大、2=高、1=中、0.5=低、0.25=极小。
• Confidence（信心）：对触达与影响评估的信心百分比，80% 以上为高信心，低于 50% 视为不合格。
• Effort（投入）：所需工作量，通常按月计算，需要设计师与工程师共同估算。

得分 = Reach × Impact × Confidence ÷ Effort。优点：用电子表格就能跑，过滤掉猜测与"嗓门最大的人"；缺点：需求很多时表格很长，对偏视觉思考的团队不够友好。

以某 SaaS 团队三个候选功能为例，假设团队统一了评分口径后打分如下：

单纯看得分，导出报表遥遥领先；多语言支持虽然触达最广、影响最高，但信心只有 0.4、要 4 个人月，折算后反而排第二。这正是 RICE 的价值——它把"直觉上很重要"的需求拉到统一的刻度上比较。同样重要的是 Confidence：如果某个需求的影响评估只有 50% 把握，它往往应该先做验证再决定优先级，而不是直接排进 Sprint。

Kano 模型：从用户满意度出发

Kano 模型（1980 年代由东京理科大学 Kano 教授提出）把功能分为三类：

• 基本功能（Basic）：用户最低预期，缺少则产品几乎无用，做得再好也不会显著提升满意度。
• 性能功能（Performance）：投入越多满意度越高，值得重点投资。
• 惊喜功能（Delighters）：超出预期的差异化点，会显著提升满意度，但会随时间推移逐渐降级为基本功能。

优点：从客户视角区分"必需"与"惊喜"；缺点：分类偏主观，且不直接考虑成本、上市时间与可行性。

价值-成本矩阵：快速可视化

把每个需求按"价值（对用户/业务的 Impact）"与"成本（开发 Effort）"放到二维矩阵中，落在四个象限：

• 速赢（Quick wins）：低成本高价值，优先做，带来增长。
• 大赌注（Big bets）：高成本高价值，潜力大但必须规划好。
• 填充项（Fill-ins）：低成本低价值，等其他重要事项完成后再做。
• 金钱陷阱（Money pit）：低成本高价值都不沾，对士气和财务都有害，应坚决避免。

优点：一眼可懂、可跨团队共享，适合需求不多时快速排序；缺点：需求很多时区分度不足，且容易低估"填充项"的实际耗时。

常见误区与选型建议

Product School 总结了几个高频错误：没有统一的评分标准（"影响 5 分"到底意味着什么）、把发现（discovery）与交付（delivery）混在一个待办里、受近因偏差影响而冷落旧需求、把过程搞得太复杂。建议：

• 用一套明确的评分指南，让"5 分"在团队里含义一致。
• 区分发现与交付两个待办列表，分别排序。
• 定期复查旧需求，过时即删除。
• 为优先级讨论设置时间盒，卡住时用先到先得作为平局规则。

选型上没有"最好"的框架，只有"对当前任务最合适"的框架：面向客户满意度选 Kano，需要数据化排序选 RICE，需要向干系人快速对齐选 MoSCoW，需求不多需要可视化选价值-成本矩阵。也可以组合使用，例如用 RICE 排序、用 MoSCoW 向管理层汇报。

16IDC 观察

对建站与 SaaS 团队，优先级框架的价值是把"我觉得重要"变成"我们有依据地排序"。排序结果会直接决定版本范围与资源配置，建议与技术栈评估联动：高优先需求需要可支撑的技术方案。日常协作工具的选择，可参考商业工具分类。更完整的需求分析流程，见本站需求分析分类。

原文来源：https://productschool.com/blog/product-fundamentals/ultimate-guide-product-prioritization
参考：MoSCoW 方法：https://en.wikipedia.org/wiki/MoSCoW_method；RICE 评分模型：https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/