第3章 验证计划模板：验证范围、验证方法、时间节点、风险预判
验证计划是原型验证工作的总纲，决定了“验证什么、怎么验证、何时验证、出问题怎么办”。本章围绕验证计划模板的四大核心要素展开，提供可直接套用的结构化框架和填写指南。
适用场景
- 项目启动阶段：首次原型完成后，需要制定系统化的验证方案时使用。
- 需求发生变更：原型功能调整或范围增减后，需同步更新验证计划。
- 迭代版本切换：从 Alpha 进入 Beta 或从 Beta 进入 RC 阶段，验证策略需重新校准。
- 跨团队协作：多个小组并行验证时，统一计划模板可降低沟通成本。
前置条件
- 需求文档或用户故事已通过评审并基线化。
- 原型设计稿或可交互原型已锁定版本。
- 验证环境（硬件、软件、数据）已准备就绪。
- 验证团队角色与职责已初步划分。
- 项目主计划已发布，关键里程碑时间点已确定。
操作步骤
- 界定验证范围：明确需要验证的功能集合、技术边界、数据域和排除项。
- 选择验证方法：根据范围特性匹配测试、评审、演示、走查或自动化检测等具体方法。
- 排布时间节点：将验证活动对齐项目里程碑，标注关键检查点和交付窗口。
- 开展风险预判：识别可能影响验证进度、质量或可信度的风险，提前制定缓解措施。
- 计划评审与签发：组织相关角色对计划草稿进行评审，修订后正式发布。
输入输出物
| 类型 | 名称 | 说明 |
|---|---|---|
| 输入 | 需求规格说明书 | 包含功能列表、用户场景、验收标准 |
| 输入 | 原型设计文档 | 含界面线框图、交互流程、设计标注 |
| 输入 | 项目主计划 | 提供整体时间轴与关键里程碑 |
| 输出 | 验证计划书（V1.0） | 包含四大要素的完整计划文档 |
| 输出 | 验证计划评审记录 | 记录评审意见、修订项与签发结论 |
责任边界
| 角色 | 职责 | 输出 |
|---|---|---|
| 产品经理 | 定义验证范围，确认功能优先级与排除项 | 范围清单 |
| 测试负责人 | 选择验证方法，设计测试用例框架 | 方法矩阵 |
| 项目经理 | 排布时间节点，协调资源窗口 | 时间轴 |
| 技术负责人 | 识别技术风险，制定应对预案 | 风险登记册 |
| 质量保证 | 监督计划执行，组织评审与签发 | 评审报告 |
记录材料
- 验证计划模板（电子版）：包含四大要素的标准空白模板，建议使用 Markdown 或 Confluence 格式维护。
- 验证计划评审纪要：记录评审日期、参会人、意见建议及采纳情况。
- 计划变更日志：每次计划修订时记录变更原因、变更内容和生效日期。
推荐做法：将验证计划模板纳入版本管理（如 Git），每次修订生成新版本号，确保团队始终使用最新版本。
异常处理
| 异常场景 | 处理方式 | 触发条件 |
|---|---|---|
| 验证范围频繁变更 | 启动变更控制流程，重新评审范围清单并更新计划 | 单周内范围变更 ≥ 2 次 |
| 选定方法与原型不匹配 | 召开技术评审会，替换为备选验证方法 | 方法在试点用例中失败率 > 30% |
| 时间节点严重滞后 | 压缩非关键路径验证项，或申请增加并行验证资源 | 滞后超过原计划 20% 工期 |
| 预判风险实际发生 | 激活对应缓解措施，通知所有干系人并更新风险登记册 | 风险等级达到“高”或“危急” |
关键提醒：异常发生后应在 24 小时内完成首次响应，并在 3 个工作日内将修订后的验证计划重新签发，避免验证活动空窗期。
验收标准
- 验证计划文档包含明确的 验证范围，且通过产品经理签字确认。
- 每项验证范围对应至少一种 验证方法，方法描述可执行、可度量。
- 所有 时间节点 与项目主计划对齐，且标注了检查点与交付物名称。
- 风险预判 列出至少 3 条具体风险，每条均有可操作的缓解措施和责任人。
- 计划已通过正式评审并获相关干系人签批。
质量门禁：任何一条验收标准未通过时，计划不得进入执行阶段，须在修订后重新评审。
验证计划模板四大核心要素关系图
图3-1 验证计划模板四大核心要素及子项关系。箭头表示从中心向外辐射的主结构，虚线弧表示要素之间的相互影响与迭代关联。