第1章 MoSCoW框架概述
1.1 定义与历史
MoSCoW优先级框架（MoSCoW Prioritization Framework）是一种用于需求排序与交付范围管理的决策工具，由 Dai Clegg 于 1990 年代在 Oracle UK 提出，最初应用于快速应用开发（RAD）方法论。随后被 DSDM（动态系统开发方法）采纳，并成为敏捷项目管理、产品路线图规划及传统瀑布项目中广泛使用的标准技术。
框架名称取自四个优先级分类的首字母组合：Must have、Should have、Could have、Won't have。中间的两个 "o" 仅为发音连贯而添加，无实际含义。MoSCoW 的核心价值在于帮助团队在固定的时间与资源约束下，做出清晰、可追溯的取舍决策，避免“所有需求都是最高优先级”的模糊状态。
1.2 核心原则
框架将需求划分为四个优先级等级，每个等级对应明确的交付承诺与决策逻辑。下表汇总了各等级的定义、含义与决策原则：
| 优先级 | 标签 | 定义 | 决策原则 |
|---|---|---|---|
| M | Must Have 必须做 |
缺失则解决方案无效，是交付的最低门槛。 | 如果没有该功能，项目无法上线或业务目标无法达成；不满足则不可发布。 |
| S | Should Have 应该做 |
重要且有价值，但存在可行的变通方案。 | 虽然很重要，但缺失时不至于使方案失效；可接受延期或替代实现。 |
| C | Could Have 可以做 |
锦上添花，提升体验或附加价值。 | 在资源允许的前提下纳入；缺失对核心交付无影响。 |
| W | Won't Have 不做 |
本次明确排除，但可纳入后续迭代。 | 主动排除，避免范围蔓延；需记录并知会干系人。 |
🔑 关键提示：MoSCoW 的强大约束在于 Must Have 的数量必须严格控制（通常不超过总需求的 20%~30%），否则框架会失去区分优先级的实际意义。
1.3 适用场景
MoSCoW 框架适用于以下典型项目与管理情境：
- 固定工期/固定预算项目：需要在时间与资源硬约束下做范围取舍时，MoSCoW 提供清晰的决策依据。
- 敏捷迭代与产品路线图规划：每个迭代或发布周期内，用 MoSCoW 确定本次交付的 Scope。
- 干系人期望对齐：当多方干系人提出大量需求时，通过分类拉齐各方对“必须做”的共识。
- 需求优先级评审会：在需求排期会、Sprint 计划会或变更控制委员会（CCB）中使用。
- MVP 定义：最小可行产品的范围界定，确保只包含 Must Have 项。
1.4 前置条件
在正式应用 MoSCoW 框架之前，团队和干系人需满足以下条件：
- 已明确项目目标、范围边界与关键约束（时间、成本、质量）。
- 已收集并初步整理需求列表（颗粒度建议为功能级或用户故事级）。
- 关键干系人（产品负责人、业务代表、技术负责人）已到位，并授权参与优先级决策。
- 团队对 MoSCoW 四个等级的定义与规则有统一理解（建议在首次使用前进行 30 分钟培训）。
⚠️ 常见误区：前置条件中“需求列表”尚未成形时，不要强行启动 MoSCoW 分类。缺乏完整需求清单会导致分类结果碎片化，后续频繁调整，丧失框架约束力。
1.5 操作步骤（概述级）
本章仅给出 MoSCoW 应用的五步宏观流程，后续章节将对每个步骤展开为详细 SOP。
- 准备需求清单：将待排期的需求/功能项整理为结构化列表，每项包含唯一编号、简要描述、预估工作量（可选）。
- 逐项分类：对每项需求，依据定义判定其属于 M / S / C / W 中的哪一个等级。
- 协商确认：与干系人及团队共同评审分类结果，解决分歧，达成一致。
- 制定交付计划：基于分类结果确定本次交付范围（Must Have 为必达目标，Should Have 为延伸目标）。
- 跟踪与复盘：在交付过程中监控范围变化，并在迭代/阶段结束时回顾分类准确性。
1.6 输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 需求管理 | 原始需求列表、干系人期望文档、项目目标与约束说明 | MoSCoW 分类矩阵（带优先级标记的需求清单） |
| 决策记录 | 分类初稿、干系人反馈、可行性评估数据 | 优先级决策日志（含分类理由、争议点、最终裁定） |
| 交付规划 | MoSCoW 分类矩阵、资源容量信息 | 本次交付范围基线（Scope Baseline） |
1.7 责任边界
| 角色 | 职责 | 决策权限 |
|---|---|---|
| 产品负责人 | 最终裁定需求优先级，对交付范围负责 | 批准 / 否决分类 |
| 需求分析师 / BA | 整理需求清单，准备分类建议，记录分类理由 | 建议权 |
| 开发团队 | 提供技术可行性评估、工作量预估 | 知情与建议 |
| 干系人（业务方） | 输入业务价值判断，确认分类是否符合业务期望 | 确认权（非否决） |
1.8 记录材料
每次 MoSCoW 分类活动结束后，应输出并归档以下记录：
- MoSCoW 分类清单：包含需求 ID、名称、优先级等级、决策理由、决策人、决策日期。
- 优先级决策日志：记录分类过程中出现的争议、讨论纪要及最终裁定结果。
- 干系人签字/确认记录：关键干系人对分类结果的书面或电子确认（邮件、审批流截图等）。
📌 实操建议：分类清单建议使用在线协同表格（如 Excel Online、Airtable、Notion）维护，便于多人实时编辑与版本追溯。每项需求的“决策理由”栏不要留空，至少填写一句话的业务或技术依据。
1.9 异常处理
在 MoSCoW 分类过程中可能出现的典型异常及处理预案：
- 分类争议：当干系人与产品负责人对某项需求的优先级存在重大分歧时，启动专题评审会，由产品负责人基于项目目标与约束条件做最终裁定，并记录在决策日志中。
- Must Have 数量超限：若 Must Have 占比超过 30%，要求业务方进一步拆分需求或重新审视项目目标，必要时申请增加资源或调整工期。
- 需求变更导致分类失效：当新增需求或原有需求发生重大变更时，触发“重新分类”流程，更新 MoSCoW 矩阵并通知所有干系人。
- 干系人缺席/不配合：由产品负责人与商务/项目经理协同，通过异步沟通（邮件、问卷）获取其输入，确保分类不因个别干系人延迟而阻塞。
1.10 验收标准
第1章作为概述，验收标准用于判断“框架理解与预备工作是否完成”：
- 能够准确复述 MoSCoW 四个优先级的含义与决策原则。
- 能够根据给定场景识别该场景是否适合使用 MoSCoW 框架。
- 已准备符合前置条件的需求清单与干系人角色表。
- 团队内对 MoSCoW 的等级定义与操作流程形成统一认知（建议通过本章后的 Quick Quiz 验证）。