第一章 评审前准备阶段问题识别与应对

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),且向所有干系人发送了评审通知。
✅ 通过标准:以上五项全部满足,则本章节工作完成,可进入下一阶段(评审会实施)。