MoSCoW 需求分级是什么
MoSCoW 把需求分为必须有、应该有、可以有与本次不做四档，用于固定时间盒内的范围协商。它的作用是让取舍显性化：在资源与时间受限时先保证必须有，把可以有留到后续。使用中最常见的失败是把几乎所有需求都标成必须有，分级随即失去意义，谈判空间也随之消失。
基本信息
| 必须有 Must | 不做则本次目标失败，占比需要受控 |
|---|---|
| 应该有 Should | 重要但可短期替代或延后 |
| 可以有 Could | 锦上添花，资源允许时补充 |
| 本次不做 Won t | 明确排除，避免反复讨论与持续期待 |
| 配套动作 | 与时间盒绑定，先定容量再定范围 |
典型使用场景
- 确定迭代容量后与业务方协商范围取舍
- 投标或外包合作中界定首期交付边界
- 年度计划里明确哪些需求本次不做，减少反复讨论
- 紧急上线场景下压缩范围，保留核心能力
- 多干系人提出大量需求时提供统一的讨论语言
范围协商示例
范围协商示例
# 必须有要与目标直接相关，否则分级会被滥用
Must：支付成功率监控（缺失则无法保障结算）
# 应该有要写替代方案，说明为何可以延后
Should：对账自动化（本期可用人工流程替代）
# 可以有的内容明确标注资源允许时再做
Could：报表样式优化（不影响业务流转）
# 本次不做要正式沟通，避免干系人仍期待交付
Won t（本期）：多币种，已在需求池另行登记分级判断与沟通
| 档位 | 判断问题 | 沟通要点 |
|---|---|---|
| 必须有 | 缺了本次目标是否直接失败 | 写清不可替代的理由 |
| 应该有 | 有无替代方案可支撑一段时间 | 说明替代方案与恢复时间 |
| 可以有 | 是否只是体验优化 | 声明资源允许时才做 |
| 本次不做 | 是否本期明确不投入 | 正式告知并登记到需求池 |
必须有占比过高是分级失效的信号：通常意味着缺少取舍讨论或目标定义不清，建议先确认本次目标与容量上限再重新分级。