产品开发周期内评审会议检查清单

产品开发周期内评审会议检查清单通用模板一、适用场景与价值本checklist适用于产品从需求调研到上线运营全周期内的各类评审会议，包括但不限于：需求评审会、技术方案评审会、UI/UX设计评审会、开发中期质量评审会、测试用例评审会、上线前准备评审会等。通过标准化评审流程，可保证各环节输出物完整、风险可控、责任明确，减少因评审疏漏导致的需求变更、技术返工或上线，提升产品开发效率与质量。二、全流程操作指引（一）会前准备：奠定评审基础明确评审目标与范围根据当前开发阶段（如需求阶段、设计阶段、测试阶段），确定本次评审的核心议题（如“需求完整性验证”“技术方案可行性”“测试用例覆盖度”）。定义评审范围：明确本次需评审的具体文档/模块（如“PRDv3.0全文档”“用户中心模块技术方案”），避免范围蔓延。确定评审参与人员核心角色：项目负责人（产品经理）、研发负责人（技术经理）、测试负责人（测试组长）、UI/UX设计师（设计师），必要时邀请运维、法务、业务方代表参与。提前3个工作日发送会议邀请，明确各角色职责（如产品经理负责讲解需求，技术经理负责评估实现难度）。准备评审材料根据评审类型整理输出物：需求评审需提供PRD、原型图、用户故事地图；技术方案评审需提供架构设计图、核心流程图、技术选型对比表；测试评审需提供测试计划、用例设计文档、自动化测试脚本等。保证材料版本最新（标注版本号、更新日期），格式统一（如PDF、PPT、在线文档），关键信息（如需求编号、技术指标）清晰可查。提前分发材料与预审会议前2个工作日通过邮件/协作工具（如飞书、钉钉）分发评审材料，同步提醒参与者提前审阅并记录疑问。项目负责人收集预审问题，梳理高频疑问点，作为会议重点讨论内容。（二）会中执行：聚焦核心议题开场与议程确认（5-10分钟）主持人（通常为项目负责人产品经理）开场，明确会议目标、议程、预计时长及纪律（如“发言聚焦主题，避免无关讨论”“每人发言不超过3分钟”）。确认参会人员到齐情况，关键角色（如技术负责人、测试负责人）缺席时需明确后续补审机制。逐项评审与讨论（核心环节，时长按议题调整）按checklist逐项检查输出物，由对应角色讲解（如产品经理讲解需求背景，技术经理讲解方案逻辑）。参与者围绕“完整性、可行性、一致性、风险点”四维度提问：完整性：需求是否覆盖所有用户场景？技术方案是否考虑异常处理？可行性：技术选型是否符合团队技术栈？需求是否在当前资源下可落地？一致性：设计与需求是否匹配？前后端接口定义是否统一？风险点：是否存在技术瓶颈？用户体验是否有潜在漏洞？上线风险是否可控？对争议问题进行充分讨论，必要时通过投票或决策人（如项目负责人产品经理、技术负责人技术经理）拍板确定结论，避免“议而不决”。问题记录与结论确认（10-15分钟）指定专人（如项目助理）使用“问题跟踪表”实时记录：问题描述、严重程度（致命/严重/一般/建议）、责任方、整改期限。会议结束前，主持人逐项回顾评审结论，明确“通过”“不通过（需整改后复评）”“有条件通过（需补充材料）”三类结果，并同步给所有参会人员。（三）会后跟进：保证闭环落地整理并分发会议纪要会后24小时内，由专人整理会议纪要，包含：会议基本信息（时间、地点、参与人）、评审结论、问题清单（含问题描述、责任方、整改期限）、后续行动计划。纪要通过邮件/协作工具发送给所有相关方，并抄送项目干系人（如部门负责人），保证信息同步。跟踪问题整改与闭环责任方按整改期限提交修改后的材料/方案，项目负责人产品经理组织二次评审（仅针对整改项）。建立“问题跟踪表”，每日更新问题状态（“处理中”“待复评”“已关闭”），每周在项目例会上同步进展，保证问题100%闭环。更新评审文档与知识沉淀根据评审结论更新相关文档（如PRD、技术方案、测试用例），标注版本号与更新人，保证文档与最终输出一致。梳理评审过程中的共性问题和优秀实践，更新至团队“评审知识库”，供后续项目参考。三、通用检查清单模板评审阶段检查项检查标准检查结果（通过/不通过/待改进）问题描述责任人整改期限需求评审需求背景与目标是否清晰明确包含业务痛点、用户需求来源、目标量化指标（如“用户注册转化率提升20%”）产品经理-需求描述是否完整（用户故事/功能描述、场景、前置/后置条件）覆盖主流程、异常流程、边界条件（如“手机号输入为11位纯数字”）产品经理-需求优先级是否合理且与产品目标一致采用MoSCoW法（必须有/应该有/可以有/暂不需要），优先级与战略目标对齐产品经理-需求是否可测试、可验收定义明确的验收标准（如“注册成功后跳转至个人主页，显示用户昵称”）产品经理-与现有系统/功能的兼容性是否考虑明确与旧系统的数据对接方式、功能冲突点（如“新登录模块需兼容/手机号登录”）技术经理-技术方案评审架构设计是否符合高内聚低耦合原则模块划分清晰，接口定义明确，避免过度依赖技术经理-数据库设计是否合理（表结构、索引、关联关系）符合三范式，索引设置避免全表扫描，关联字段外键约束开发工程师-接口定义是否清晰（入参、出参、错误码、调用频率）接口文档完整，包含请求/响应示例，错误码符合团队规范开发工程师-异常场景是否考虑（错误处理、容错机制、降级方案）定义网络超时、数据异常、服务不可用等场景的处理逻辑技术经理-功能指标是否明确（响应时间、并发量、吞吐量）指标符合业务需求（如“首页加载时间≤2秒，支持1000并发”）技术经理-测试用例评审测试用例是否覆盖需求全场景（正常场景、异常场景、边界场景）用例数量≥需求数量*1.5，覆盖核心流程100%测试组长-用例描述是否清晰（前置条件、操作步骤、预期结果）步骤可执行，预期结果可量化（如“输入错误密码，提示‘密码错误，请重新输入’”）测试工程师-异常用例是否充分（非法参数、异常中断、数据冲突等）如“输入空用户名”“网络断开后重试”等场景是否覆盖测试工程师-自动化测试用例是否合理（核心流程、高频场景）自动化覆盖率≥60%，关键路径（如支付流程）100%自动化测试工程师-上线前评审发布方案是否完整（发布时间、回滚机制、灰度策略）明确发布窗口（如“凌晨2:00-4:00”），回滚步骤≤3步，灰度用户比例≥10%运维工程师-风险预案是否完善（技术风险、业务风险、舆情风险）针对数据库故障、流量高峰、用户投诉等场景制定应对措施项目负责人-监控指标是否到位（业务监控、技术监控）监控核心指标（如“注册量、接口成功率、服务器CPU使用率”）运维工程师-运营准备是否充分（运营方案、客服培训、问题反馈渠道）运营物料（如公告、教程）已准备，客服团队熟悉新功能运营经理-四、关键注意事项与风险规避避免“形式化评审”：保证评审材料提前分发，参会人员充分预审，避免会议中“临时看材料、走过场”；对高风险问题（如架构设计缺陷、核心需求遗漏）需“一票否决”，整改完成后不得二次提交。鼓励“开放沟通”：营造“对事不对人”的氛围，允许不同角色提出质疑（如研发可挑战需求的合理性，产品可反馈技术方案的实现成本），避免“一言堂”导致的风险遗漏。问题“可落地、可追溯”：问题描述需具体（如“登录按钮无响应”优于“功能异常”），责任方明确到个人（避免“研发团队”模糊表述），整改期限合理（一般≤3个工