第4章 评审会议的会前检查清单：PRD完整性、格式规范、需求编号、版本号、变更记录
1. 适用场景
- 正式技术评审 (TR)：产品需求文档（PRD）进入评审会议前，无法确定是否具备准入资格。
- 需求基线锁定：PRD完成终版撰写，准备提交给开发、测试、UI/UX等下游团队时。
- 版本迭代切换：多版本并行开发，需要确认当前评审的是正确的版本基线。
- 外包/跨团队交付：非本团队人员提交的PRD，必须通过会前检查清单过滤。
2. 前置条件
- PRD已由需求撰写者完成内部自检，已不存在明显的逻辑或语法错误。
- 该PRD已被上传至统一的文档管理平台（Confluence、SharePoint、飞书文档等），且具有“已提交待评审”状态标签。
- 已生成本次评审的参会人员列表（至少含评审组长、技术负责人、测试代表）。
- 评审组长（或主持人）已收到 PRD 链接并拥有阅读权限。
3. 操作步骤
评审组长或主持人应按以下五步完成会前检查，缺一不可。每一步若未通过，应标记为“未通过”并返回修订。
-
PRD完整性检查
对照标准 PRD 模板，检查是否存在章节缺失。必须包含：背景与目标、需求详细描述（含业务规则）、非功能性需求（性能/安全性）、影响范围、验收标准。所需物：PRD 标准模板目录（见下表）。 -
格式规范检查
检查标题层级（H1→H2→H3）、字体统一（宋体/微软雅黑）、表格对齐、图片清晰度、以及是否使用了正确的术语缩略语。禁止出现保留的“TODO”标记。 -
需求编号合规性检查
每个需求条目必须具有唯一且可追踪的编号。编号规则建议为：[产品缩写]-[版本号]-[模块代码]-[三位流水号]。例如：OMS-1.2-PAY-001。 -
版本号准确性检查
检查文档页眉、页脚及文件名中的版本号是否与版本发布计划中的版本号一致。禁止出现“V1.0”、“最终版”、“修改版”等模糊版本命名。 -
变更记录可追溯性检查
必须包含变更记录表，且记录表至少包含：序号、变更日期、变更人、变更摘要、变更前版本、变更后版本。最后一个版本的变更记录应当为本次提交前的终版修订。
提示：建议评审组长在会前至少1个工作日发出检查结果。如果前三项任何一项未通过，直接推迟评审会，无需进入会议议程。
4. 输入输出物
| 类别 | 内容 |
|---|---|
| 输入物 | 已提交的PRD文档、历史版本PRD（若有）、版本发布计划、PRD标准模板目录 |
| 输出物 | 《PRD会前检查清单（已填写）》、是否准入评审的结论说明 |
5. 责任边界
| 角色 | 职责 |
|---|---|
| 评审组长 | 执行检查清单，记录不符合项，做出准入/退审判断 |
| 需求撰写者（产品经理） | 提供完整的PRD，并配合修改检查出的格式/编号问题 |
| 配置管理（CM） | 验证版本号与变更记录的基线一致性（可选） |
6. 记录材料
需要生成并归档以下记录（至少在评审会议召开前归档）：
- 《PRD会前检查清单.xlsx》：包含“通过/未通过/意见”三列，所有检查项逐条记录。
- 《版本号确认截图》：截取PRD文件名、页眉、变更记录表中的版本号对比图。
- 《退出评审通知》（如有）：当检查未通过时，向参会者发送会议“取消/推迟”通知，并注明原因。
7. 异常处理
| 异常场景 | 处理策略 |
|---|---|
| PRD完整性缺失（如未包含非功能性需求） | 直接标记为退审，要求产品经理补齐后重新提交 |
| 格式规范严重越界（使用特殊字体、大量未处理TODO标记） | 标注为拦阻项，拒绝进入评审会；要求发起人修正后重新发起 |
| 需求编号重复或不符合命名规则 | 按模块强制重编号，并与开发人员确认无冲突；可在会前1天内完成 |
| 变更记录未填写或与版本号不符 | 要求产品经理填写变更记录，并重新上传版本号为当前日期的新版本 |
警告：任何“退审”操作必须保留沟通记录。不得口头通知，须在项目管理工具（JIRA/TAPD/飞书任务）中创建“退审任务”并指定给产品经理。
8. 验收标准
- 输出物 《PRD会前检查清单》 已填写完整，且所有检查项均为“通过”。
- 文档版本号与发布计划严格一致，变更记录中可以追溯到每一次修改。
- 所有需求编号在PRD中唯一，且格式符合
[产品缩写]-[版本号]-[模块代码]-[三位流水号]。 - 未出现“格式不符合标准的段落”或“无编号的需求项”。
- 评审组长确认：该PRD已满足进入正式评审会议的最低质量门槛。