第4章：前置条件清单——原型就绪标准、需求文档对齐、角色准备、环境要求
适用场景
本章节适用于以下评审环节启动前的准备阶段：
- 需求原型边界确认评审——需要确认原型与需求文档是否已对齐、参与角色是否到位、演示环境是否可用。
- 跨团队联合评审——涉及产品、开发、测试、业务方等多角色协作时，前置条件清单用于统一入场标准。
- 远程/分布式评审——当评审成员分布在异地时，环境要求与角色准备需要提前逐项核验。
- 迭代增量评审——在敏捷迭代中，每次增量交付的原型都需经过前置条件检查方可进入正式评审。
前置条件
使用本清单前，需确认以下元条件已满足：
| 元条件 | 说明 | 验证方式 |
|---|---|---|
| 原型已冻结 | 当前评审版本的原型页面已停止修改，且经过内部评审团队自检。 | 版本号 + 冻结签章 |
| 需求文档已定稿 | 与原型对应的需求文档已完成终版审核，变更记录已关闭。 | 文档修订记录 |
| 角色通知已发出 | 所有必需角色已收到评审邀请并确认出席。 | 会议邀请回执 |
| 环境预测试通过 | 演示环境、评审工具、网络连接已完成预检，可正常使用。 | 环境预检报告 |
关键原则：前置条件检查不是走过场，而是评审质量的第一道防线。元条件缺失时，不建议跳过检查直接进入评审。
操作步骤
按照以下 4 步检查流程 逐项核验前置条件：
-
核验原型就绪标准
- 检查原型交互流程是否完整覆盖所有用户场景（含主路径与异常路径）。
- 确认视觉稿是否遵循设计规范（色彩、字体、间距、组件库）。
- 验证标注是否清晰可读（尺寸、状态、交互说明、跳转逻辑）。
- 记录不符合项并标记为
待修复或阻塞项。
-
对齐需求文档
- 比对原型版本号与需求文档版本号是否一致（精确到次版本号）。
- 核查所有需求条目是否可追溯到原型页面（需求 ID ↔ 页面 ID）。
- 确认最近一次变更已同步至所有相关文档，并在变更日志中记录。
- 检查需求优先级标注是否清晰（P0/P1/P2）。
-
确认角色到位
- 确认产品经理（需求负责人）已到场或在线。
- 确认开发代表（技术可行性评估）已准备就绪。
- 确认测试代表（用例设计与验收标准）已参与。
- 其他角色（设计师、业务方、运维等）按需通知并确认。
-
检查环境要求
- 评审工具（在线白板 / 原型演示工具 / 会议系统）已打开且权限正常。
- 演示环境（原型可交互版本 / 模拟数据）已部署并可操作。
- 网络条件（带宽 / 延迟 / 远程接入）满足流畅演示需求。
- 投影或共享屏幕已就绪，分辨率适配正常。
效率建议：将上述 4 步整合到一份
前置条件检查表 中，由评审主持人统一逐项勾选，避免遗漏。
输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 原型相关 | 原型文件（含交互稿、视觉稿、标注稿） | 原型就绪检查报告（通过 / 待修复 / 阻塞） |
| 文档相关 | 需求说明书（含版本号、变更记录） | 需求文档对齐确认表（已对齐 / 有偏差） |
| 角色相关 | 评审会议邀请 + 角色名单 | 角色到位确认回执（全员确认 / 有缺席） |
| 环境相关 | 环境预检清单（工具 / 网络 / 数据） | 环境预检通过报告（通过 / 需整改） |
| 综合 | 以上四份输入物 | 前置条件总清单（四维状态一览） |
责任边界
| 角色 | 职责 | 交付物 |
|---|---|---|
| 评审主持人 | 统筹前置条件检查，组织逐项核验，判定是否满足入场标准。 | 前置条件总清单（签字） |
| 产品经理 | 提供原型与需求文档，确保版本一致、标注清晰、需求可追溯。 | 原型就绪检查报告 + 需求对齐确认表 |
| 开发代表 | 评估原型技术可行性，确认开发资源可支撑当前方案。 | 技术可行性备注（可选） |
| 测试代表 | 确认原型可测试性，验证验收标准是否明确。 | 可测试性检查意见 |
| 运维/环境负责人 | 保障演示环境、网络、评审工具处于可用状态。 | 环境预检通过报告 |
常见权责不清：产品经理常被默认为“全权负责”所有前置条件，实际应由主持人统筹、各角色各司其职。务必在评审启动前书面明确责任人。
记录材料
以下材料需在评审存档中永久保留：
- 前置条件总清单（含四维状态、检查结果、签字确认）
- 原型就绪检查报告（含不符合项截图及修复状态）
- 需求文档对齐确认表（含版本比对与变更记录截图）
- 角色到位确认回执（会议邀请截图 + 出席确认记录）
- 环境预检通过报告（含工具版本、网络测速、数据快照）
异常处理
| 异常场景 | 处理方式 | 决策路径 |
|---|---|---|
| 原型未冻结 | 标记为 阻塞，暂停评审流程，退回产品团队修复。 | 主持人判定 → 通知产品经理 → 重新排期 |
| 需求文档版本不匹配 | 立即比对版本差异，若为微小偏差可现场对齐；若偏差 ≥ 2 次版本，则延后评审。 | 主持人 + 产品经理现场决策 |
| 关键角色缺席 | 优先等待 10 分钟；仍无法到场则转为异步评审或改期。 | 主持人判断 → 通知所有参会者 |
| 环境不可用 | 尝试备用方案（本地演示 / 录屏 / 截图讲解）；若核心功能无法展示则改期。 | 环境负责人排查 → 主持人决策 |
| 多个维度同时异常 | 直接标记为 整体阻塞，重新协调资源后启动新一轮前置条件检查。 | 主持人升级 → 项目管理层介入 |
经验参考：实际项目中，约 60% 的评审延误源于前置条件未达标。建议在评审前 24 小时由主持人发起一次“预检查”，提前暴露问题。
验收标准
本章节前置条件清单的验收标准如下：
- ✅ 四维检查全部通过（原型就绪、文档对齐、角色到位、环境可用）。
- ✅ 所有不符合项已记录在案，并明确处置状态（修复 / 降级 / 阻塞）。
- ✅ 各角色在检查表上签字确认，无未解决争议项。
- ✅ 前置条件总清单已归档，可作为评审启动的正式依据。
- ✅ 异常处理记录完整，包含问题描述、决策过程、最终结果。