团队协作基础：团队角色定义与RASCI矩阵

做ASPICE项目这么多年，我最大的感触是：流程再完善，人不对，全白搭。你想想看，一个项目里，系统工程师和软件工程师互相甩锅，测试工程师最后才被拉进来，项目经理天天救火——这种场景，我见过太多次了。

所以今天咱们聊聊团队协作的基础。说白了，就是两件事：谁该干什么，以及谁对什么负责。

一、核心角色定义

ASPICE里没有规定你必须设哪些岗位，但根据我的经验，以下四个角色是标配。嗯，这里要注意，一个人可以兼任多个角色，但千万别让同一个人既写代码又测自己的代码——我吃过这个亏。

1. 项目经理（Project Manager）

项目经理不是监工。他的核心职责是资源协调和风险管控。我个人习惯把项目经理看作“项目的大管家”——他得确保每个阶段该有的资源到位，该做的评审做了，该过的里程碑过了。

• 职责范围：制定项目计划、管理预算、协调资源、跟踪进度、处理升级问题
• ASPICE关注点：MAN.3（项目计划）、MAN.5（风险管理）
• 避坑指南：我曾经见过一个项目经理，天天盯着工程师的代码行数，结果团队士气崩了。项目经理要盯的是流程合规性，不是技术细节。

2. 系统工程师（System Engineer）

系统工程师是技术层面的“翻译官”。他得把客户的需求翻译成技术语言，再分发给软件和硬件团队。我在项目中遇到过最头疼的事，就是系统工程师写出来的需求模棱两可——软件工程师看了说“这能实现”，测试工程师看了说“这没法测”。

• 职责范围：需求分析、系统架构设计、技术方案评审、接口定义
• ASPICE关注点：SYS.1（需求获取）、SYS.2（需求分析）、SYS.3（系统架构设计）
• 避坑指南：我曾经带过一个项目，系统工程师把需求文档写得像天书，结果后期返工成本占了总预算的30%。记住：好的系统工程师，写出来的需求连测试工程师都能看懂。

3. 软件工程师（Software Engineer）

软件工程师是真正的“干活的人”。但很多软件工程师有个毛病——只管写代码，不管流程。我建议ASPICE项目里的软件工程师，至少要做到：代码写完了，单元测试也过了，评审记录也提交了。

• 职责范围：软件详细设计、编码实现、单元测试、代码评审
• ASPICE关注点：SWE.1（软件需求分析）、SWE.2（软件架构设计）、SWE.3（软件详细设计与单元测试）
• 避坑指南：我曾经见过一个软件工程师，为了赶进度跳过了单元测试，结果集成测试阶段发现了一个低级bug，修复成本翻了10倍。别省那点时间，不值得。

4. 测试工程师（Test Engineer）

测试工程师不是“找茬的”，他是质量的守门员。我经常跟团队说：测试工程师越早介入，项目风险越低。别等到代码写完了才把测试叫来，那时候已经晚了。

• 职责范围：测试策略制定、测试用例设计、测试执行、缺陷管理
• ASPICE关注点：SWE.4（软件集成测试）、SWE.5（软件合格性测试）、SYS.4（系统集成测试）、SYS.5（系统合格性测试）
• 避坑指南：我曾经遇到一个测试工程师，只测“快乐路径”，结果上线第一天就出了严重问题。记住：测试工程师的职责是找到问题，不是证明系统没问题。

二、RASCI矩阵：谁对什么负责

角色定义清楚了，但实际干活的时候，经常出现“我以为你做了，你以为我做了”的情况。RASCI矩阵就是解决这个问题的。

RASCI是五个字母的缩写：

角色	含义	通俗解释
R (Responsible)	执行者	活是你干的，出了问题先找你
A (Accountable)	负责人	最终拍板的人，背锅侠
S (Support)	支持者	帮你干活的人，但不背锅
C (Consult)	咨询者	做决定前要问他的意见
I (Inform)	知会者	做完后告诉他一声就行

这里有个关键点：每个活动只能有一个A。如果两个人都说“我负责”，那最后肯定没人负责。我见过最典型的例子——一个需求变更，项目经理说“我负责”，系统工程师也说“我负责”，结果需求漏了，两个人互相推诿。

实战中的RASCI矩阵示例

下面是我在一个实际项目中用过的RASCI矩阵，你可以参考：

活动	项目经理	系统工程师	软件工程师	测试工程师
需求获取	A	R	C	C
系统架构设计	I	A/R	C	C
软件详细设计	I	C	A/R	C
编码实现	I	I	A/R	I
单元测试	I	I	A/R	S
集成测试	I	C	S	A/R
系统测试	I	C	I	A/R
发布评审	A	R	C	C

三、角色与RASCI的配合要点

角色定义和RASCI矩阵是相辅相成的。光有角色没有RASCI，大家不知道具体活谁干；光有RASCI没有角色，你连谁该坐在哪个位置上都不知道。

我总结了几条实战经验：

• 角色是静态的，RASCI是动态的。角色定义了“你是谁”，RASCI定义了“你在这个活动里干什么”。同一个角色，在不同活动里可以是R、C、I。
• 别让一个人同时当R和A。除非项目特别小，否则执行者和负责人最好分开。为什么？因为自己检查自己，很难发现问题。我见过太多“自测通过，集成崩了”的案例。
• C和I不要太多。如果一个活动有5个C、8个I，那这个活动基本没法推进。我建议每个活动的C不超过2个，I不超过3个。
• 定期回顾RASCI。项目中期，角色可能会调整，RASCI也得跟着变。我习惯在每个迭代结束时，花15分钟过一遍RASCI矩阵，看看有没有需要调整的。

四、常见问题与避坑

最后，分享几个我踩过的坑：

• 坑1：项目经理当了所有活动的A。结果项目经理累死，其他人没事干。记住：A是拍板的，不是干活的。
• 坑2：测试工程师在需求阶段是I。等测试介入时，需求已经定了，想改都来不及。我建议测试工程师至少在需求评审阶段是C。
• 坑3：软件工程师在集成测试阶段是R。这会导致软件工程师既写代码又测集成，自己测自己，能发现问题才怪。集成测试的R应该是测试工程师。
• 坑4：RASCI矩阵写完了就扔一边。我见过最离谱的项目，RASCI矩阵写在项目计划里，但从来没人看过。那还不如不写。

好了，关于团队角色定义和RASCI矩阵，今天就聊这么多。下一章咱们聊聊沟通机制与信息同步——说白了，就是怎么让团队里每个人都清楚项目在干什么，别出现“我以为你知道”的情况。