4. 四类优先级详解：Could Have 的意义与限制
Could Have（应有）位于 MoSCoW 框架的第四优先级，代表“如果有时间就做”的需求类别。这类需求对项目交付成功不构成关键影响，但一旦实现能为用户或业务带来额外价值。Could Have 是项目弹性空间的主要来源，也是团队应对范围变更的“缓冲带”。理解它的真实意义与内在限制，是正确使用该优先级的前提。
4.1 适用场景
下列场景中，需求适合被标记为 Could Have 优先级：
| 场景类别 | 具体说明 | 示例 |
|---|---|---|
| 增强型功能 | 在核心功能完整后可提升体验，但非必需 | 报表导出为 PDF 格式 |
| 低使用率需求 | 仅少数用户会用到，价值可量化但不高 | 高级筛选条件组合 |
| “锦上添花”特性 | 能提升满意度但不影响业务目标达成 | 仪表盘主题切换 |
| 实验性功能 | 需要验证假设，可接受延迟或取消 | AI 智能推荐预览 |
| 合规/审计冗余 | 超出最低合规要求，但可优化流程 | 操作日志可视化面板 |
核心判断标准：如果该需求被移除，项目是否仍能正常交付核心价值？若答案为“是”，则属于 Could Have 候选。
4.2 前置条件
使用 Could Have 优先级前，必须满足以下条件：
- 已锁定 Must Have 与 Should Have：前两个优先级的需求已明确定义并获得干系人确认。
- 有明确的“时间盒”边界：团队知道可用总工时或交付截止日期，能判断“是否有时间”。
- 干系人对“不交付无风险”达成共识：所有关键干系人理解 Could Have 需求可能被移除，且不会影响项目验收。
- 建立了需求价值量化标准：至少能用“用户覆盖数”“效率提升分钟数”“满意度分值”等指标粗略评估价值。
4.3 操作步骤
将需求正确归类为 Could Have 并管理其生命周期，遵循以下四个步骤：
- 识别候选需求——从需求池中筛选出“非关键但有价值”的条目，使用
优先级初筛清单标记。 - 评估实现成本与价值——对每个候选需求估算开发工作量（人/天）与预期业务价值（低/中/高），填入
需求价值评估表。 - 正式标记并排序——在需求管理工具中将优先级字段设为
Could Have，并按价值/成本比从高到低排序。 - 设定交付阈值——明确“在什么剩余工时条件下启动 Could Have 任务”，例如
剩余工时 > 20% 总工期时开始排入迭代。
4.4 输入输出物
| 方向 | 物项名称 | 格式 / 载体 | 说明 |
|---|---|---|---|
| 输入 | 需求池（未分级） | Excel / Jira / 飞书表格 | 包含所有待评估的功能需求 |
| 输入 | Must Have / Should Have 已确认列表 | 需求优先级矩阵 | 已确定的关键需求清单，用于对比排除 |
| 输入 | 项目工期与资源预算 | 项目计划书 | 明确可用总人天与交付截止日 |
| 输出 | Could Have 需求清单（已排序） | Jira 筛选视图 / 分级表格 | 按价值/成本比从高到低排序 |
| 输出 | 交付阈值声明 | 迭代计划文档 | 写明“剩余工时 > X% 时启动”等规则 |
| 输出 | 风险登记册（Could Have 相关） | 风险管理表 | 记录可能被升级为 Should 的候选及触发条件 |
4.5 责任边界
- 产品经理：负责识别 Could Have 候选需求，组织价值评估，并与干系人就“不交付无风险”达成书面共识。
- 项目经理：设定并监控交付阈值，确保 Could Have 任务不挤占 Must / Should 资源，更新风险登记册。
- 开发团队：在满足阈值的前提下，按排序依次实现 Could Have 需求；工时紧张时主动提出暂停。
- 干系人 / 客户：确认并接受 Could Have 需求可能被推迟或取消，不将其作为验收硬性条件。
最佳实践：在迭代回顾中专门检查“Could Have 实现率”，若连续两个迭代实现率为 0%，应重新评估前置的 Must / Should 是否过多，或需求池分类是否准确。
4.6 记录材料
以下记录材料必须归档并保持更新：
- 需求价值评估表（含需求 ID、描述、价值评分、工作量估算、价值/成本比）
- Could Have 排序清单（按优先级排序，标注当前状态：待排期/开发中/已完成/已移除）
- 交付阈值配置记录（包含设定日期、阈值规则、审批人）
- 风险登记册（Could Have 相关条目）（含风险描述、概率、影响、触发条件、应对措施）
4.7 异常处理
常见异常与应对方案
| 异常现象 | 根因分析 | 处理措施 |
|---|---|---|
| 干系人将关键需求标记为 Could Have | 对优先级定义理解不一致，或有意“隐藏”强需求 | 重新执行需求分级对齐会，使用 MoSCoW 定义卡 校准理解；若仍争议，升级至项目发起人决策 |
| Could Have 需求从未被排入迭代 | 交付阈值设定过高，或 Must / Should 估算不准确 | 审查迭代容量计划，调整阈值（如从 25% 降至 15%），或缩短迭代周期以释放时间盒 |
| 大量 Could Have 在交付前被强制升级为 Should | 前期需求分析不充分，或业务环境发生重大变化 | 触发变更控制流程，重新平衡整个优先级矩阵，并调整项目基线 |
4.8 验收标准
本章节内容是否被正确应用，通过以下标准检验：
- 标准 1：需求池中所有 Could Have 条目均有明确的价值/成本评分，并按排序展示。
- 标准 2：项目计划文档中包含了书面的交付阈值声明，且团队全员知晓。
- 标准 3：在任意迭代中，Could Have 任务占用的总工时 ≤ 剩余可用工时的阈值上限。
- 标准 4：风险登记册中 Could Have 相关风险项已识别并指定了责任人。
- 标准 5：无干系人在验收阶段将 Could Have 需求作为“必须交付”的缺陷提出。