1. 评审前准备<br> (Pre-Review Preparation)<br>
产品经理 (PM) 准备材料
业务背景与目标 (BRD/MRD)
清晰完整的PRD文档
用户故事/用例 (User Stories/Use Cases)
功能清单 (Feature List)
业务流程图 (Flowchart)
线框图/交互原型 (Wireframe/Prototype)
数据需求与成功指标 (Metrics)
确定评审范围与目标
明确本次评审的核心功能点
确定希望达成的共识（如：技术可行性、排期等）
预约评审会议
提前发出会议邀请
明确会议时间、地点、议程
提前分发材料（至少提前1个工作日）
参会角色确认
开发 (前端、后端、客户端)
测试 (QA)
设计 (UI/UX)
运营/业务方
项目经理 (PMO)
2. 评审会议中<br> (During the Review Meeting)<br>
产品经理宣讲 (PM Presentation)
讲解业务背景与价值（Why）
逐项讲解PRD内容（What）
演示原型，讲解交互逻辑
讲解业务流程与规则
与会人员讨论与答疑 (Q&A Session)
开发团队
评估技术可行性、实现方案
识别技术风险与依赖
初步评估工作量（人/天）
测试团队
理解需求，思考测试场景
评估测试复杂度与风险
提出逻辑遗漏与边界情况
设计团队
确认交互逻辑与原型的一致性
提出用户体验优化建议
运营/业务方
确认需求是否满足业务目标
提出业务层面的问题与建议
记录关键问题与决策 (Note Taking)
指定记录人（通常是PM或QA）
明确记录：问题点、责任人、解决方案、预计解决时间
会议总结与后续安排
总结会议结论与待办事项
明确需求是否通过评审
确定下一步行动计划（如：补充设计、技术方案设计等）
3. 评审后跟进<br> (Post-Review Follow-up)<br>
问题修复与PRD更新
PM根据会议记录，修改和优化PRD文档
更新原型、流程图等材料
同步更新内容
将更新后的PRD同步给所有参会人员
确认关键问题是否已全部解决
召开二次评审（如需）
若修改内容多或存在重大变更，组织二次评审
通常范围较小，只针对修改点
需求定稿与启动
所有角色确认无误后，PRD正式进入基线状态
开发团队根据基线版PRD进行技术方案设计与排期
测试团队开始编写测试用例（Test Cases）
5. 成功关键要素<br> (Key Success Factors)<br>
PRD质量是基础：文档清晰、准确、无歧义
提前沟通：复杂点会前与关键人员预先沟通
目标明确：明确评审目标，控制会议范围，避免发散
高效会议：主持人控场，围绕主题，鼓励发言
责任到人：所有问题都有明确的跟进责任人和期限
文化氛围：建设性讨论，对事不对人，共同目标是做出好产品
4. 参与角色与职责<br> (Roles & Responsibilities)<br>
产品经理 (PM)
需求所有者，负责撰写PRD、组织评审、跟进修改
开发 (Dev)
评估技术可行性、实现方案、工作量
测试 (QA)
评估测试风险、提出逻辑漏洞、编写用例
设计师 (UI/UX)
确认交互与视觉方案的可行性及一致性
项目经理 (PMO)
协调资源、跟踪流程、确保项目进度（可选角色）
