第一章 评审前准备阶段问题识别与应对
1.1 适用场景
本章内容适用于以下典型场景:
- PRD 首次评审前:文档尚未定稿,需要预检基础质量。
- 需求背景模糊:业务目标、用户场景或产品 KPI 未明确描述。
- 文档组织混乱:目录层级过多、术语不统一、缺少标准模板。
- 评审角色缺失:关键干系人(研发、测试、运营、法务等)未被邀请或遗漏。
- 跨团队协作启动:涉及多个部门联合评审,需统一信息基线。
1.2 前置条件
- PRD 已进入草稿阶段,具备至少 80% 的内容完整性。
- 已确定该次评审的主负责人(通常为产品经理)。
- 已创建或获取企业内部的 PRD 标准模板(如有)。
- 项目干系人清单已初步列出,并包含各角色代表。
- 评审会议时间已预留,且与会人可协调出至少 1 小时。
1.3 操作步骤
步骤 1:需求背景缺失 —— 识别与应对
⚠ 常见表现:PRD 开篇直接写功能列表,未说明“为什么要做”、“为谁做”、“如何衡量成功”。
识别方法:
- 逐项核对 PRD 是否包含 业务目标、用户场景、产品 KPI 三个必备小节。
- 若缺少任意一项,即判定为“背景缺失”。
应对方法:
- 立即应用 需求背景模板 补充信息:
## 需求背景
### 1. 业务目标
(例:提升支付转化率 5%)
### 2. 用户场景
(例:新用户在支付页停留超过 10 秒后流失)
### 3. 产品 KPI
(例:支付页漏斗转化率 ≥ 75%)
- 若 PM 无法独立补齐,则组织 15 分钟需求澄清会,邀请业务方与技术 TL 参与。
步骤 2:文档结构混乱 —— 识别与应对
⚠ 常见表现:标题层级随意(如直接从 h2 跳到 h4)、术语前后不一致、缺少目录或附录。
识别方法:
- 检查文档 目录结构,确认是否使用标准模板的层级(h1 → h2 → h3)。
- 统计术语定义是否在同一章节内统一(如“用户”与“客户”混用)。
- 确认是否存在 孤立的表格或图片 缺少说明文字。
应对方法:
- 使用企业 PRD 标准模板 进行全局重构:
1. 需求背景
2. 用户故事
3. 功能描述
3.1 前置条件
3.2 业务流程
3.3 界面规则
4. 验收标准
5. 附录
- 统一术语表(可在附录中维护),对全文执行“查找替换”确保一致。
- 为每个表格/图片添加 编号及标题(如:表 1-1 支付渠道对比)。
步骤 3:干系人遗漏 —— 识别与应对
⚠ 常见表现:评审会上才发现缺少法务、安全或数据端的代表,导致决策延期。
识别方法:
- 使用 RACI 矩阵 核对本次需求需涉及的角色(R:执行者,A:审批者,C:咨询者,I:知会者)。
- 检查评审邀请名单是否覆盖:产品、研发、测试、设计、运营、法务/合规、数据 七大基础角色。
应对方法:
- 更新 干系人清单,补充遗漏角色并指定对应人员。
- 若关键干系人无法参加原定时间,则 重新协调评审时间 或安排异步预审。
- 在 PRD 首页插入 评审参与角色表:
| 角色 | 负责人 | 参与方式 | 确认状态 |
|--------------|----------|--------------|----------|
| 产品经理 | 张三 | 主持评审 | 已确认 |
| 技术负责人 | 李四 | 现场评审 | 已确认 |
| 测试负责人 | 王五 | 现场评审 | 已确认 |
| 运营代表 | 赵六 | 异步预审 | 待确认 |
| 法务代表 | 钱七 | 异步预审 | 已确认 |
1.4 输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 需求背景 | 原始 PRD 草稿(背景缺失版) | 补充后的 PRD 需求背景章节 |
| 文档结构 | 混乱的 PRD 文档(无标准模板) | 按标准模板重构的 PRD |
| 干系人清单 | 初始邀请名单(不完整) | 完整的干系人清单 + 参与状态表 |
| 评审包 | 零散的 PRD、附件 | 结构化的评审材料包(含目录、术语表) |
1.5 责任边界
- 产品经理(主责):负责需求背景补充、文档结构重构、干系人清单更新,是本章所有操作的第一责任人。
- 技术负责人(配合):协助确认技术相关干系人是否遗漏,参与需求澄清会。
- 测试负责人(配合):从验收角度验证需求背景是否可测,反馈文档中模糊的定义。
- 运营/业务方(输入):提供业务目标和用户场景的一手信息。
- 法务/合规(咨询):对于涉及合规要求的 PRD,需在准备阶段确认法务干系人已纳入清单。
📌 边界提示:本章节聚焦“评审前”的准备动作,不涉及评审会中的讨论与决策。若在准备阶段发现需求方向有重大分歧,应升级至项目立项会解决,而非仅通过模板补充。
1.6 记录材料
- 《PRD 评审准备检查表》:逐项登记三个问题的识别结果与应对状态。
- 《干系人清单及参与状态表》:记录各角色负责人、参与方式、确认状态。
- 《需求背景补充记录》:若召开了需求澄清会,需记录会议结论与待办项。
- 《文档结构修改记录》:列出调整的章节、术语统一项、新增内容。
1.7 异常处理
| 异常场景 | 处理措施 |
|---|---|
| 需求背景无法获取(业务方不配合) | 升级至项目 sponsor,明确要求业务方提供书面背景,否则暂停评审。 |
| 文档结构重构导致内容遗漏 | 使用 diff 工具对比重构前后版本,逐项核对功能点是否完整迁移。 |
| 关键干系人长期无法协调时间 | 采取“异步预审 + 线下签字确认”模式,不阻塞评审整体进度。 |
| 多个问题相互交织(如背景缺失导致干系人无法确认) | 先解决背景缺失(步骤 1),再更新干系人清单(步骤 3),按优先级串行处理。 |
1.8 验收标准
- ✅ PRD 中已包含完整的 业务目标、用户场景、产品 KPI 三个小节。
- ✅ 文档采用企业 标准模板,目录层级清晰(不超过 4 级),术语统一。
- ✅ 干系人清单覆盖 七大基础角色(产品、研发、测试、设计、运营、法务、数据),且状态为“已确认”或“已安排预审”。
- ✅ 所有识别出的问题均已记录在《PRD 评审准备检查表》中,并标记为“已应对”。
- ✅ 评审材料包已上传至共享空间(如 Confluence、飞书文档、SharePoint),且向所有干系人发送了评审通知。
✅ 通过标准:以上五项全部满足,则本章节工作完成,可进入下一阶段(评审会实施)。