2. 四类优先级详解：Must Have 的识别标准、风险与代价
Must Have（必须有）是 MoSCoW 框架中唯一不可妥协的优先级类别。若交付物中缺失任何一个 Must Have 项，整个交付即被视为失败。因此，明确识别标准、清醒认知风险与代价，是正确划定 Must Have 边界的核心能力。
2.1 适用场景
Must Have 判定适用于以下五类典型场景：
| 场景编号 | 场景描述 | 典型示例 |
|---|---|---|
| S1 | 法规与合规要求 | GDPR 数据脱敏、PCI-DSS 支付字段加密 |
| S2 | 核心业务路径闭环 | 电商下单→支付→库存扣减 |
| S3 | 系统安全基线 | 用户身份认证、API 鉴权中间件 |
| S4 | 无法绕过的最小可用集 | MVP 版本中的关键用户故事 |
| S5 | 强依赖上游接口 | 第三方 SDK 集成（无 workaround） |
2.2 前置条件
- 已确认项目愿景与核心度量指标：必须了解“不做会死”的底线是什么。
- 已完成用户故事地图或功能依赖图：明确功能之间的强依赖与串行链路。
- 已建立“一票否决”模型：团队就每个候选 Must Have 的失败后果达成一致。
- 已预留至少 15% 的缓冲时间：Must Have 不应因时间压力而被挤掉，缓冲保障其落地。
2.3 操作步骤
识别 Must Have 需执行以下 6 步流程（每一步的输入输出见 2.4 节）：
- 枚举候选功能清单：从需求池、用户反馈、合同条款中列出所有待定项。
- 施加“去掉后是否导致……”测试：对每项提问“若移除该项，项目是否仍能上线？用户核心任务是否仍可完成？”
- 标注外部强制约束：如法律、安全、行业标准要求的功能直接挂 Must Have 标签。
- 识别强依赖链：若 B 依赖 A，且 A 是 Must Have，则 B 自动升为 Must Have（除非 B 可通过手工操作替代）。
- 验证“最小可用集”完整性：将所有候选 Must Have 放入一个集合，检查是否覆盖完整用户旅程。
- 量化风险并表决：对每个候选 Must Have 评估“不实现的风险指数”（1-10），团队投票决定是否纳入。
判断口诀：
去掉能活吗？不能 → Must Have
去掉能用吗？不能（但有变通） → Should Have
去掉会被罚吗？会 → Must Have
去掉出 bug 但不致命？ → Could Have
去掉能活吗？不能 → Must Have
去掉能用吗？不能（但有变通） → Should Have
去掉会被罚吗？会 → Must Have
去掉出 bug 但不致命？ → Could Have
2.4 输入与输出物
| 流程节点 | 输入物 | 输出物 |
|---|---|---|
| 步骤 1～2 | 需求清单、用户故事地图 | 初筛 Must Have 列表 |
| 步骤 3～4 | 合规文档、依赖矩阵 | 受约束的 Must Have 子集 |
| 步骤 5 | 端到端用户旅程图 | 最小可行产品定义（Must Have 全集） |
| 步骤 6 | 风险登记册、投票记录 | 最终 Must Have 清单（含风险等级） |
2.5 责任边界
- 产品负责人（PO）：对 Must Have 的最终列表负责，必须能解释每个选项为何是“生死线”。
- 技术负责人：评估实现 Must Have 所需的技术栈、依赖与工期，并指出“隐性 Must Have”（如架构升级）。
- QA：确认 Must Have 的验收标准是否可测，且无模糊边界。
- 法务/合规：提供强制要求的输入，并对 Must Have 中的合规项签字确认。
2.6 记录材料
每项 Must Have 应在项目管理工具中保留以下记录字段：
ID: MH-001
名称: 用户登录 2FA 验证
说明: 所有访问财务模块的用户必须完成双因素认证
归类依据: PCI-DSS 第 8.3 条
风险指数: 9/10
移除后果: 法律罚款 + 数据泄露 > 50 万用户
关联依赖: 无（独立实现）
验收标准: 见 2.8 节
2.7 异常处理
| 异常场景 | 处理策略 |
|---|---|
| Must Have 数量超过交付能力 50% | 启动“强制去重”会议，逐条审查是否真的“不做会死”。通常 50% 的候选项会降级为 Should Have。 |
| 依赖项尚未就绪 | 将强依赖前置为 Must Have，同步引入风险缓冲或手工替代方案暂代。 |
| 团队对某个功能是否 Must Have 僵持不下 | 使用“后果沙盘推演”：画出移除该功能后用户的真实操作路径，如果出现死锁则强行纳入 Must Have。 |
| Must Have 在开发中期发现不可实现 | 立即上报变更控制委员会，评估重新谈判或切为 Should Have，并更新风险登记册。 |
常见陷阱：不要将“想做得好”当成“Must Have”。例如“动画加载效果”永远不会是 Must Have，即使它被 Stakeholder 要求。Must Have 只回答“没有它，系统是否可以安全上线且完成核心任务”。
2.8 验收标准
每一项 Must Have 必须满足以下验收条件方视为完成：
- 可测试性：有明确通过/不通过的标准，不含模糊表述（如“反应迅速”需改为“页面加载 ≤ 2 秒”）。
- 独立集成：该功能无需再过依赖即可独立验证。
- 回归覆盖：自动化测试覆盖其全部正常及异常路径。
- 合规签字：若涉及法规条款，需法务在验收单上签字。
- 用户确认：产品负责人代表用户确认功能达到“最低可用”程度。
典型的验收标准范本：
验收标准 - MH-001 用户登录 2FA 验证
1. 输入正确密码 + 有效 TOTP 令牌 → 登录成功，跳转主页
2. 输入正确密码 + 无效 TOTP 令牌 → 提示“验证码错误”，拒绝登录
3. 连续 5 次 TOTP 失败 → 账户锁定 30 分钟，发送告警邮件
4. 跳过 2FA 尝试 → 返回 403，客户端不得存储任何会话
5. 所有步骤在 Chrome/Firefox/Safari 最新版本上均通过
2.9 Must Have 识别结构图
下图展示了从候选需求到最终 Must Have 清单的识别路径及其风险传导关系：
图中红/橙节点代表高风险环节，绿色为依赖检查，青色为最终产出；每个环节的漏判都可能导致 Must Have 被错误降级，从而引发交付失败。