第2章：跨团队角色定义与责任矩阵
1. 适用场景
本章适用于以下评审或协作场景：
- 多团队参与的大版本PRD启动阶段——当PRD涉及前端、后端、算法、测试、设计、数据等多个职能团队时，必须先统一各团队在评审过程中的角色定位。
- 跨部门责任边界模糊的项目——如果历史评审中出现过“无人确认需求变更”“验收标准无人背书”等责任归属混乱情况，则需要通过本章内容建立清晰的RACI矩阵。
- 首次引入PRD评审流程的新团队或新项目——为新成员提供“谁负责、谁批准、找谁咨询、知会谁”的操作依据。
2. 前置条件
- 已完成《PRD模板与评审阶段的统一版本约定》（第1章）的团队共识对齐。
- 已识别本次PRD评审涉及的全部团队清单（如下游开发组、QA、设计中心、数据平台、运营策略组等）。
- 各团队已指派至少一名对接负责人（TL/PMO或指定代表），且该负责人已获得团队内部的授权。
- 已准备好企业协作平台（如Confluence、飞书文档、FigJam等）用于记录RACI矩阵以及后续的签字确认。
3. 操作步骤
- 列出全部涉众团队：参照表2-1 标准涉众清单模板，将参与PRD全生命周期的团队名称填入左侧列。
- 分解PRD评审的关键活动：定义从“PRD初版提审”到“终版归档”之间的核心节点，如：Figma原型对齐、技术可行性评估、测试用例预审、数据埋点确认、法务合规审查、终版签字等。
- 对每个活动-团队交点分配RACI：
- R（负责）——实际执行该活动的人/团队；
- A（批准/问责）——对结果最终拍板的人/团队；
- C（咨询）——在决策前需要提供输入意见的人/团队；
- I（知悉）——活动完成后只需要被告知结果的人/团队。
- 可视化发布&公示：将完成的RACI矩阵张贴在PRD评审频道或项目主页，并设置异议窗口期（通常为2个工作日）。
4. 输入输出物
| 类型 | 描述 | 示例/格式 |
|---|---|---|
| 输入 | 团队花名册、产品路线图、PRD初版目录 | 飞书多维表格、JIRA Epic信息 |
| 输出 | 【PRD评审RACI矩阵V1.0】 | 在线文档（含表头：活动｜团队1｜团队2｜团队3……） |
| 输出 | 【角色职责说明书】 | 针对每个团队/角色的详细操作边界（1~2页PDF） |
5. 责任边界
- 产品经理(PM)：承担PRD内容的主要编写责任，同时也是评审活动的组织者和推动者；但不是技术可行性的最终批准者。
- 技术团队TL：负责技术实现方案评估与成本估算，但不能单方面否定需求——必须给出可替代方案并计入A节点。
- QA团队：负责可测性与验收标准的对齐，但不对需求价值做决策。
- 设计团队：负责UI/UX在PRD中的落地方案，但不能变更核心业务逻辑。
- 关键原则：每个活动必须有且仅有一个A（批准）角色；若存在争议，上升至项目PMO或产品委员会裁决。
6. 记录材料
- RACI 会议纪要：包含各团队对自身角色的确认签字（电子签或飞书审批流截图）。
- 角色变更日志：当项目进入下一迭代或人员发生调动时，更新RACI矩阵并记录变更原因、日期、变更人。
- AR记录：在首次RACI对齐会上产生的待办事项（如“开发团队需在周三前补充算法评估”“设计团队需更新字体规范文档”）。
💡 小提示： 建议使用统一的在线表格维护RACI矩阵，并利用“冻结首行+条件格式”快速识别某个活动是否存在多个A或缺失A的情况。
7. 异常处理
| 异常场景 | 处理方式 |
|---|---|
| 某个活动出现多个A（批准） | 立即发起一次10分钟站会，由PMO裁定最终A；如果仍无法裁定，上升至产品委员会并在PRD评审记录中注明裁决层级。 |
| 某团队拒绝接受分配的角色（如“我不该是I，我必须参与C”） | 先由PM与团队TL沟通确认其真实原因；若因资源不足，可在RACI中标记为“C-限时”，即在特定窗口期内提供咨询，过期自动变更为I。 |
| RACI公示期内无人提出异议，但执行时发现角色缺失 | 触发紧急补位流程：在当日站会上声明缺失活动，指定一名临时R，并在2个工作日内完成正式RACI更新。 |
| 跨时区团队无法同时参加对齐会 | 采用异步确认模式：将RACI草案录制成5分钟讲解视频，附在文档开头；各团队在48小时内在对应单元格批注确认，PM收集批注后发布终版。 |
⚠️ 避免常见陷阱： 不要将RACI矩阵做成“一刀切”模板——不同阶段的PRD（MVP vs 完整功能 vs 合规升级）对团队的依赖程度完全不同。务必在每次评审前根据实际范围调整RACI。
8. 验收标准
- 完整性：RACI矩阵包含所有涉众团队（≤5个团队时可手动校验；>5个团队时建议使用脚本检查表头数量和活动行数）。
- 唯一性：每个活动行中恰好有且仅有1个A（批准单元格）。R与C数量不限，但不可为0（R不能空缺，C至少0个）。
- 可追溯性：当翻看V1.0版本的RACI矩阵时，能看清每个角色分配的时间、依据以及是否已获得该团队负责人的确认答复。
- 可执行性：实际评审开始前，所有指定为R和A的人员已收到系统通知（如飞书@消息）并确认知晓自己的责任。
附：RACI缩略参考
R = Responsible → 执行者 （谁做这件事）
A = Accountable → 批准者 （谁最终拍板/担责）
C = Consulted → 咨询者 （决策前必须咨询的人）
I = Informed → 知悉者 （完成后通知的人）