第4章 功能维度验收标准：核心功能列表、优先级、完成定义
功能维度验收标准是MVP交付质量的基准线。它要求团队将产品愿景拆解为可执行的功能单元，并明确每个单元在MVP阶段必须达到的完成状态。本章围绕核心功能列表、优先级分级和完成定义（DoD）三个关键环节，提供标准化的设定流程与实操模板。
核心逻辑：功能列表定义“做什么”，优先级决定“先做什么”，完成定义回答“做到什么程度算完”。三者缺一不可，共同构成功能维度的验收基线。
适用场景
- 产品团队首次定义MVP范围，需要结构化梳理功能清单。
- 跨职能团队（PO、开发、测试）对“完成”标准存在理解分歧时。
- 项目面临交付压力，需要明确哪些功能必须达标、哪些可降级。
- 产品进入迭代验收阶段，需要统一的验收基线。
前置条件
- 已完成用户故事地图（User Story Mapping）或场景化需求拆解。
- 已明确产品愿景、核心目标及MVP阶段约束（时间、资源、质量）。
- 团队已对齐敏捷迭代节奏与验收流程。
- 具备可用的需求管理工具（如Jira、Confluence、Trello）。
操作步骤
-
用户故事映射与功能拆解
基于用户角色和关键场景，将用户故事按业务流程排列，识别出支撑MVP目标的最小功能单元。每个功能单元应具备独立的用户价值和可测试性。
产出物：用户故事地图（含主线、支线、MVP切分线）。
-
编制核心功能列表
从故事地图中提取MVP切分线以下的功能单元，整理为结构化清单。每个功能条目包含：功能ID、功能名称、关联用户故事、依赖关系、预估工作量。
产出物：核心功能列表（Epic / Feature 级别）。
-
优先级分级（MoSCoW 模型）
采用 MoSCoW 方法对功能进行分级：
级别 含义 MVP 处理策略 Must-have 必须包含，否则MVP无法交付核心价值 100%完成，不可降级 Should-have 应该包含，但可寻找临时替代方案 完成≥80%，明确例外清单 Could-have 可以包含，但不影响核心路径 尽力完成，不承诺 Won't-have 本次明确不包含 移出版本，记录待后续 产出物：功能优先级分级矩阵（含分级依据说明）。
-
设定完成定义（DoD）标准
为每个功能条目定义可量化的完成标准。DoD 应覆盖：代码实现、单元测试、集成测试、文档、UI/UX 适配、性能基线、安全合规。推荐使用检查表格式。
【DoD 检查表模板】 功能ID: F-001 | 功能名称: 用户登录 □ 前后端代码合并至主干分支 □ 单元测试覆盖率 ≥ 85% □ 集成测试通过（含异常场景） □ 操作手册/工具提示已更新 □ UI 适配 375px ~ 1920px 分辨率 □ 登录响应时间 ≤ 1.5s (P95) □ 无高危安全漏洞产出物：功能级 DoD 检查表（每个功能一条）。
-
验收标准对齐与确认
PO、开发负责人、测试负责人共同评审功能列表、优先级和DoD，确保三方对“完成”的理解一致。确认后的基线由PO签字并锁定变更流程。
产出物：功能维度验收基线（含三方签字确认记录）。
实操建议：在优先级分级时，可引入 RICE 模型（Reach, Impact, Confidence, Effort）对 MoSCoW 结果进行交叉验证，避免主观偏差。
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 需求 | 用户故事地图、产品愿景文档 | 核心功能列表（基线化） |
| 优先级 | 技术可行性报告、资源容量数据 | 功能优先级分级矩阵 |
| 质量 | 团队DoD公约、行业标准 | 功能级 DoD 检查表 |
| 验收 | 评审纪要进一步确认函 | 功能维度验收基线（签字版） |
责任边界
| 角色 | 职责 | 决策权 |
|---|---|---|
| 产品负责人（PO） | 编制核心功能列表、设定优先级、确认DoD业务价值 | 批准功能列表与优先级变更 |
| 开发团队 | 提供技术实现可行性、估算工作量、执行DoD技术标准 | 对DoD的技术可实现性有一票否决权 |
| 测试团队 | 审核DoD的可测性、补充测试场景、执行验收 | 对DoD的测试覆盖率提出建议 |
| 敏捷教练（SM） | 引导评审会议、确保流程合规、记录异常 | 对流程规范性有监督权 |
记录材料
- 核心功能列表模板：使用表格记录功能ID、名称、关联故事、优先级、DoD状态。
- 功能优先级分级矩阵：展示所有功能的 MoSCoW 分级结果及依据。
- DoD 检查表（单功能级）：每个功能对应一条检查表，逐项打勾确认。
- 功能维度验收基线确认书：包含PO、开发、测试三方签字栏和变更记录页。
常见陷阱：不要把 DoD 写成“开发完成”或“测试通过”这种模糊描述。DoD 必须包含可量化、可验证的条件，例如“接口响应时间 ≤ 200ms”、“单元测试覆盖率 ≥ 80%”。否则验收时容易产生争议。
异常处理
| 异常场景 | 触发条件 | 处理措施 |
|---|---|---|
| 功能列表膨胀 | 评审时新增超出MVP范围的功能 | 冻结当前列表，新增功能移入“待办池”，走变更控制流程 |
| 优先级争议 | PO与开发团队对Must-have判定不一致 | 重新对齐MVP目标，必要时引入用户调研数据辅助决策 |
| DoD标准过高 | 技术实现远超迭代周期 | 拆分DoD为“必须项”和“优化项”，MVP阶段只验收必须项 |
| 基线后需求变更 | 客户或市场要求紧急调整功能 | 启动变更评审，评估影响范围，更新功能列表与DoD |
验收标准（本章内容自检）
- 核心功能列表已覆盖MVP全部用户故事，无遗漏。
- 每个功能条目都有明确的 MoSCoW 优先级分级，且分级依据可追溯。
- 每个功能条目都有对应的 DoD 检查表，且检查项可量化、可验证。
- 功能列表、优先级、DoD 已经过PO、开发、测试三方评审并签字确认。
- 变更控制流程已建立，基线后的任何调整都记录在案。