第2章 评审前准备清单：材料完备性、干系人识别、时间预留

适用场景

本章适用于任何一次正式 PRD 评审会议召开之前 48–72 小时的窗口期。无论是需求宣讲、技术评审还是终审决策，前置准备的质量直接决定评审会能否从“对齐信息”转向“达成共识”。本清单适用于产品经理、项目经理以及评审会组织者。

前置条件

• PRD 文档已完成内部初稿，且至少经过作者本人一轮通读检查
• 评审目标已明确：是获取反馈、确认方案，还是签字放行
• 项目排期已初步框定，评审不早于计划启动前 3 个工作日

操作步骤

评审前准备分为三个并行的流水线，每条流水线的产出物需在会前 T-24h 完成冻结。以下三步严格按照顺序执行，但不要求串行——可由不同角色并发推进。

1. 通读自检：产品经理逐页检查 PRD 的章节完整性，确认无 TODO 标记、无悬空引用（如“详见附录X”但附录缺失）、无矛盾数字（如“支持 10 万用户”与“按 1000 并发设计”冲突）。
2. 关键要素打标：在文档中高亮标注以下三类信息——依赖项（需要其他团队前置交付的能力）、决策点（本次评审必须拍板的问题）、边界范围（本次版本不做但已识别的事项）。
3. 附件与原型确认：检查原型图、流程图、数据字典、接口定义等配套材料是否可访问、版本是否与 PRD 一致。若使用第三方工具（如 Figma、Swagger），确认权限已开放给所有评审人。

1. 绘制干系人矩阵：使用 RACI 模型标注每项决策的 负责（产品经理自己）、批准（有签字权的人）、咨询（需被征求意见的技术/业务专家）、告知（只需获取结果的人）。
2. 确认参会人意愿：对 “R” 和 “A” 角色必须采用定向邀请，而非群发日历；对 “C” 角色至少提前发送材料并确认其是否已阅读。避免出现“人到场但未读过需求”的情况。
3. 预沟通敏感议题：对可能引发争论的功能点或资源冲突，在评审会前单独与关键干系人做 15 分钟预沟通，提前暴露分歧。预沟通不改变决策权，只减少现场争吵。

1. 评估评审工作量：按每 10 页 PRD 预留 25 分钟、每 1 个争议议题预留 10 分钟的经验公式，预估最低需要的评审时长。
2. 设定时间预算合约：在会议邀请正文中写明议程分段，例如：前 15 分钟通读框架 → 中间 30 分钟逐条件讨论 → 最后 10 分钟结论确认。并将超过时间后的处理规则写进描述（例如“到达时间后未决问题转入异步跟帖”）。
3. 预留缓冲期：评审会后至少保留 4 小时的工作日时间用于产生结论备忘。不要在评审会结束后立即安排另一场高密度会议。

输入输出物

责任边界

• 产品经理：对材料完备性和预沟通负全责；保证文档中没有低级错误和隐式依赖。
• 项目经理/Scrum Master：对干系人识别和参会确认负责；最终检查 RACI 矩阵是否遗漏必要角色。
• 技术负责人/代表：阅读材料并反馈前置可行性，非必须在评审会上才首次提出技术风险。
• 上级主管（若需批准）：明确告知自己的决策边界——哪些事项可以在会上当场签字，哪些需要会后 1 天再给答复。

记录材料

评审前准备完成后，必须留存以下三项记录材料，供评审会结束时核对使用：

1. PRD 版本变更日志：最后 3 次修订的变更摘要，方便参会人了解文档在哪里发生了什么变化。
2. 干系人邀请确认截图或系统记录：直接在会议邀请中设置“附件已读确认”或手动记录每位被邀请人的反馈。
3. 预沟通纪要（可选但推荐）：任何预沟通后若有结论或未达成的共识，用一句话记录在共享笔记中，同步给所有参会人。

异常处理

验收标准

本章验收标准即评审会开始前 10 分钟由评审组织者（通常为产品经理或项目经理）对照以下清单逐项自检：

• ✅ PRD 文档无 TODO、无矛盾数据、无悬空引用，且已通过自检通读
• ✅ 所有参会的 “A” 角色和 “R” 角色均已书面确认出席或已授权替代人
• ✅ 会议邀请中包含议程分段时间表，且超时处理规则已写明
• ✅ 至少对 1 个潜在争议议题完成了预沟通（或确认无争议议题）
• ✅ 评审会开始时间与下一次有明确产出要求的时间之间，有至少 4 小时缓冲

评审前准备流程全景图