前置条件与准入标准：PRD成熟度检查、参会人通知周期、材料预读要求
适用场景
本流程适用于以下场景：
- PRD初稿完成后，计划组织跨团队（研发、测试、设计、数据、运营等）正式评审之前
- 需要统一准入条件，避免评审会因为PRD不成熟、参会人未通知、材料未预读而导致节奏失控
- 多项目并行时，通过标准化前置检查确保每个评审会都有相同的质量底线
前置条件
- PRD初稿已定稿：至少完成全部需求正文、非功能性需求、验收标准、业务规则、数据定义模块
- 产品经理已完成自检清单：使用下方“PRD成熟度检查表”逐项确认
- 评审排期已预留：评审会时间暂不锁定，待准入检查通过后正式发出邀请
- 关键干系人名单已确认：至少包含技术负责人、测试责任人、设计接口人、业务方代表
常见坑点： 许多团队在PRD只有待定占位符时就发起评审，导致会上50%时间讨论未确定内容。本流程要求所有“待定”项必须标注预计确认时间和Owner，否则不可通过准入。
操作步骤
- PRD成熟度检查
- 产品经理逐项检查自检表，确保无红色未完成项
- 如存在黄色待确认项，需在PRD正文中标注“待确认”及确认时间节点
- 确认PRD版本号、修订记录完整
- 参会人确认与通知周期设定
- 根据项目优先级和复杂性，选择通知周期：常规项目≥3个工作日，紧急项目≥1个工作日且需获得与会者确认
- 通过协作平台（如飞书、钉钉、Outlook）发送会议邀请，正文包含PRD版本号、预读截止时间、评审时长
- 对关键角色（技术负责人、测试负责人）额外私聊确认收到
- 材料预读要求设定与跟踪
- 在会议邀请中明确：参会人需在评审会前至少8小时完成预读，并提交至少1条评论或问题
- 产品经理在预读截止时间前2小时检查评论情况，对未提交评论者发起提醒
- 如预读参与率低于70%（关键角色低于100%），产品经理需判断是否延后评审
- 准入状态确认与锁死
- 上述三项全部通过后，将评审会状态设为“准入通过”并锁定时间
- 如任一条件未满足，自动触发异常处理流程
最佳实践： 建议将PRD成熟度检查电子表格与评审邀请系统打通，自动检查通过后直接发送邀请。使用简单的看板来追踪每个评审会的前置条件状态。
输入输出物
| 输入物 | 输出物 |
|---|---|
| PRD初稿（含版本号、修订记录） | 通过准入的PRD（评审版） |
| 干系人名单 | 正式的评审会议邀请（含预读要求和截止时间） |
| PRD成熟度自检表 | 准入检查记录表（含通过/未通过标志） |
| 预读参与率数据 | 预读完成情况报告（用于评审后复盘） |
责任边界
- 产品经理：对PRD成熟度检查负全责，确保无遗漏项；主动跟踪参会人通知和预读情况
- 技术负责人/测试负责人：有义务在预读截止时间前完成阅读并反馈，未完成可拒绝参加评审
- 项目经理/Scrum Master：监控整体准入流程，对未达标评审有权叫停
- 业务方代表：确认PRD中的业务规则、验收条件是否覆盖核心场景
记录材料
| 记录项 | 格式 | 保存位置 |
|---|---|---|
| PRD成熟度检查表（每版本一份） | 电子表格 / 需求管理工具字段 | 项目共享文档库 |
| 参会人确认通知记录 | 协作平台聊天记录 / 邮件截图 | 评审会议附件或备注 |
| 预读评论记录 | PRD系统中的评论 / 反馈列表 | 需求管理工具 |
| 准入检查结果 | 看板卡片标签或状态 | 项目管理工具（如Jira、Wrike） |
异常处理
| 异常类型 | 处理方式 |
|---|---|
| PRD成熟度检查未通过 | 产品经理补全缺失内容，重新提交检查（单次重检不超2个工作日） |
| 关键参会人无法参加（通知周期内） | 调整评审时间，重新发送邀请（优先选最早可安排时间）；如该角色可书面授权替代人，则由授权人代为参与 |
| 预读参与率低于70% | 延后评审会24小时，再次发送提醒，并将参与率数据在评审会开场时通报 |
| 材料预读时间不足（突发紧急评审） | 将评审会改为“快速对齐会”，不要求正式评审结论；会后1个工作日内补齐正式评审 |
| 评审会因外部不可抗力取消 | 在参会人通知周期内重新发起，并告知新的预读截止时间（至少保留4小时） |
验收标准
- PRD成熟度检查表所有项为绿色通过或黄色待确认（已标注Owner和确认时间），无红色未完成项
- 参会人通知周期已满足（常规3个工作日，紧急1个工作日且获得确认）
- 预读参与率≥70%，且关键角色（技术、测试负责人）预读参与率=100%
- 会议邀请中已明确预读截止时间和评论要求
- 准入状态已锁死，评审会可按时召开