为什么新能源车企HR拒招传统主机厂员工

文章又名：《软件定义汽车背景下，传统主机厂DRE何去何从》。

故事要从“软件定义汽车”开始。

软件定义汽车，可理解为把汽车抽象成四个轮子一个手机。四个轮子代表的是底盘、动力等传统机械结构；手机意味着互联互通、丰富的软件应用生态、独立于硬件的迭代、可以通过软件创造盈利点的能力。

“软件定义汽车”思想指导下的汽车形态，是面向用户体验的、是智能网联的、是功能可快速迭代的、是需要具备业务的高可扩展性的。

这分别意味着：

面向用户体验：用户体验专家（用户使用数据采集和分析专家）；

智能网联：物联网专家；

功能可快速迭代：软件自研；

业务高可扩展性：为实现高可扩展性，需要深入理解后对通讯系统架构重构、对软件架构设计重构（所谓SOA化）、对硬件资源平台重构。

如果软件定义汽车是汽车产业正确的转型方向，那么上述这些特征是转型车企的必备。

零件的设计过程，大致包括：产品定义、需求定义、系统功能设计、软件架构设计及开发、硬件架构设计及开发。

其中，单零部件的系统功能设计，除需求业务逻辑的本身实现功能外，还包括电源模式系统功能、MCU系统功能、板间交互的数据协议、接口通讯协议等等。

而需求业务逻辑的实现，涉及软硬件架构的设计。在既有硬件平台上，软件架构设计从上至下，开发范畴从应用层开发、中间件开发、到安卓框架服务改写、操作系统改写等逐层深入。如现有的服务SOA化，则从下至上定义服务、服务接口调用逻辑、通信协议、应用设计等等。

OEM和零件供应商的传统合作模式，职责分界点在需求定义。

需求定义往左由OEM完成，需求定义往右由供应商完成。

OEM向供应商提出产品功能和性能指标等需求，而后，该零件对OEM而言即为黑盒，不knowhow如何设计并实现的系统功能逻辑、软硬件架构，零件的验收也是对应最初需求的功能和性能指标。

而现如今，为了应对软件定义汽车的转型、满足上面所说的“面向用户体验的、智能网联的，是功能可快速迭代的，是需要具备业务的高可扩展性的“等一系列特性，OEM开始自己搭建相应的能力。

新形态下，OEM与供应商的边界也越来越往右偏，软件先从应用软件入手，再逐级向下渗透。

原来完全由供应商承担的工作，现在开始逐渐被OEM吸纳。

那么，问题来了。这个转型的过程，自研的人从哪里来？

随着智能网联汽车时代的到来，源自互联网行业的大佬纷纷下场造车。他们来了，带着完备的自研能力和自研人才来了。

回答上面的问题。当主机厂转型开始，新增的软硬件开发人才，要么是校招新人培养，要么是从供应商处挖开发人员。

现在出现了几个怪象。

1、 传统主机厂员工出走供应商镀金，供应商比传统主机厂员工更好找工作。

过去大都是供应商想挤进传统头部主机厂，现在反过来了，头部主机厂的员工开始愿意选择去供应商参与开发项目镀金。

主机厂HR宁愿跨行业找那些没有汽车背景但有自研能力的供应商，也不愿考虑传统开发模式的主机厂员工。

由于主机厂来势汹汹，开价很高，一些供应商已经顶不住压力，开始隔断开发人员和主机厂之间的直接接触，甚至给开发人员起花名，而不透露真实姓名。

2、岗位招聘，旱的旱、涝的涝。

汽车行业的招聘岗位和求职人员分布非常不均。

新兴热点岗位，如自动驾驶、智能网联、动力电池、SOA化等人员非常不饱和，需求量大，人员流动也较大（到处挖人）；而传统岗位如底盘内外饰等则过饱和，新增岗位需求少，有岗位释放出来投递量高、竞争激烈，人员流动也相对较小。

3、在某些专业上，泛亚不再是行业标杆，大家更想看"蔚小理"是怎么做的。

不得不说，智能网联、智能驾驶领域，以“蔚小理”为代表的新势力确实做到了行业领先。由此，在这些领域里，传统头部车厂工程师不再是HR首选，他们更想招聘有新能源车厂工作经历的人，首选“蔚小理”。

以前，泛亚，这一汽车研发界的黄埔军校，员工很少出走，出走也必升职。而现在，开始有声音唱衰泛亚，乃至唱衰泛亚的DRE。

有人说，泛亚的DRE，“什么都让供应商做，自己什么都不会。“

作为一名前泛亚的员工，我听了很无奈。

大部分传统车厂的DRE确实缺失代码能力，对软件的实际开发了解确实不如供应商。计算机和软件方面虽不至于“什么都不会”，但在当前的风向下，不太懂计算机和软件而想跳到更高价格和前景的岗位，确实不易。

有时不禁感慨，我们这代面向传统汽车开发模式培养的汽车人，是刻着时代烙印的一代。

下面这些话可能会得罪人，但我还是想如实阐述我所看到的。

过去的十几年，汽车产业虽有起有落，但总体还是蓬勃发展的趋势。各大工科院校的汽车专业都作为重点专业来建设师资力量，本科录取分数线在各专业居高位。每年高考季结束，能够被汽车专业录取的大都是这所大学里的高分生。

由于高薪、稳定、可靠，大众、通用等顶尖车厂成为了绝大多数汽车专业学生的首选。

相应的，大众、通用，这些顶尖的传统车厂的校招生源，基本都来自顶级工科院校的汽车学院。

在这些顶尖主机厂，轻易能找到上海交大、同济、吉大、东大、哈工大等高校的本科、研究生同学。举个例子，吉大车辆工程专业几乎成了一汽大众、泛亚的生源培训基地。

进入工作岗位后，作为一名标准的零件DRE，必须要会的基本功是看数模。每个DRE都要进修公司的UG培训，每个零件小组都有自己的工作站。

而那些电子电器件的DRE，除了要会看零件数模，还要掌握总线的网络拓扑、报文信号、诊断服务等等与整车业务强相关的内容。

至于零部件内部的实现方式，DRE们很少关心，外包供应商会解决。彼时的控制器没有那么高的算力要求，仅使用MCU就可满足基本的控制逻辑。

处于这个时代的汽车，不论是产品竞争力还是价值流向，都是偏硬件的、机械的。

大学里，专业课科目也是面向彼时就业场景设计的。

车辆工程的专业课，基本包括：机械原理、机械设计、机械制图、理论力学、材料力学、汽车理论、汽车发动机原理、车辆构造、电工学、流体力学等等，大多是偏机械、偏硬的科目，与软件相关的基本局限于计算机原理和C语言编程。

放在过去，这些课程对于主机厂DRE的专业需求而言是非常对口的，但在现在，软件定义汽车的背景下，对软件能力的要求越来越高，过去培养的汽车人才，已经开始跟不上时代发展的脚步了。

有人这么总结传统主机厂DRE和供应商在整车开发中的行为。

供应商就是厨子，传统DRE就是点菜员，开发零件就是叫了个锅包肉。

厨子知道做锅包肉的流程，知道搭什么样的炉灶，用多大的火候，是蒸还是炸，放多少盐加多少料勾多少芡。但厨子不清楚这个锅包肉做好后是给什么宴会准备的，其他的配菜是什么，宴会的主题是什么、流程是什么，宴会的整体协调方式是什么，组织者的黑话是什么意思，都有哪些人参加，喜好是什么。

厨子只管在指定的时间，把点菜员点的锅包肉按要求做好。此外的事情，都是点菜员参与负责的。

点菜员对于锅包肉本身的理解，就是“猪肉、胡萝卜丝、葱丝，要脆，要甜，要片大”，再深入一些，就是了解到“先挂淀粉浆再炸，炸完再炒糖浆”。

点菜员不会、也不需要了解到厨子的实际工作细节，比如要把肉拍散；要有两口锅，但只有一个炉灶要合理调度资源；菜板只有那么巴掌大，要合理使用缓存空间等等。

从这么个小例子上，大概可以看出，供应商更关注于功能的实现本身，传统DRE更关注承载功能的业务整体效果和流程把控。

再说最近吃到的一个瓜。

自动驾驶的优秀生Pony.AI暂停了造车业务。根据离职员工的说法，公司内部可能“把造车想的简单了，对造车缺少了些敬畏之心”。

过于看重软件研发、重软件轻硬件，把“软件定义汽车”的理念放在最高优先级，可能会走向另一个极端。

缺少对精密机械产品制造和庞大工程流程管控的敬畏，可能是做软件出身者常有的思维局限。

那么，问题来了。

有丰富软件自研能力的供应商 PK 传统开发模式的DRE，谁更胜一筹呢？

我个人理解，没有谁更胜一筹。

大家的岗位职责都同样重要、同样的缺一不可。当下所谓的“重要岗位”，是供需不平衡的结果。真正解决这个问题，要从人才培养源头入手。这需要时间的酝酿和制度保证。

而当下，不论是供应商的开发人员进入主机厂，还是传统主机厂员工接触自研，没有哪方是轻而易举就可适应新环境的。机会是留给那些看得清方向并且肯为之钻研的人。

到这里，想说一说我写这篇文章的初衷。

作为一名从传统主机厂做非量产项目的DRE，转为新势力主机厂做量产非自研项目的DRE，后转为系统工程师设计系统功能并尝试设计软硬件架构，后又转为新势力主机厂做量产自研项目的系统工程师，我和供应商的羁绊，从单纯的需求-外包开发，慢慢演进为需求定义、流程定义、算法定义-供应商外包开发，到现在，岗位职责是承接上游产品定义，设计系统功能、流程、算法、软硬件架构，对接下游软硬件开发工程师。组内其他的系统工程老师们基本都是从供应商实打实做产品自研后转型过来的。

这一路走来，我最大的感触就是，我们正处在汽车行业变革的中心。

回想我从校招入职，一步一步能走到今天，最大的原因是“没有分寸”。

没有固守在岗位职责圈定的范畴内，一腔想弄明白工作原理、架构、数据流的热忱，推着我不断地去问、去找、去学习。感谢每个被我的问题逼到欲哭无泪的供应商朋友，感谢被供应商朋友逼哭后又继续求索的我自己。现在能和供应商朋友做组内同事，感觉仿佛闯完了一个阶段性的关卡。感谢这种没有分寸，让我看到、学到了更多。

行业在迅猛变革，任何固步自封、停滞不前的人都在后退。面对行业的未来飞速发展，我只想说：道阻且长，行则将至；但行好事，莫问前程。

总结、共勉和自励。

希望努力耕耘的人都能有收获。