4. 需求评审与对齐：PRD讲解、技术可行性评估、测试关键点识别、争议解决流程
4.1 适用场景
本章适用于以下关键节点，确保需求从“文档”向“可执行方案”平稳过渡：
- PRD终稿发布后、开发排期前：产品经理已完成PRD定稿，即将移交技术团队。
- 涉及多系统/跨团队协作：需求影响面广，需要前后端、数据、QA、运维等角色对齐理解。
- 技术方案存在不确定性：新功能或架构调整可能引入性能、安全或兼容性风险。
- 测试资源紧张：需提前识别核心测试路径与边界，避免后期返工。
⚠️ 常见误区：将评审会开成“PRD朗读会”。评审的核心是质疑与挑战，而非单向信息传递。若评审会无人提问或全员沉默，需立即暂停并启动引导式提问。
4.2 前置条件
| 类别 | 必要条件 | 负责角色 |
|---|---|---|
| 文档 | PRD v1.0终稿（含交互原型、业务规则、异常流程） | 产品经理 |
| 环境 | 评审会议室/线上会议录制权限、共享屏幕、白板工具 | 产品经理/项目经理 |
| 人员 | 相关方已确认参会（开发、测试、设计、运维） | 项目经理 |
| 预审 | 关键开发/测试已提前24h阅读PRD并标记疑问 | 开发/测试 |
4.3 操作步骤
评审会议按以下四阶段逐层推进，每一阶段需完成特定目标后方可进入下一环节：
- PRD讲解（30%会议时间）：
- 产品经理按“WHY→WHAT→HOW”逻辑串联：业务背景→用户旅程→核心功能→边界规则。
- 配合原型逐页演示，重点标注假设条件与开放问题。
- 输出物：与会者口头确认“理解了业务意图”。
- 技术可行性评估（30%会议时间）：
- 开发负责人从架构、数据流、第三方依赖、性能指标四个维度评估。
- 对存在风险的模块（如高并发写入、遗留系统改造）当场标记为“需二次技术调研”。
- 输出物：可行性意见表（达成/有条件达成/不可行）。
- 测试关键点识别（20%会议时间）：
- 测试工程师基于PRD梳理功能点矩阵，区分P0/P1/P2优先级。
- 对规则复杂或逻辑分支密集的区域，现场白板推导等价类与边界值。
- 输出物：测试策略草案（包含主流程、异常场景、兼容性范围）。
- 争议解决流程（20%会议时间）：
- 按“数据/逻辑/结论”分层归类争议：如规则分歧、资源冲突、排期冲突。
- 当场无法裁决的争议，记录入争议待办清单，明确决策人与截止日期。
- 输出物：争议记录表（争议描述、备选方案、决策人、TTL）。
💡 实操建议：每阶段结束后，主持人（项目经理或技术负责人）做一次“确认三连”：“是否理解了？有无不同意见？是否可进入下一阶段？” 避免因跳跃讨论导致关键点遗漏。
4.4 输入输出物
| 输入物 | 输出物 | 传递对象 |
|---|---|---|
| PRD v1.0 终稿 | 评审会议纪要（含确认点、待办事项） | 全体参会人 |
| 交互原型/设计稿 | 技术可行性评估表 | 开发负责人 → 项目经理 |
| 历史相似功能测试报告 | 测试关键点清单（含P0用例原型） | 测试工程师 |
| 争议预登记表（可选） | 争议决策记录（含升级路径） | 项目经理/产品总监 |
4.5 责任边界
| 角色 | 核心责任 | 禁止行为 |
|---|---|---|
| 产品经理 | 澄清业务逻辑、确认需求优先级、记录开放问题 | 在评审会上临时新增需求或修改已确认规则 |
| 开发负责人 | 评估技术可行性、识别架构风险、给出排期预估算 | 承诺未验证的技术方案（如“这个肯定能行但说不清怎么实现”） |
| 测试工程师 | 识别测试盲区、确认测试环境与数据准备需求 | 在技术方案未定论前就设计详细用例 |
| 项目经理 | 把控时间线、记录争议与决策、推动达成共识 | 代替产品经理或开发做技术决策 |
4.6 记录材料
每次评审需产出一份可追溯的评审记录，建议包含以下字段：
【评审记录模板 v1.0】
===================
项目名称：__________ PRD版本号：__________ 日期：__________
参会人：产品【___】 开发【___】 测试【___】 其他【___】
【PRD讲解确认点】
1. 业务目标是否清晰？ ☐是 ☐否（简述：__________）
2. 用户旅程是否完整？ ☐是 ☐否（缺失环节：__________）
【技术可行性评估结果】
- 已完成评估模块：__________
- 需二次调研模块：__________（DDL：__________）
【测试关键点清单（P0级）】
| 功能模块 | 测试类型 | 优先级 | 备注 |
|----------|------------------|--------|------------|
| 登录 | 边界值/异常场景 | P0 | 兼容老版本 |
【争议待办清单】
| 争议描述 | 涉及方 | 决策人 | 预计解决日期 |
|--------------|----------|----------|--------------|
| 缓存策略选择 | 产品+开发 | 技术总监 | 2025-03-05 |
【下一轮评审会议预订】日期：__________ 目标：__________
4.7 异常处理
| 异常场景 | 处理流程 | 责任人 |
|---|---|---|
| 关键角色缺席（如架构师） | 会议立即转为“PRD通报会”，不形成技术决议；待关键角色到场后重新召开评审会 | 项目经理 |
| 多轮评审后意见仍无法统一 | 升级至产品委员会或技术委员会，使用“决策矩阵”投票（支持/反对/弃权），投票结果作为最终依据 | 产品总监/CTO |
| 需求在评审中被发现存在重大逻辑漏洞 | 冻结该模块评审，产品经理在3个工作日内输出修复版PRD，并行通知受影响方 | 产品经理 |
| 频繁出现需求变更 | 项目组启用“变更控制流程”：变更单审批→影响域评估→重新评审（仅评审变更部分） | 变更控制委员会 |
✅ 最佳实践：每次评审会预留最后5分钟进行“RACI确认”：共识各任务的责任人（Responsible）、决策者（Accountable）、咨询方（Consulted）、知情方（Informed），避免后期执行阶段权责不清。
4.8 验收标准
一个成功的需求评审与对齐，应符合以下五项标准：
- 共识度≥80%：与会者现场就PRD内容达成基本一致，无重大未决异议。
- 技术可行：开发负责人已识别所有技术风险，对“有条件达成”项有明确后续调研计划。
- 测试可测：测试关键点清单包含P0级别用例，且测试环境/数据准备需求已明确。
- 争议清零：所有已识别争议均有决策人、TTL和备选方案，无“悬而未决”项。
- 记录完整：评审记录模板中所有字段均已填写，且上传至项目共享空间。
评审对齐完成后，产品经理需在24小时内将评审纪要、技术评估表、测试策略草案及争议记录打包上传至项目管理工具（如Jira/Confluence），并@相关方确认。下阶段将基于此共识进入技术方案设计与测试用例编写环节。