MoSCoW 优先级法把一轮要做的需求分成“必须有、应该有、可以有、这次不会有”四级，用来在时间固定的前提下确定交付范围。它回答的是这一轮必须交付什么、哪些可以往后放，核心动作是强制取舍并控制总量。下面从四级含义、适用边界、操作过程、相邻方法区别和常见误解几个方面说明这套方法怎么用。
要点总览（TL;DR）
- MoSCoW 把需求分为 Must have、Should have、Could have、Won't have this time 四级，判断依据是需求在本轮交付中的必要性，而不是需求本身的价值高低。
- 它适用于时间盒固定、范围可调的场景，管的是需求对象排序，不负责产品功能整体布局，也不决定开发任务的执行先后。
- 操作上先定时间盒与产能，再逐条归类，最后核对 Must 总量；Must 超出产能时回到范围谈判，分级才真正产生取舍。
- Must 控制在总量六成左右是经验参考而非硬标准，合理比例取决于团队规模、需求不确定性和外部依赖。
- 常见误解包括把 Should 当 Must、把 Won't 理解为否决、只分级不核对产能；Won't 项应写明原因与复审时点。
MoSCoW 四级分别代表什么
MoSCoW 由四个英文词的首字母组成：Must have、Should have、Could have、Won’t have this time。四个级别描述的是需求在本轮交付中的必要性，而不是需求本身的价值高低。同一条需求在不同轮次里可能落在不同级别，判断依据始终是“这一轮”的时间盒和产能。
使用时，对每条需求依次问三个问题：缺了它本轮能否交付？有没有替代或临时绕行方案？在产能有余量时做它是否值得？三个问题的答案基本能把需求归入对应级别。
| 级别 | 含义 | 判断问题 | 典型处理方式 |
|---|---|---|---|
| Must have（必须有） | 缺失即视为本轮不可交付的必备项 | 没有它，本轮成果是否无法成立或无法上线？ | 优先排入范围，逐条核对产能 |
| Should have（应该有） | 重要，但存在替代方案或临时绕行办法 | 本轮不做，是否有可接受的替代或临时方案？ | 排在 Must 之后，产能允许时纳入 |
| Could have（可以有） | 有余量才做的加分项 | 做了更好，不做是否不影响本轮目标？ | 作为缓冲，产能有余时补充 |
| Won’t have this time（这次不会有） | 本轮明确排除，不等于永久否决 | 本轮为什么不做，何时重新评估？ | 记录原因与复审时点，移出本轮范围 |
常见经验是把 Must 控制在总量的六成左右，其余留给 Should 和 Could，以便应对估算偏差和临时变化。这个比例是参考值，不是硬标准；团队规模、需求不确定性和外部依赖不同，合理比例也会不同。判断是否合适，看的是 Must 是否真的缺一不可，以及剩余产能能否吸收变化。
它解决什么问题，又不包括什么
MoSCoW 适用于时间盒固定、范围可以调整的场景，例如固定周期的版本发布、有明确截止时间的项目阶段、需要在有限产能内确定交付内容的迭代。这类场景的共同点是日期或投入先定，做多少内容可以谈，方法正好提供了谈范围的共同语言。
它管的是需求对象的排序，不管产品功能的整体布局与取舍，也不决定开发任务的执行先后。功能要不要做、产品长期往哪个方向走，属于产品规划层面的判断；任务先写接口还是先做页面，属于排期与依赖管理。把 MoSCoW 用在这些问题上，会得到看似有结论、实际依据不足的分级。
它也不替代成本估算和价值量化打分。一条需求该归入哪一级，仍然需要工作量估算、收益判断和风险信息作为输入；MoSCoW 提供的是归类和取舍的框架，不提供计算过程。缺少这些输入时，分级容易变成凭印象贴标签。
在范围固定、日期也固定的强约束项目里，MoSCoW 的作用会受限。此时可调整的空间很小，方法更适合用来识别哪些需求属于真正的必备项、哪些可以在范围内做置换，并提前暴露“范围与日期无法同时满足”的矛盾，把问题摆到决策桌面上，而不是等到交付前才发现做不完。
四级分类是怎么落到一次排序里的
分级不是对着一份需求清单逐条打标签，而是一个先定约束、再归类、最后核对总量的过程。下面是一轮排序可以参照的步骤。
- 确定时间盒与可用产能。明确这一轮的起止时间、可投入的人力和必要的外部依赖，形成产能上限。没有这个上限，分级就失去了参照。
- 整理需求池。把候选需求写成可判断的条目，每条说明要解决的问题、大致工作量和提出背景，避免用一句口号代替需求描述。
- 逐条归类。用上一节的判断问题把需求归入 Must、Should、Could 或 Won’t，归类时记录判断依据，例如“缺少该能力则无法通过验收”“本轮可用现有流程临时替代”。
- 核对 Must 总量。把 Must 项的工作量加总，与产能上限比较。超出时回到范围谈判：把部分 Must 降级、拆分出最小可交付部分，或调整时间盒，三者选其一并留下记录。
- 为 Won’t 写明原因与复审时点。说明本轮排除的理由，约定下次评估的时间或触发条件，避免同一需求反复被提出又反复被搁置。
- 形成本轮范围基线。分级结果确定后作为本轮范围的基准，后续新增或变更需求走重新分级，而不是直接插入范围。
这个过程的关键在于总量约束。分级本身不产生取舍，只有把 Must 的总量与产能对齐，取舍才真正发生。若只分级不核对总量，四级标签就只是描述，无法阻止范围膨胀。
与打分排序、KANO、 Eisenhower 等方法的区别
MoSCoW 与几种常见排序方法回答的问题不同，混用时容易把不同维度的结论当成同一件事。下表按同一口径对照它们的差异。
| 方法 | 输出形式 | 主要判断维度 | 适用场景 |
|---|---|---|---|
| MoSCoW | 四个离散级别 | 本轮交付的必要性 | 时间盒固定、范围可调，需要明确本轮承诺 |
| 加权打分法 | 连续分值或排序 | 按多个评价维度加权计算 | 需要在较多需求间做相对排序，评价维度可量化 |
| KANO 模型 | 需求属性分类（如基本型、期望型、兴奋型） | 需求满足程度与用户满意度的关系 | 分析需求属性、规划产品体验方向 |
| 重要紧急四象限 | 四个象限 | 重要性与时间紧迫性 | 个人或团队的任务安排与时间管理 |
与加权打分法相比，MoSCoW 给出的是离散级别，结论直接对应“这轮做不做”；打分法给出连续分值，适合在候选较多时做相对排序，但分值本身不说明交付承诺。与 KANO 相比，KANO 分类的是需求属性，回答某类需求对满意度的影响方式；MoSCoW 分类的是本轮交付必要性，同一条基本型需求也可能因为已有替代方案而落在 Should。与重要紧急四象限相比，四象限的核心维度是时间紧迫性，MoSCoW 的核心维度是交付必要性，一条紧急需求未必是 Must，一条不紧急的需求也可能是 Must。
这些方法可以组合使用：先用 KANO 或打分法筛选出值得做的需求，再用 MoSCoW 在时间盒内确定本轮范围。组合时要注意保持维度分离，打分结果作为分级输入而不是直接换算成级别，避免把高分需求自动当成 Must，让分级失去强制取舍的作用。
一个具体例子与三个常见误解
假设一个团队要在四周内完成一次版本发布，可用产能约为人力的四周投入。需求池里有账号登录改造、报表导出、消息通知、界面主题切换、批量导入五项。分级过程如下：登录改造缺少则版本无法上线，归为 Must；报表导出重要，但本轮可先用现有导出方式临时替代，归为 Should；消息通知在产能有余时补充，归为 Could；界面主题切换本轮排除，归为 Won’t，原因是优先级低于核心流程，约定下个版本复审；批量导入依赖外部接口，本轮无法完成联调，归为 Won’t 并记录依赖方。核对总量时若 Must 已接近产能上限，就把 Should 中的报表导出进一步拆分，只保留最小可用部分。
这个例子里的分级结论都附带了判断依据，换一个时间盒或产能，结论可能变化，这正是 MoSCoW 按轮次判断的特点。
常见误解有三个。其一，把 Should 当 Must。提出者往往认为自己的需求很重要，于是逐条争取 Must，结果 Must 总量超出产能，分级退化为全员优先。纠正方式是回到判断问题：本轮不做是否有替代或绕行方案，有则归 Should。其二，把 Won’t 理解为否决或否定提出者。Won’t 只表示本轮不做，需要写明原因和复审时点，让提出者知道需求被记录、何时再议。其三，只分级不核对产能，四级标签贴完就结束，范围仍然随新增需求膨胀。纠正方式是把 Must 工作量与产能对齐作为分级完成的标志，超出即触发范围谈判。
分级结果如何在协作工具中承载
分级结论要在一轮交付中持续可用，需要落到团队日常查看和更新的地方，否则容易停留在一次会议的记录里。常见的承载方式有三类。
第一，在需求工作项上设置优先级字段，把四级结论写入字段，同时在描述或评论中保留判断依据，例如替代方案、依赖情况和估算工作量。这样任何人打开工作项都能看到这条需求为什么是这一级，减少重复讨论。ONES 的工作项可以承载需求条目及其属性信息，团队可据此记录分级结论和依据。
第二，用版本或迭代承载本轮范围基线。把本轮确定为 Must、Should、Could 的需求关联到同一个版本或迭代，形成可查看的范围清单；Won’t 项不放入本轮范围，但保留在工作项库中并注明复审时点，避免下次讨论时从零开始。ONES 提供迭代与版本相关的管理概念，可用于组织一轮交付的范围。
第三，范围变更触发重新分级与评审。新增需求或调整级别时，走一次简短评审：说明变更原因、对 Must 总量的影响、需要置换出哪些内容，评审通过后更新字段和范围清单。把变更记录留在工作项或相关文档中，下一轮复盘时可以直接回看分级是否准确、哪些判断需要修正。
这三类承载方式共同保证分级结果可查、可改、可追溯。工具承担的是记录与流转，分级判断本身仍依赖团队对产能和必要性的持续核对。
常见问题
Must 的比例控制在多少比较合适？
常见经验是把 Must 控制在总量的六成左右，其余留给 Should 和 Could，为估算偏差和临时变化留出缓冲。这个比例是参考值，不是硬标准。团队规模、需求不确定性和外部依赖不同，合理比例也会不同。判断是否合适，看两点：Must 是否真的缺一不可，剩余产能能否吸收变化。如果 Must 逐条都“很重要”，说明判断问题没有被认真使用，需要回到“本轮不做是否有替代或绕行方案”重新归类。
范围固定、日期也固定的项目还能用 MoSCoW 吗？
可以用，但作用会受限。这类项目可调整的空间很小，MoSCoW 更适合用来识别哪些需求属于真正的必备项、哪些可以在范围内做置换，并提前暴露“范围与日期无法同时满足”的矛盾，把问题摆到决策桌面上，而不是等到交付前才发现做不完。如果分级后发现 Must 总量已经超出产能，需要把范围、日期或投入中的某一项拿出来重新讨论，方法本身不提供额外的时间。
Won't have this time 和直接砍掉需求有什么区别？
Won’t 只表示本轮不做，不等于永久否决，也不否定提出者。处理时写明本轮排除的原因和复审时点或触发条件，需求保留在需求池中，下次评估时可以直接回看。直接砍掉则意味着需求不再进入后续讨论。保留 Won’t 记录的价值在于减少重复讨论：同一需求再次被提出时，团队可以基于上次的判断依据决定是否重新分级，而不必从零开始争论。
分级完成后，中途插入新需求该怎么处理？
分级结果确定后作为本轮范围基线，新增或变更需求走重新分级，而不是直接插入范围。具体做法是走一次简短评审：说明变更原因、对 Must 总量的影响、需要置换出哪些内容，评审通过后更新字段和范围清单。把变更记录留在工作项或相关文档中，下一轮复盘时可以直接回看分级是否准确、哪些判断需要修正。若新增需求确实属于 Must，就要同步降级或移出部分原有内容，保持总量与产能对齐。
MoSCoW 和打分法能一起用吗？
可以组合，但要注意保持维度分离。常见做法是先用 KANO 或加权打分法筛选出值得做的需求，再用 MoSCoW 在时间盒内确定本轮范围。打分结果作为分级的输入，而不是直接换算成级别。如果把高分需求自动当成 Must，分级就失去了强制取舍的作用，Must 总量会随打分结果膨胀。组合使用时，分级环节仍然要回到“本轮缺了它能否交付”的判断问题，并核对 Must 总量与产能是否匹配。
