在整车软件全栈自研浪潮下，DRE（ECU Owner）何去何从？

我是穿拖鞋的汉子，魔都中坚持长期主义的工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

如果你必须离开一个地方，一个你曾经住过、爱过、深埋有你所有过往的地方，无论以何种方式离开，都不要慢慢离开，要尽你所能决绝地离开，永远不要回头，也永远不要相信过去的时光才是更好的，因为它们已经消亡。

回归正题，本文主要分享在整车软件全栈自研浪潮下，DRE（ECU Owner）这个岗位何去何从？

话题的起因是995的大环境下，晚上九点多下班去地铁的路，跟几个好友讨论DRE这个岗位（在有的公司叫ECU Owner）的尴尬境遇。要知道以前OEM距离技术最近的就是DRE，获取第一手技术资料，对比现在，可真实不可同日而语。

由以下对话，加深对这个岗位的理解：

和朋友喝酒聊天，吐槽说，DRE越做越像项目经理啦！

所干的职责就是：

-> 追供应商交付，追问题，追进度，各种汇报，哪里有事都先找DRE;

-> 不是转自研了吗，需求和方案总要设计吧？

-> 这部分内容彻底划给系统功能工程师去做了。

职责成了一个管控项目进度的尴尬位置，拉通对齐信息。

关于DRE这个角色，以往在OEM，绝对是骨干生产力，现如今随着合作模式的转型，职责逐渐地被弱化。

过去，在合资车企独领风骚的年代，OEM与供应商的合作模式基本是软硬件全部委外。

不知是从互联网巨头踏入造车圈开始，还是从EEA由分布式转集中式开始；不论是主导还是被推着走，OEM开始搞自研。特别是在软件定义汽车这个浪潮掀起后，这种趋势越发明显。

从应用软件自研开始，逐渐地，基础软件自研、软件全栈自研、软硬件全栈自研。

传统车厂跳到一家软硬自研走在前面的OEM后，万万没想到通信终端的32960.2的过检需要自己带着测试、开发、软件项目经理团队，捧着十几个车机域控制器，在实验室里做测试过检。

一屋子的供应商为甲方主机厂在台架上吭哧做测试，只有我们是从主机厂亲自来的。规范解读、流程全都自己摸索，测完一遍拿着报告去找中汽研老师，哪里不对改哪里。一遍又一遍。

功能定义不对，系统功能工程师改定义；代码bug，开发老师现场改代码。

DRE在哪里？全栈自研后，没有所谓的DRE了。

传统委外开发模式，DRE的重心是管理结果。

DRE释放需求（期望结果）给供应商。供应商进行方案设计，交付结果。由DRE将结果注入工程项目流程，完成数模发布、试验管理、物料管理、装车管理等一系列工程任务。

而现如今全栈自研后，原来所谓的Tier1供应商不存在了，只有硬件代工厂、 元器件/模组供应商、第三方SDK供应商。

内部分工呢？

DRE管理供应商硬件开发部分的工作，由硬件平台项目经理负责；

DRE管理需求的部分，由软件项目经理负责；

DRE把结果注入造车流程的工作，由零件车型项目经理负责。

“DRE”没了，“DRE”被分解了。

全栈自研模式下的职能分工

自研，意味着：吸纳原有供应商的系统方案能力和开发能力，把knowhow从供应商回收至车企。

Knowhow的建立，通过人力资源流通实现，也可通过内部人员培养实现。

DRE的职责被分解细化到多个岗位。这种分解， 按照技能聚合的规律操作。

一个人所适合的工作，由经验面、知识面、能力面和兴趣面决定。

经典的DRE角色，多来自传统主机厂的SMT部门，非常熟悉造车流程，对零件的结果在整车层级的维度有着明确的期望定义，擅长跨部门协作，有丰富的基于零部件的项目管理经验。

零部件内部的软硬系统方案、开发能力，主要掌握在供应商出身的开发人员手中。开发人员熟悉零件内部的功能逻辑流转，但需要拓宽对于功能理解的边界。对于方案设计的着眼点，需要放在整车功能层级、全生命周期使用场景、面向工程用户和消费用户的维度进行考量。

所谓拓宽视野，需要拓宽的是对汽车行业的认知。

由于汽车软硬件开发人力资源池不足，现在许多OEM的开发人员是从非汽车行业吸收进来的。

隔行如隔山。

做手机的、做电脑的、做消费电器的，不同出身背景的人员，对于汽车理解的浅白，就如同汽车出身的人员对手机、电脑、消费电器行业的理解一样浅白。

知识栈、经验栈都有各行业独有的体系。想拓宽认知，只能不断学习，不断磨合，不断迭代。

而从岗位职责设计上，需要基于不同岗位的关注圈、经验圈和技能圈进行收敛聚合。

完成工作的关注圈聚焦在项目进度、流程方面的，将同类工作划分给有项目管理经验的人员作为其职责范畴。

功能实现本身，按基础支撑功能和平台业务功能分层，有BSP相关经验的进行基础支撑功能设计开发，由业务经验的进行平台业务功能设计开发。

使完成工作所需要的关注圈聚焦，付出同样时间，事半功倍，避免重复劳动。

对于个人，能够更深入技能；对于组织，更高效。

一些感慨

说是 “时代的脚步”也好，“前进的车轮” 也好， “发展的洪流”也好，现如今，技术是拦都拦不住地日日新。

新的不意味是对的，当下受追捧的也不是一直持久。

一些形态是需求对技术发展的妥协，是过渡，比如小挡板HUD；

一些形态是新兴事物浅表的审美，是需要打磨的，比如铺天盖地的大屏；

一些形态是还没准备好的决策，需要等待。比如3年前的V2X、Autopilot。

但是，大家太快了，你追我赶的，来得及冷静思考吗？来得及看市场表现吗？来得及充分论证吗？

他们上这个了，我们快快快抄过来！

这个功能，用户真的需要吗？

不是说要“培养用户习惯”吗？用着用着就需要了。

实现了这个功能后会引起1 2 3个问题。

但TOP3都是这样做的，这样做的能卖TOP3。

是这个逻辑吗？

管他呢，市场就是玄学啊！

改完了吗？

发布了吗？

测试通过了吗？

在吗？

在吗？

在吗…

如果被人说做得是工业垃圾，会感到失败。