3. 评审角色与责任边界
3.1 适用场景
本章流程适用于以下典型场景，帮助团队在AI产品特性边界评审中快速对齐角色职责、减少协作摩擦：
- 首次建立评审机制：团队初次引入特性边界评审流程，尚未形成固定的角色分工共识。
- 职责模糊导致评审低效：已有评审会议但经常出现“该谁决策”“该谁准备材料”的争议，会议超时且结论模糊。
- 跨部门协作复杂：涉及产品、开发、测试、业务方等多个职能，各方对“边界”的理解和话语权重不一致。
- AI特性不确定性高：模型行为边界、数据依赖、效果度量等AI特有维度需要多角色联合界定，责任交叉易遗漏。
🔍 识别信号：如果团队在评审中出现“这个不是我的事”“我以为你们已经确认了”“技术边界为什么让业务来定”等对话，说明角色边界需要显式定义。
3.2 前置条件
在启动本章角色边界界定流程之前，必须满足以下条件：
- 已完成《产品需求文档》初稿（至少包含特性描述、核心指标、已知约束）。
- 已确定评审团队成员候选名单，覆盖产品经理、开发工程师、测试工程师、业务方代表四个角色。
- 已制定评审会议议程草案，并预留角色职责对齐环节（至少30分钟）。
- 各角色已收到预审材料并确认出席，业务方已书面授权代表参与决策。
3.3 操作步骤
按照以下5个步骤完成评审角色与责任边界的界定与确认，每个步骤均需保留执行记录。
-
步骤一：识别并确认关键角色
对照特性类型，从产品经理、开发工程师、测试工程师、业务方中确认本次评审的必须参与角色。若涉及数据合规、算法安全等专项领域，需额外邀请专家列席。 -
步骤二：分发评审材料并预审
产品经理在评审会议前2个工作日发出材料包，包含PRD、技术可行性初评、测试策略草案、业务价值说明。各角色在预审阶段标注职责相关疑问。 -
步骤三：召开边界评审会议，对齐角色职责
会议主持人（通常为产品经理或技术负责人）逐项过评审Checklist，每项均明确“谁主责、谁支持、谁审批”。使用责任矩阵（RACI）实时记录。 -
步骤四：签署责任矩阵确认书
各角色代表在确认书上签字或电子签名，确认已理解并接受自身职责边界。确认书作为后续变更的基线文档。 -
步骤五：归档评审记录并同步至项目看板
将签字的责任矩阵、会议纪要、待办事项更新至项目管理工具（如Jira、TAPD），并通知全体项目成员。
3.4 输入输出物
| 类型 | 名称 | 责任方 | 格式/备注 |
|---|---|---|---|
| 输入 | 产品需求文档（PRD） | 产品经理 | 包含特性边界、核心指标、已知约束 |
| 输入 | 技术可行性初评报告 | 开发工程师 | 含依赖系统、数据需求、风险预估 |
| 输入 | 测试策略草案 | 测试工程师 | 含测试范围、环境要求、质量门禁 |
| 输入 | 业务价值说明 | 业务方 | 含预期收益、使用场景、成功标准 |
| 输出 | 角色责任矩阵表 | 产品经理（汇总） | RACI格式，全员签字 |
| 输出 | 评审会议纪要 | 产品经理（记录） | 含决议、待办、风险 |
| 输出 | 边界评审Checklist（已签署） | 全员 | 逐项确认版本 |
3.5 责任边界
各角色在AI产品特性边界评审中的核心职责、决策权及关键输出物定义如下：
| 角色 | 核心职责 | 决策权 | 关键输出物 |
|---|---|---|---|
| 产品经理 | 定义特性边界范围；判断优先级与业务价值；管理需求变更；组织评审会议 | 边界变更审批、需求优先级排序、评审会议召集 | PRD、边界定义文档、评审议程、责任矩阵 |
| 开发工程师 | 评估技术可行性；提供实现方案与成本估算；识别技术依赖与风险 | 技术方案选择、可行性结论、技术风险定级 | 技术评估报告、实现方案设计、依赖清单 |
| 测试工程师 | 确定测试范围与策略；评估质量风险；制定准入准出标准 | 测试准入/准出决策、缺陷等级判定、测试环境准备 | 测试策略文档、质量风险评估表、测试用例集 |
| 业务方 | 确认业务价值与需求真实性；提供业务数据与场景样例；澄清歧义 | 需求有效性确认、业务优先级排序、验收标准认可 | 业务价值确认书、场景清单、验收标准草案 |
📌 边界清晰化原则：每一项特性边界的“定义权”归产品经理，“可行性否决权”归开发，“质量门禁权”归测试，“价值确认权”归业务方。任何角色不得替代其他角色的决策权，但可以发起联合复议。
3.6 记录材料
每次评审会议必须生成标准化的记录文档，以下为推荐的责任矩阵与会议纪要模板（JSON格式，可导入项目管理工具）：
{
"评审会议": {
"项目名称": "AI客服语义升级",
"特性名称": "多轮对话边界确认",
"会议日期": "2025-03-21",
"参会人员": [
"产品经理: 张琳",
"开发: 王海",
"测试: 李彤",
"业务方: 陈雯"
]
},
"责任矩阵": [
{
"评审项": "特性范围边界",
"产品经理": "R",
"开发": "C",
"测试": "I",
"业务方": "A"
},
{
"评审项": "技术可行性评估",
"产品经理": "I",
"开发": "R",
"测试": "C",
"业务方": "I"
},
{
"评审项": "质量风险定级",
"产品经理": "C",
"开发": "C",
"测试": "R",
"业务方": "I"
},
{
"评审项": "业务价值确认",
"产品经理": "C",
"开发": "I",
"测试": "I",
"业务方": "R"
}
],
"待办事项": [
{"事项": "补充边缘case数据样本", "责任人": "业务方", "截止日": "2025-03-25"},
{"事项": "评估模型推理延迟对边界的影响", "责任人": "开发", "截止日": "2025-03-24"}
]
}R=主责，A=审批，C=咨询，I=知会。此模板可在每次评审中复用，形成历史基线。
3.7 异常处理
| 异常场景 | 处理方案 | 责任方 |
|---|---|---|
| 产品经理临时缺席且无人代理 | 评审会议改期，需至少提前4小时通知全员；若已召开，仅做信息收集，不做边界决策 | 会议组织者 |
| 开发与测试对技术边界理解严重分歧 | 暂停该条目讨论，由开发与测试在24小时内产出联合技术备忘录，提交产品经理仲裁 | 开发工程师、测试工程师 |
| 业务方临时变更需求范围（新增特性） | 评估变更是否影响已确认边界；若有影响，标记为“变更请求”，启动单独变更评审流程，不阻塞当前会议 | 产品经理、业务方 |
| 多方对同一特性的责任归属产生争议 | 主持人组织现场投票（产品经理、开发、测试、业务方各1票），若2:2平局，由产品经理终裁 | 会议主持人（产品经理） |
| 评审超时但未完成全部条目 | 已确认条目现场签字；未确认条目形成待办，指定责任人与期限，在48小时内完成线上确认 | 产品经理 |
⚠️ 红线原则：任何角色不得在未签确责任矩阵的情况下，自行扩大或缩小自身职责边界。发现此类行为，须在下次站会上立即纠正，并在责任矩阵中更新记录。
3.8 验收标准
本章流程执行完毕后，需通过以下所有验收项方可视为完成：
- ✅ 已形成经全员签字的《角色责任矩阵表》，包含产品经理、开发、测试、业务方四个角色的明确职责划分。
- ✅ 每个评审项在矩阵中均有唯一“R”（主责）角色，不存在无人负责或多人争抢决策权的情况。
- ✅ 所有异常场景均已记录在案，且处理方案得到相关责任方确认。
- ✅ 会议纪要已归档至项目共享空间，并同步至项目看板，全体成员可查阅。
- ✅ 待办事项已分配具体责任人和截止日期，且已纳入迭代跟踪。
- ✅ 各角色代表均能口头说出自身在特性边界评审中的核心职责和决策权范围。