MoSCoW优先级标识法详解：Must / Should / Could / Won't
MoSCoW 法源自软件开发中的敏捷与 DSDM（动态系统开发方法），是产品经理在 PRD 中嵌入优先级标识最经典、最易于沟通的方法之一。它将需求按交付紧迫性分为四类 —— Must、Should、Could、Won't —— 帮助团队在资源与时间约束下做出明确的取舍决策。
四类优先级定义
| 类别 | 全称 | 定义 | 验收标准关键词 |
|---|---|---|---|
| M | Must have | 本次发布不可或缺的需求，缺失则产品无法上线或核心流程断裂。 | 必须、强制、阻断 |
| S | Should have | 重要但可暂缓的需求；缺失不影响上线，但会显著降低用户体验或业务价值。 | 尽量、建议、重要 |
| C | Could have | 期望实现但非必须的需求，通常添加在资源富余时，属于“锦上添花”。 | 可选、有能力时 |
| W | Won't have | 本次明确排除的需求，不纳入交付范围，需在 PRD 中显式记录以避免未来反复讨论。 | 本次不包含、排除 |
场景案例：在线教育平台“作业批改”模块
假设你正在为在线教育平台设计“作业批改”模块，面临 8 项需求，资源仅够交付 5 项。使用 MoSCoW 法进行需求拆解：
- Must：教师上传作业、学生提交作业、教师评分并写评语 —— 核心闭环，缺一不可。
- Should：作业逾期自动标记、批改结果通知推送 —— 提升效率与体验，但可通过手动方式替代。
- Could：语音评语、评分统计图表 —— 增强功能，发布后可快速迭代。
- Won't：AI 辅助批改（本次不纳入，作为 V2.0 需求池保留）。
需求拆解要点：先识别 Must，再依次判断 Should、Could、Won't，避免“什么都要 Must”的倾向。建议与产品负责人、技术 Leader 共同完成优先级评审。
PRD 中应用格式
在 PRD 中，MoSCoW 不仅需要出现在需求表格中，还应融入需求描述的开头，形成可扫描的标识结构。推荐以下两种格式：
格式一：表格内嵌标签
在需求描述表格中增加“优先级”列，直接填写 M / S / C / W。颜色辅助（例如 M 用红色背景、S 用橙色、C 用绿色、W 用灰色）可在后续视觉化工具中配置，PRD 文字版中仅用字母标识即可。
格式二：需求标题前缀
将 MoSCoW 标识嵌入需求标题的开头，方便快速检索。例如：
[M-001] 教师上传作业（支持 PDF、图片）
[S-002] 作业逾期自动标记（DDL 后 24 小时触发）
[C-003] 语音评语（教师录制后以附件形式发送）
[W-004] AI 辅助批改（V2.0 需求池）建议同时维护一个“优先级矩阵对照表”作为 PRD 附录，记录每类需求的评估依据。
MoSCoW 优先级决策流程
下图为典型的需求拆解与优先级分配流程：
常见避坑提示
⚠️ 常见误区：
- “全部 Must”：如果 80% 以上的需求都标记为 Must，说明 Po 没有真正的优先级意识，需重新识别核心价值。
- “Won't 写得太少”：Won't 是保护团队精力的边界，应敢于排除，不要只写“未来考虑”。
- “颜色代替文字”：在 PRD 纯文本或协作工具中，颜色不一定被渲染，必须使用字母前缀或标签文本确保无障碍阅读。
交付物模板示例
在 PRD 的“需求清单”章节中，可直接嵌入如下结构的优先级标识表格：
| 需求编号 | 优先级 | 需求描述 | 验收标准 |
|----------|--------|-----------------------------------|---------------------------------------------|
| REQ-001 | M | 教师上传作业（支持 PDF/图片） | 教师可选择本地文件，上传后 3s 内生成预览 |
| REQ-002 | S | 作业逾期自动标记 | 超过截止时间 24h 后，状态变为“逾期” |
| REQ-003 | C | 语音评语 | 教师可录制 ≤60s 语音，学生端可直接播放 |
| REQ-004 | W | AI 辅助批改 | 本次不包含，详见 V2.0 需求池文档 |
通过以上格式，成员可以在 3 秒内识别每个需求的交付态度，减少反复确认成本。