第四章 评审前准备工作清单：材料准备、预审检查、依赖对齐
适用场景：本章适用于PRD已完成初稿、准备发起跨团队评审之前的准备阶段。当PRD涉及多个依赖方、数据变更、接口联调或前后端协作时，必须按照本章清单完成前置对齐，否则评审会容易陷入细节争议或无效讨论。
4.1 前置条件
- PRD文档已完成初稿并经过产品经理自检（格式完整、逻辑闭环）。
- 已明确评审范围、目标团队及关键决策人。
- 评审日历已预留至少3个工作日用于预审检查与依赖对齐。
- 产品经理已获取各团队的接口文档、数据定义或约束文件（如有）。
4.2 操作步骤
- 材料准备清单确认：对照模板检查PRD中是否包含背景、目标、功能列表、非功能需求、埋点方案、数据字典、UI原型链接等核心模块。缺少的部分标注为待补充，并启动补充流程。
- 预审检查（内审）：由产品经理或指派的小范围资深成员（通常1-2人）对照历史评审常见漏洞清单进行逐项检查，重点验证逻辑一致性、边界条件完整性、术语统一性。
- 依赖对齐：识别PRD中所有跨团队依赖点（如接口定义、数据源、第三方SDK、资源配额），主动发送依赖确认邮件或IM消息给各接口人，收集其书面确认或修改建议。
- 整理依赖状态表：将每项依赖标记为“已确认 / 待确认 / 有冲突”，对有冲突的内容提前组织小范围对齐讨论，避免评审现场暴露未解决的依赖问题。
- 预审问题归档：将预审检查中发现的问题和依赖对齐结果整理成《预审问题清单》，随PRD一起分发至评审参与人。
实操提示：预审检查最好由不直接参与该PRD撰写的同学执行，视角更新鲜，更容易发现“想当然”的逻辑漏洞。依赖对齐建议使用共享表格（如飞书/钉钉多维表），让依赖方实时更新状态。
4.3 输入输出物
| 输入物 | 输出物 |
|---|---|
| PRD初稿（V0.9） | 预审后PRD（V0.95） |
| 历史评审常见漏洞清单 | 预审问题清单 |
| 各团队接口/数据约束文档 | 依赖状态表（已确认/待确认/有冲突） |
| 评审参与人名单及角色 | 评审会前通知（含预审问题清单） |
4.4 责任边界
- 产品经理：负责材料完整性自检、首次预审、依赖清单梳理及依赖确认跟进，最终输出预审问题清单和依赖状态表。
- 技术负责人/架构师：协助预审检查技术可行性、接口约束、性能指标；对依赖冲突给出专业判断。
- 各依赖方接口人：在指定时间内（通常≤2个工作日）回复依赖确认或提出修改建议。逾期未回复默认视为接受。
- 测试负责人（可选）：参与预审检查测试边界、埋点需求可测性。
4.5 记录材料
- 预审问题清单（字段：编号、问题描述、所属模块、严重级别、状态、提出人、解决方式）
- 依赖状态表（字段：依赖项、依赖方、状态、确认人、确认时间、备注）
- 评审前准备核对卡（清单式，逐项打钩）
示例：预审问题清单（局部）
| 编号 | 问题描述 | 严重级别 | 状态 |
|------|--------------------------------|----------|--------|
| P001 | “xx接口”未说明超时重试策略 | 高 | 已修复 |
| P002 | 用户权限字段定义与IAM不一致 | 中 | 待对齐 |
| P003 | 数据埋点事件名未按规范命名 | 低 | 已修改 |4.6 异常处理
常见异常及应对：
- 依赖方逾期未确认：产品经理升级为邮件+即时消息双重提醒，仍无回复则标记为“默认按现有方案执行并保留调整兜底时间”。
- 预审发现重大遗漏（如缺失安全策略）：中止评审准备，退回PRD补充章节，重新走预审流程。
- 依赖冲突无法在2个工作日内对齐：记录冲突点，升级至项目经理或技术总监仲裁，仲裁结果更新至依赖状态表后再推进评审。
- 材料版本混乱：启用版本管理机制，使用统一文件命名规则（如 v0.95_20250406），并清理旧版本链接。
4.7 验收标准
- 预审问题清单已完整归档，高严重级别问题清零或已明确解决计划。
- 依赖状态表中所有依赖项均为“已确认”或“有冲突（已升级）”，无“待确认”遗留。
- PRD文档已更新至V0.95版本，并在评审通知中同步预审问题和依赖状态。
- 所有评审参与人（除待确认依赖方外）均已收到评审会前通知且回复预计到场。