产品开发流程节点评审模板

一、适用场景与核心目标二、标准化评审操作流程（一）评审准备阶段明确评审目标与范围由产品经理牵头，根据当前开发阶段（如需求调研完成、原型设计完成等），确定本次评审的核心目标（如“确认需求完整性”“验证技术方案可行性”）、评审范围（需覆盖的模块、功能点或交付物）及通过标准（如“需求覆盖率100%”“无重大技术瓶颈”）。组建评审组评审组成员需包含核心角色：产品负责人（经理）、研发负责人（工）、测试负责人（工）、设计负责人（工）、业务方代表（*主管），必要时可邀请用户代表或外部专家。提前3个工作日通知评审组成员，确认参会时间。准备评审材料产品经理整理当前阶段产出物（如需求文档、原型图、技术方案、测试计划等），保证内容完整、逻辑清晰，重点标注关键需求、风险点及待确认问题。材料需提前2个工作日分发至评审组成员，预留审阅时间。（二）评审实施阶段会议开场与目标重申评审组长（通常为产品负责人或研发负责人*工）主持会议，明确会议时长（建议控制在60-90分钟）、议程顺序及发言规则（如“先汇报后讨论，避免打断”），重申本次评审目标和通过标准。成果汇报与问题聚焦由核心产出负责人（如产品经理经理、研发负责人工）依次汇报当前阶段成果，重点说明：需求背景与目标、核心功能设计、技术实现路径、测试覆盖范围、已识别风险及应对措施。汇报结束后，评审组提出疑问，汇报人逐一解答，聚焦存在争议或未明确的问题。逐项评审与共识达成对照评审目标，对产出物逐项评审：需求评审：检查需求完整性（是否覆盖用户场景）、一致性（与产品目标是否冲突）、可落地性（技术资源是否支持）；方案评审：评估技术可行性、架构合理性、扩展性及成本；测试评审：确认测试用例覆盖核心场景、缺陷分级标准是否明确。对存在分歧的问题，组织讨论达成初步共识；对无法当场解决的问题，记录为“待决议项”，明确后续跟进人及时间。形成评审结论评审组根据通过标准，对评审对象结论进行投票：通过：无重大问题，可进入下一阶段；带条件通过：存在次要问题（如文档格式不规范、非核心功能需优化），明确改进项及完成时限后可进入下一阶段；不通过：存在重大问题（如需求遗漏核心场景、技术方案不可行），需重新输出成果并再次评审。（三）评审输出阶段整理评审记录记录人（通常为产品经理或指定成员*工）汇总评审过程，形成《评审报告》，内容包括：评审基本信息（时间、地点、参与人）、评审内容概述、各问题点描述（含责任部门/人、改进建议）、评审结论及待决议项。分发与确认评审结束后24小时内，将《评审报告》分发至评审组成员及相关部门负责人，要求成员在1个工作日内确认内容准确性，如有异议需反馈记录人修订。问题闭环跟踪对“带条件通过”的改进项及“待决议项”，由产品经理建立《问题跟踪清单》，明确责任部门、责任人、完成及时限，每日同步进展，保证所有问题在下一阶段启动前闭环。（四）评审复盘阶段每个重大节点（如需求评审、上线评审）完成后，组织评审组召开简短复盘会，总结本次评审中的亮点（如高效识别风险点）与不足（如材料准备不充分、讨论偏离主题），持续优化评审流程。三、评审记录模板与填写说明（一）评审记录表模板评审基本信息项目名称电商平台V2.0改版项目评审阶段需求调研阶段评审评审时间2023年10月26日14:00-16:00评审地点3楼会议室A评审组长*工（产品负责人）参与人员经理（产品经理）、工（研发负责人）、工（测试负责人）、主管（业务方代表）记录人*工评审内容与问题清单责任部门/人完成时限状态备注1.用户注册模块需求未明确第三方账号登录（）支持方式产品部*经理10月28日待改进需补充登录流程及数据对接说明2.商品搜索功能未考虑高并发场景下的功能优化方案研发部*工10月30日待改进需提交技术架构优化方案3.购物车功能测试用例未覆盖“商品库存不足时用户操作”场景测试部*工10月29日待改进补充边界值测试用例4.需求文档中“用户等级权益”部分与业务方前期确认的规则不一致产品部*经理10月27日已完成已同步业务方确认评审结论□通过□带条件通过（需完成上述改进项）□不通过（需重新输出需求文档）改进要求说明带条件通过，所有改进项需在10月30日前完成，产品部汇总确认后进入设计阶段签字确认评审组长签字_______________记录人签字_______________参与人员签字工、经理、工、主管（可附签到表）（二）填写说明评审基本信息：需准确填写项目名称、阶段、时间及参与人员，保证可追溯；评审内容与问题清单：问题描述需具体（如“未明确功能”而非“需求不清晰”），责任部门/人需明确到个人，时限需合理；评审结论：根据评审实际情况勾选，带条件通过时需明确改进项及整体完成时限；签字确认：评审组长需对结论负责，参与人员签字确认参与过程，保证评审有效性。四、关键注意事项与风险规避避免评审目标模糊评审前务必明确“本次评审要解决什么问题”，避免泛泛而谈导致讨论偏离方向。例如需求评审聚焦“需求完整性”而非“产品设计细节”，技术评审聚焦“可行性”而非“代码实现”。保证材料提前准备评审材料需提前分发，保证成员有足够时间审阅；材料中需标注重点（如加粗、颜色区分），避免现场因材料不熟悉导致评审效率低下。匹配评审组人员能力评审组成员需具备相关领域专业知识，如技术评审需包含架构师，用户体验评审需包含设计师，避免“外行评内行”导致结论偏差。做好问题跟踪闭环评审后的问题清单需专人跟踪，避免“议而不决”；对未按时完成的改进项，需及时反馈并分析原因（如资源不足、需求变更），保证问题不遗留到下一阶段。保持评审客观性评审过程中需基于事实