2. 评审角色与职责

2.1 适用场景

当上线验收评审的组织架构明确后，必须清晰定义每位参与者的核心职责与决策边界。本章适用于以下场景：

• 新系统或重大功能版本首次上线前的预审准备会角色分配
• 多团队协作出品的SaaS平台或企业级应用预发布评审
• 包含基础设施变更、数据库迁移等高危操作的上线评审
• 引入第三方系统或对原有架构进行改造的回归性验收

2.2 前置条件

1. 项目已完成内部功能测试与集成测试，测试报告已产出
2. 《上线验收评审章程》已获项目经理签署，规定了角色任命原则
3. 各角色对应人员已有至少一次该角色对应职责的现场或线上评审经验
4. 评审物料清单（代码冻结记录、测试报告、运维检查清单）已准备就绪

2.3 操作步骤概要

1. 项目经理发起角色确认会议，明确本次评审的最终决策人（通常为项目经理本人或产品负责人）。
2. 产品经理演示业务功能，确认需求实现度与用户体验达标。
3. 开发负责人审查代码质量、技术债务及自测覆盖率。
4. 测试负责人展示最终测试报告，确认缺陷密度与严重缺陷清零情况。
5. 运维负责人评估部署脚本、回滚方案、监控告警及资源预留。
6. 所有角色在评审记录表上签署“通过”或“有条件通过”意见。

2.4 五大角色职责矩阵

下表精确限定了各角色的输入输出物、责任边界与记录材料。每个单元均与具体工件挂钩，避免职责推诿。

2.5 角色协作与数据流转示意图

以下SVG展示了五大角色在上线验收评审中的数据输入输出关系及决策传递路径。箭头代表信息的流向与依赖。

2.6 异常处理说明

职责边界内出现以下情形时，对应角色拥有否决权，评审过程暂停并升级处理：

• 产品经理拒绝签字：需求有不符合法规或严重体验问题，无法上线。
• 开发负责人拒绝冻结：未合并主线或存在未修复的安全漏洞（CVE评分≥8.0）。
• 测试负责人拒绝通过：P0~P1级缺陷总数>10%或冒烟测试失败。
• 运维负责人拒绝签署：回滚方案未验证或监控配置缺失。
• 项目经理指定干预：工期严重延误且风险可控时发起例外决策，需书面记录并抄送总监/CTO。

2.7 记录材料模板片段

实际操作中，应使用如下标准化签到表模板记录各角色职责履行情况。以下为基本字段：

【上线验收评审—角色职责签署表】
项目名称：__________  版本号：__________  日期：__________

角色        职责确认                签字         时间      结论
产品经理    □ 需求完整性                     ______    ______   通过□/不通过□
开发负责人  □ 代码冻结/无高危漏洞           ______    ______   通过□/不通过□
测试负责人  □ 回归通过/缺陷可控             ______    ______   通过□/不通过□
运维负责人  □ 部署就绪/回滚有效             ______    ______   通过□/不通过□
项目经理    □ 资源&风险确认                 ______    ______   最终决策：上线□/回退□/补充□

异常备注：___________________________________________
应急决策记录：_______________________________________

2.8 验收标准

• 角色定义清晰，无职责交叠或缺失区域（允许多角色共享检查项但必须注明主责人）。
• 每个角色在评审记录表上签字确认职责履行，项目经理完成最终签字。
• 异常发生时有明确的升级路径和仲裁机制，不影响后续评审流程串联。
• 记录材料完整归档，包含角色签署照片或电子签名。