第4章 评审参与角色总览：甲方建模团队、乙方开发团队、QA、架构师、业务方
学习目标：明确五大核心角色在模型边界确认评审中的具体职责、输入输出边界与协作关系，减少因职责重叠或遗漏导致的评审停滞。
适用场景
- 模型边界确认评审首次启动时，需要为评审组划定角色与职责。
- 历史评审中出现过职责推诿、角色冗余或信息孤岛的项目。
- 跨组织（甲方/乙方）联合评审，需用统一语言定义责任边界。
前置条件
- 项目已建立评审组织架构，指定评审主席（通常由架构师或项目经理担任）。
- 各角色至少明确一名正式代表、一名备份代表。
- 已发布《模型边界文档 v0.5》作为评审输入。
- 评审计划（时间、地点、议题）已通过邮件或项目管理工具周知全员。
操作步骤
| 步骤 | 活动 | 责任角色 | 输出 |
|---|---|---|---|
| 1 | 主持人宣读评审目标与角色定义 | 架构师（主席） | 评审角色清单（含备份） |
| 2 | 各角色逐一确认职责矩阵 | 全员 | 职责确认签名表 |
| 3 | 建立沟通渠道与仲裁机制 | 架构师 + 甲方建模负责人 | 通讯录 & 争议升级路径图 |
| 4 | 分配评审检查项（按职责领域） | 各角色自行领取 | 个人评审待办清单 |
| 5 | 确认角色边界后启动正式评审 | 主持人 | 评审启动通知 |
输入输出物
- 输入：《模型边界文档 v0.5》、《评审组织机构表》、《历史评审复盘记录》。
- 输出：《职责矩阵总表》（含五角色）、评审角色签到表、沟通仲裁路径图。
责任边界
| 角色 | 核心职责 | 边界（不负责） | 关键交付物 |
|---|---|---|---|
| 甲方建模团队 | 提供业务需求、业务术语定义、验收标准 | 不负责技术实现细节、不评估代码质量 | 业务场景用例 / 验收准则列表 |
| 乙方开发团队 | 提供技术可行性分析、接口定义、性能预估 | 不负责业务规则修改、不保证非功能需求完整性 | 技术方案节选 / 接口契约草稿 |
| QA | 检查评审流程合规性、测试用例覆盖率、缺陷追溯 | 不评审业务正确性、不替代开发做决策 | 评审合规检查表 / 缺陷预分析报告 |
| 架构师 | 主持评审、技术决策仲裁、非功能需求确认 | 不具体撰写需求、不替代QA做验证 | 评审纪要 / 技术决策记录 |
| 业务方 | 确认模型是否符合实际业务流程、数据语义 | 不评审技术实现、不决定实现方案 | 业务确认签字 / 变更需求说明 |
关键原则：
“谁提供、谁确认、谁签字”——每个角色仅对自己负责的部分拥有决定权与签字权，避免跨域决策导致后续推责。
“谁提供、谁确认、谁签字”——每个角色仅对自己负责的部分拥有决定权与签字权，避免跨域决策导致后续推责。
记录材料
- 职责矩阵总表：包含角色、责任人、替代人、职责条目、确认状态。
- 评审角色签到/确认表：电子或纸质签名，含日期。
- 争议升级路径图：记录当角色间出现职责争议时，应由架构师先协调，无法解决则升级至项目决策委员会。
异常处理
| 异常场景 | 处理措施 | 责任人 |
|---|---|---|
| 某角色代表临时缺席 | 启用备份代表，并由主持人在评审开始前单独解释职责边界 | 架构师 |
| 角色间职责定义重叠 | 现场仲裁：由架构师根据责任边界表划清界线，无法达成时执行争议升级流程 | 架构师 + 决策委员会 |
| 角色拒绝签署职责确认表 | 暂停评审，记录拒绝理由，由项目管理层介入协调 | 项目经理 |
| 评审中新增角色需求 | 暂停评审，补充角色定义与职责矩阵，重新执行第1-3步 | 架构师 |
验收标准
- 所有五大角色均已在职责矩阵总表中签字确认。
- 各角色能口头复述本人的核心职责与不可跨越的边界。
- 不存在同一职责条目被两个及以上角色同时认领。
- 沟通仲裁路径图已公告并全员知悉。
- 评审组能依据当前角色划分至少完成一次模拟评审检查。
常见误区：
1. 将“甲方建模团队”与“业务方”混为一谈——业务方仅验证业务语义，不负责模型结构设计。
2. 让QA承担评审主持人角色——QA应专注合规性，主持工作应由架构师负责。
3. 缺乏备份机制导致评审中断——至少为每个角色指定一名备份人员。
1. 将“甲方建模团队”与“业务方”混为一谈——业务方仅验证业务语义，不负责模型结构设计。
2. 让QA承担评审主持人角色——QA应专注合规性，主持工作应由架构师负责。
3. 缺乏备份机制导致评审中断——至少为每个角色指定一名备份人员。