MoSCoW优先级管理
敏捷开发中用于需求优先级排序的经典框架，将需求分为Must have/Should have/Could have/Won’t have四类，帮助团队在每个版本中明确”必须做”和”可以不做”的边界
简介
MoSCoW是由Dai Clegg在敏捷开发中推广的需求优先级排序方法，其名称取自四个优先级首字母的组合。该方法的核心价值在于：强制团队在每个版本中做出明确取舍，将有限资源集中在最关键的需求上。与KANO模型（判断需求类型）和RICE评分模型（量化评估）不同，MoSCoW解决的是”这个版本我们做什么、不做什么”的排期决策问题。
关键信息
- 类型：方法论 / 优先级框架
- 领域：产品管理、敏捷开发、项目管理
- 提出者：Dai Clegg（敏捷DSDM框架）
- 核心问题：如何在有限版本资源下，明确需求的优先级边界
- 四个优先级：Must have / Should have / Could have / Won’t have
核心特性
四层优先级定义
| 优先级 | 含义 | 说明 | 建议占比 |
|---|---|---|---|
| Must have | 必须有 | 没有这个功能产品无法上线或版本无法交付。这是版本的”最低门槛”。 | 约20% |
| Should have | 应该有 | 很重要但可以推迟到下一版本。如果资源允许就做，不允许就先保证Must。 | 约30% |
| Could have | 可以有 | 有比没有好，但影响不大。资源充裕时才做，通常是”锦上添花”类功能。 | 约30% |
| Won’t have | 这次不做 | 明确放弃，放到后续版本或Backlog中。一定要记录在案，避免同样问题反复讨论。 | 约20% |
使用MoSCoW的关键纪律
Must have ≠ “所有功能”：最常见的误用就是把一堆需求全部标成Must。Must应该是经过严格筛选后”没有就真的不行的那一小撮”。如果Must占比超过30%，通常意味着没有真正的优先级判断。
Won’t have必须记录：明确说”这次不做”的需求需要有记录，否则每次迭代都会被重新提出来讨论，浪费团队精力。一个清晰的Won’t列表和Must列表同样重要。
动态调整：一个需求在上个版本的Should，可能在收集新数据后变成这个版本的Must。优先级不是一成不变的。
MoSCoW与KANO模型的配合
KANO模型判断需求属于基本型/期望型/兴奋型/无差异型/反向型，而MoSCoW决定在当前版本做不做：
- KANO模型的基本型需求 → 通常对应MoSCoW的Must have
- KANO模型的期望型需求 → 通常对应Should have或Must have（根据竞争压力）
- KANO模型的兴奋型需求 → 通常对应Could have（有余力时加入）
- KANO模型的无差异型/反向型 → 直接进入Won’t have
MoSCoW与RICE的配合
RICE评分模型给出量化的优先级分数，MoSCoW将分数映射到具体版本的排期决策：
- RICE高分 → 倾向进入Must或Should
- RICE中分 → 倾向进入Should或Could
- RICE低分 → 倾向进入Could或Won’t
不同素材中的观点
怕浪猫将MoSCoW作为产品经理需求优先级评估的三个核心框架之一（与KANO和RICE组合使用），强调：
- 每个版本都需要有清晰的Must列表，确保核心功能完整
- Should和Could可根据资源灵活调整
- Won’t需要有明确记录，避免同样的问题反复讨论
- 建议占比约20%:30%:30%:20%作为参考，具体比例根据版本目标调整
实用信息
基本用法
- 列出所有候选需求：从需求池中提取当前版本相关的需求
- 逐项判定优先级：每个需求对照”如果不做会怎样”——无法上线的归Must，影响较大但可推迟的归Should，锦上添花的归Could，不相关的归Won’t
- 资源匹配检查：检查Must和Should是否符合当前版本的人力/时间预算
- 记录Won’t：将Won’t的需求记录在案并标注原因
适用场景
- 敏捷开发的Sprint/迭代规划
- 产品版本规划
- 项目启动阶段的Scope定义
注意事项
- Must占比不应超过30%，否则说明没有进行真正的优先级判断
- Won’t需求必须有记录和说明，避免”反复提案反复否决”
- 优先级是动态的——每次迭代重新评估