3. Should Have 的价值判断与边界
Should Have 是 MoSCoW 框架中的第二优先级，代表“应该有”的需求。这类需求在核心路径之外，却能显著提升用户体验、业务价值或技术稳健性。本章围绕 Should Have 的价值判断标准与边界界定，提供可操作的 SOP 流程。
3.1 适用场景
Should Have 的价值判断流程适用于以下四类典型场景：
| 场景 | 说明 | 典型示例 |
|---|---|---|
| 版本规划 | 在发布窗口内对需求做二次取舍 | Sprint 中识别“可推迟但不应丢弃”的需求 |
| 需求评审 | 区分“必须做”与“应该做”的边界 | 功能评审会标记 Should Have 条目 |
| 资源受限项目 | 团队产能不足时保留高价值非核心需求 | 人力短缺时保留报表增强功能 |
| 产品路线图调整 | 中期规划中维持需求优先级梯队 | Q2 路线图将“批量导出”标记为 Should Have |
3.2 前置条件
执行 Should Have 价值判断前，必须满足以下所有条件：
- Must Have 清单已冻结 — 核心路径需求已确定且经过评审。
- 需求池完整可追溯 — 所有候选需求均有 ID、描述、提出方和初步评估。
- 业务目标已对齐 — 团队对当前迭代/版本的业务目标达成一致。
- 价值维度已定义 — 组织已定义用户价值、业务价值、技术价值的评估标准。
提示：前置条件不满足时，Should Have 的判定容易与 Must Have 混淆，建议先完成 Must Have 的确认再进入本章流程。
3.3 操作步骤
按照以下 5 个步骤执行 Should Have 的价值判断与边界界定：
- 筛选候选需求 — 从需求池中提取所有 未标记为 Must Have 且 有明确价值主张 的需求。
- 三维价值评估 — 对每个候选需求进行用户价值、业务价值、技术价值评分（1-10 分），取加权总分。
- Must Have 边界校验 — 逐条检查候选需求是否被误判：若缺失该功能导致核心流程中断或发布阻塞，则升级为 Must Have。
- Should Have 标记与归因 — 通过边界校验且价值总分 ≥ 6 分的需求标记为 Should Have，并记录价值归因。
- 时间窗口与可行性验证 — 确认 Should Have 需求在当前版本时间窗口内可完成；若不可完成，则降级为 Could Have 或移至后续版本。
核心原则：Should Have 是“有价值但非致命”的需求。判断时始终问：“没有它，用户能完成核心任务吗？” 若答案为“能”，则属于 Should Have 或更低优先级。
3.4 输入输出物
| 类型 | 名称 | 格式/载体 | 责任方 |
|---|---|---|---|
| 输入 | 需求池（未标记优先级） | 需求管理工具 / 电子表格 | 产品经理 |
| 输入 | Must Have 清单（已冻结） | 文档 / 看板列表 | 产品经理 + 技术负责人 |
| 输入 | 业务目标说明书 | PDF / 在线文档 | 业务方 / 产品总监 |
| 输出 | Should Have 清单（含价值评分与归因） | 需求管理工具 / 结构化数据 | 产品经理 |
| 输出 | 价值评估矩阵 | 电子表格 / 数据库 | 产品经理 + 技术负责人 |
输出数据示例（需求条目记录格式）：
[
{
"id": "REQ-0042",
"title": "订单详情页推荐相似商品",
"priority": "Should Have",
"valueScores": {
"userValue": 8,
"businessValue": 7,
"techValue": 5
},
"weightedTotal": 7.2,
"rationale": "提升客单价，非核心交易路径",
"versionTarget": "v2.3"
},
{
"id": "REQ-0047",
"title": "批量导出报表为 Excel",
"priority": "Should Have",
"valueScores": {
"userValue": 6,
"businessValue": 8,
"techValue": 4
},
"weightedTotal": 6.8,
"rationale": "运营效率提升，不影响核心功能",
"versionTarget": "v2.3"
}
]3.5 责任边界
| 角色 | 责任内容 | 决策权限 |
|---|---|---|
| 产品经理 | 组织价值评估，维护 Should Have 清单，协调边界争议 | 最终标记 Should Have；争议时升级至产品总监 |
| 技术负责人 | 提供技术可行性评估、工作量估算 | 对“时间窗口内是否可完成”有一票否决 |
| 业务方 | 提供业务价值输入，确认需求归因 | 对业务价值评分有建议权，无最终决策权 |
| 测试负责人 | 评估 Should Have 需求的测试风险 | 对“测试资源是否充足”给出建议 |
常见误判：产品经理容易将高价值需求直接标记为 Must Have。此时技术负责人应主动质疑：“移除该需求是否真的导致发布阻塞？” 以此校准边界。
3.6 记录材料
本章流程需要维护以下 4 份记录材料：
- Should Have 需求登记表 — 包含需求 ID、标题、三维价值评分、加权总分、归因说明、目标版本。
- 价值评估矩阵（主表） — 横轴为需求 ID，纵轴为用户/业务/技术价值，对应评分及权重。
- 边界校验日志 — 记录每个需求在“Must Have 边界检查”环节的判定理由，特别是升级或降级的情况。
- 版本窗口可行性确认单 — 技术负责人签署的 Should Have 需求在版本内可完成的确认记录。
3.7 异常处理
| 异常场景 | 触发条件 | 处理方式 |
|---|---|---|
| Should Have 数量过多 | 超出团队产能的 30% 以上 | 按价值总分降序排列，截断部分降级为 Could Have |
| Should Have 与 Must Have 边界模糊 | 多次评审仍无法达成一致 | 升级至产品总监裁定；引入用户测试数据辅助决策 |
| Should Have 在开发中途被要求升为 Must Have | 业务方提出紧急变更 | 启动变更评审流程，评估影响后重新冻结优先级 |
| 时间窗口验证不通过 | 技术负责人判定无法在版本内完成 | 自动降级为 Could Have 或移至下一版本清单 |
| 价值评分严重分歧 | 同一需求各维度评分差异超过 5 分 | 组织专题评审会，重新对齐评分标准后复评 |
3.8 验收标准
以下 5 项全部满足时，本章节流程方可视为完成：
- AC-1 — 所有 Should Have 需求均经过三维价值评估且总分 ≥ 6 分。
- AC-2 — 每个 Should Have 需求均通过 Must Have 边界校验，并记录“不属于 Must Have”的判定理由。
- AC-3 — Should Have 清单已与技术负责人确认版本时间窗口可行性，且获得书面确认。
- AC-4 — 价值评估矩阵、边界校验日志、版本窗口确认单三份记录材料已归档至项目知识库。
- AC-5 — 所有异常场景均按 3.7 节处理完毕，无遗留争议项。