汽车电子软件组织的“角色”大起底

1

无法回避的“角色”

“角色”或“Role”，我们并不陌生，但不知道有多少人细想过。

作为一个人，我们不可避免地会被贴上“标签”，我们不是单一的抽象的人，除了姓名和身份证号，我们还会有各种各样的角色，可能是爸爸、妈妈、儿子、女儿、兄弟、姐妹、学生、老师、亲戚、朋友、敌人、北京人、上海人、中国人、外国人、男人、女人、工人、农民、演员、歌手……

总之，在不同的视角或领域下你会有不同的角色，背后会反映出你的责任、义务、权利等，社会心理学家莱威在《社会结构》一书中将角色定义为“由特定社会结构来分化的社会地位”。

说了这么多，也就是要引出我们工作中的“角色”。迁移一下定义，公司组织里的角色就是“由特点组织结构来分化的组织地位”。

组织内背负各种角色的人或群体成为了一个个功能块，承担着责任，背负着期待，贡献着智慧，推动着事务的进行。企业架构都是由各种各样的“角色”组成，流程都是由各种各样的“角色”推进，项目都是由各种各样的“角色”完成，可以说组织内最具活力的部分。

因此，不管是大企业还是小企业，都无法跳脱开“角色”来思考工作。大企业会拆分到更细，会有更多的角色，一个人担任的角色也会更少，分工更细更专；小企业相对粗放，没有区分出那么多角色定义，或者多种角色一肩挑。

职场人成熟的标志之一是，知道自己当下的“角色”和想要的“角色”，能够从“个人角色”走向“群体角色”。

接下来，我们可以聊一聊在一个比较完整的、成熟的汽车电子软件组织（供应功能电子软件模块的供应商或主机厂里自研的研发部门）里有什么样的典型角色，或可对相关从业者有些参考价值。

在汽车行业的运作模式里，角色一般会挂在这么三条线上：组织线、项目线和流程线。

组织线是指整体的、General的、服务于整个组织的，其角色是服务于所有项目的；

项目线多是执行层员工被拉到各个项目组里进行项目交付工作，日常工作基本都是这条线上完成的。由于汽车行业主体是按照项目来组织推动的，即所谓的矩阵型组织架构，所以项目角色也多按照职能来划分，我们每个人都是挂在这样的人事职能架构里的特定位置上，有直线汇报的顶头上司，在需要进入项目组工作时，也有虚线汇报的项目经理；

对于流程线角色呢，前两者更多地类似于静态的、可视的一种架构模式里的角色，而它是指业务流动到不同点位时对应的相关人员，是指特定组织流程在不同环节涉及到的责任人。流程线是人为定义的、理论的、抽象的，所以其角色多由具体的项目角色或组织角色来执行。

2

组织角色

第一个是Customer（客户），Customer会有两类：外部客户和内部客户。由于只有外部客户才具备直接影响公司新订单、新项目的作用，所以我们说起客户，更多地会想到外部客户，就像OEM对Tier 1来说。

而内部客户是公司组织内部要交付的下游，名义上的客户，实际上的合作者、扯皮者，就像OEM内部的整车验证对于模块开发来说。

这里的客户会更多地可以理解为客户这个抽象的概念，可以理解为公司、实体、组织、群体或各个人，而不是具体的某一个人。

因此，我们就需要一个Customer Window（客户接口），在供应商侧一般由Sales、PM、TPM或PDL来兼任，OEM内部没有实际的商务关系，也就由相应的DRE或PM或PE担任了，这个角色主要目的是找到一个唯一负责人和单一信息源。

有了客户，自然相对应的是Supplier（供应商），就是按Customer需求供应零件、服务或软件之类。

既然是商务关系，在Supplier和Customer之间就会有桥梁，从Customer到Supplier的桥梁是Purchase（采购），PR、PO、RFQ都是研发人员与采购交互的一些内容；而从Supplier到Customer就是Sales（销售），销售就是要和采购官方对接的。

还有一个角色，和销售一样，会关注市场，我们称之为Product Manager（产品经理），他会基于内外部环境、市场趋势、技术能力、组织策略等规划产品方向，所谓的Roadmap多出自这个角色。

成熟组织内都会有EPG这么个角色，它的存在主要是来定义、维护、优化各类流程体系的，我们所聊的角色定义也多由这个角色来完成。

对于常规工作，按照流程按部就班地完成即可，中人之才足够了，但工作总会有难点、有挑战，没挑战也需要创造挑战，这时就需要牛人——Expert（专家）出马了。

当然，专家未必都是大才，一般是业内某个职能上比较资深、经验比较丰富的人，在项目遇到一些难题时来支持解决。根据产品特点不同，可能会有不同的专家类型，比如架构、OTA模块、算法、标定、功能安全、EMC等等，也可能会有流程专家。

我们所做的工作的基本目的就是交付，电子电器件都要交付模块，需按照订单或其他要求完成对客户的交付，开发也会需要一些工程件，这块会涉及到Sample Shop（样件车间或工程车间）或Plant（工厂），在车间和工厂里当然还会有更多的角色，比如，计划、制造、测试等，他们不属于研发核心角色，不在交流范围，就不细说了。

再聊聊我们的Manager（职能经理），经理也是一种组织角色，主要负责行政上的管理和决策，负责为项目团队输送项目角色。总体来说，管钱和管人。

一个个挂着经理之名而无经理之权的项目经理带着一个个项目在做，但如果有了难以解决的问题怎么办？比如，资源冲突了，产线停线了，实验重大失效了……这时，单一职能的Manager往往不能解决问题，这就需要一个会议，上面有各种领导的会议，我们姑且称呼这个角色为Project Escalation Meeting（项目升级会），项目经理带着ppt上来诉苦和要钱要人要时间，到这个层面多数可以解决问题了，不行的话，就上到更高级别的会议。

3

项目角色

项目结构基本和产品结构相对应，所以项目角色也基本落在System（系统）、Software（软件）、Calibration（标定）、Hardware（硬件）、Mechanics（机械）以及Functional Safety（功能安全）和Cybersecurity（网络安全）这几块。其中，后面几部分共同组成系统。

硬件里基本的有HW Developer（硬件开发），整体负责一个项目的硬件技术部分，包括开始的需求和最终的交付。

结合硬件的特点，抽象上，它包含各种功能；具体上，它由各种电子元器件组成，所以还会有HW Component Owner（硬件元器件开发）（如MCU、ASIC、电容、传感器、PCBA等）和HW Function Owner（硬件功能开发）（如COM、Power、Watchdog等）。

有了开发，就要有测试，也就是HW Tester（硬件测试），他们会完成黑盒测试、EMC、鲁棒性、性能、I/O等测试。

HW的释放本身也可以看作是一个项目，所以理论上也存在HW Project Manager（硬件项目经理）这个角色，以统筹协调。

同理，SW Project Manager（软件项目经理）、Calibration Project Manager（标定项目经理）、ME ProjectManager（机械项目经理）也是类似，System层面一般会叫Technical Project Manager（技术项目经理）或Product Engineer（产品工程师）或Project Technical Leader（项目技术经理）等大同小异的名字，他们会对整个产品的技术部分负责。再往上走，就是整个项目的Project Manager（项目经理），他们可能关注到更多的东西，相较于TPM侧重于技术，PM在商务、法务、财务、生产、物流等层面涉足更广。

我们再回到SW层面，SW相对HW更复杂一点或者说更抽象一点，从SW Developer（软件开发）细分的话会有SW Architect（软件架构）、SW Function/Feature/Component Owner（软件功能开发）、SWUnit/Detail Developer（软件单元开发/详细设计）、SW Integrator（软件集成）。

对应开发，自然会有测试，相应的有SW Unit Tester（软件单元测试）、SW IntegrationTester（软件集成测试）、SW Tester（软件功能/需求测试）等。

而CalibrationEngineer（标定工程师）更多在于实车匹配上，使用不同的算法调试不同场景下的参数，然后提供给集成工程师与SW完成集成。

机械部分是另一个领域，Design（设计）、CAD（3D/2D制图）、CAE（仿真）、Test（测试）也是有全链路的角色，不过这不是我们的重点，暂且不表。

网络安全工程师和功能安全工程师虽然比较火，但角色上还没有拆分那么细，零星几个人负责或者被系统的工程师兼任。

最后就是系统，系统的概念在业内也比较成熟了，比如System Architect（系统架构）、Requirement Engineer（需求工程师）、Feature Owner（子功能责任人）、System Tester（系统测试）等。

在前面文章我们集中讲过系统和软件的工作，所以角色上就不再扩展介绍了。

4

流程角色

流程千变万化。比如，defect、变更、风险、交付、质保、需求、配置等，流程又无法脱离组织和项目存在，所以实际流程里的角色更多是前两种角色来担任的，而且流程每一个点位都有一个角色，具体由组织或项目里的哪个角色担任和不同公司定义及业务差异有关，数量种类繁杂，在本文里就不扩展，姑且举几个例子即可。

比如，defect提出者多为测试；变更提出者可以为任何角色，但多数是客户；风险提出者往往是项目经理；需求管理的负责人一般为系统架构或软件架构；配置管理员可由项目经理或QA来兼任……

5

写在最后

粗略地过了一下业内习惯的一些角色定义方式，挂一漏万，仅供参考。

最后还是要强调下，角色和人员不等同，你可能只有一个人，一个人就是一个团队，那相当于你一个人兼任了多个角色，而不代表这些角色不存在。因为，拆分为更细的角色是一种精细化运作的思维。