85 lines
3.3 KiB
Markdown
85 lines
3.3 KiB
Markdown
---
|
||
type: responsibility_matrix
|
||
tags: [项目管理流程, 角色职责, RACI]
|
||
aliases: [角色职责, 职责矩阵, RACI]
|
||
source: AI_驱动_内部系统开发流程_V3.docx
|
||
status: active
|
||
owner: 内部技术团队
|
||
updated: 2026-05
|
||
---
|
||
|
||
# 角色职责矩阵
|
||
|
||
## 总览
|
||
|
||
| 角色 | 主要负责阶段 | 核心职责 | 典型产出 |
|
||
|---|---|---|---|
|
||
| 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 |
|
||
| 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 |
|
||
| 产品经理 | 阶段2 | 收敛需求、组织高保真模型、明确版本范围 | 高保真模型说明、项目周期与版本确认 |
|
||
| 前端 | 阶段2、阶段3 | 深度参与模型收敛、页面结构、按钮行为、组件复用、前端开发 | 高保真模型、前端技术评审、按钮行为矩阵、前端实现 |
|
||
| 后端 | 阶段3 | 设计接口、数据库、权限、安全、日志、回滚和服务能力 | 技术实现对接、后端服务、接口和数据库方案 |
|
||
| 算法 | 阶段3 | 判断是否需要 AI，设计输入输出、置信度、人工审核和风险控制 | 算法适用性判断、算法输入输出说明、置信度规则 |
|
||
| 测试 | 阶段2.5、阶段4 | 提前写测试用例、发现需求漏洞、正式测试、培训材料、上线反馈 | 测试用例初稿、正式测试报告、内部培训手册、上线问题回流 |
|
||
| 技术负责人 | 阶段0、阶段5 | 技术分级、风险判断、技术债治理和能力沉淀 | 技术债清单、业务原子能力沉淀清单、组件库与服务复用清单 |
|
||
|
||
## 业务主管
|
||
|
||
业务主管保证方向正确、主流程清楚、需求不漏大块。
|
||
|
||
职责：
|
||
|
||
- 判断项目是否值得做。
|
||
- 定义主流程。
|
||
- 定义日常操作入口。
|
||
- 明确业务人员每天先看什么页面。
|
||
- 拆分分支流程，指定业务人员补充。
|
||
- 确认异常流程。
|
||
- 确认业务完整性。
|
||
- 参与业务验收。
|
||
|
||
## 业务人员
|
||
|
||
业务人员负责具体分支流程和真实操作细节。
|
||
|
||
职责：
|
||
|
||
- 补充分支流程。
|
||
- 提供样本数据，例如 ASIN、订单、评论、用户、表格等真实样本。
|
||
- 使用 Vibe Coding 跑页面，验证是否符合真实操作。
|
||
- 补充异常场景。
|
||
|
||
## 算法
|
||
|
||
算法保证 AI 能力可控、可解释、可人工审核。
|
||
|
||
职责：
|
||
|
||
- 判断是否需要 AI，避免为了 AI 而 AI。
|
||
- 设计算法输入，明确模型需要哪些数据。
|
||
- 设计算法输出，明确 AI 返回什么结果。
|
||
- 制定置信度规则。
|
||
- 制定人工审核机制。
|
||
- 设计风险控制，确保 AI 判断错误时可以回退和纠正。
|
||
|
||
## 测试
|
||
|
||
测试不只是最后找 Bug，还要提前补漏，并负责内部培训材料。
|
||
|
||
职责：
|
||
|
||
- 高保真模型出来后先写测试用例。
|
||
- 用测试视角发现流程、按钮、权限遗漏。
|
||
- 正式测试主流程、分支流程、权限、异常和数据。
|
||
- 输出验收报告。
|
||
- 将测试用例转成业务操作手册。
|
||
- 记录上线问题并回流需求池。
|
||
|
||
## 关联条目
|
||
|
||
- [[AI驱动内部系统开发流程_V3_总览]]
|
||
- [[阶段0_项目入口分级]]
|
||
- [[阶段1_业务需求完整形成]]
|
||
- [[阶段2.5_测试提前补漏]]
|
||
- [[阶段4_测试培训上线回流]]
|