OEM该如何打造面向软件的队伍？

（Source:Bing）

文/侯哥

在上次的文章《谈谈SDV时代OEM的组织机构设计》发出之后，有一些朋友问我具体应该如何去做？

说句心里话，每个OEM都是一个巨型的组织，是一个无比复杂的系统，随便哪个OEM都是上万人，研究机构也都有几千人以上的规模，又有着不同的所有制的背景和不同的股权结构，大家的市场策略、技术积累、人员结构和对未来的预期都是不同的，想找出一个普遍适用的方式根本就是一项不可能完成的任务。

不过，既然SDV是一个新的时代，那么这个新的时代一定有一些特有的东西是以前的时代所不具备的。下面，我们就从这些特有的东西来入手，看看在这个新的时代中，我们在组织机构的设计上可能会有什么变化或者特点？

SDV的核心是软件，这是所有人普遍的共识。不管欧美的同行们是否也热衷于谈论软件定义汽车，但是大家对软件的重视已经是毋庸置疑的了。那些已经在软件行业有了相当实力的“局外人”——如苹果、百度、华为和阿里们都已经开始参与到这个游戏中来。虽然，大家的套路各不相同，但是躬身入局已经是不争的事实。为啥？因为既然汽车即将由软件所定义，那么这些软件大佬不可能置身事外，眼看这么大的一个蛋糕被别人所瓜分。

既然软件成为了汽车行业下一个时代的核心，那么，提升软件能力也就是一个必须要做的事情。如何提升软件能力？

首先要有软件的开发队伍，否则提升什么呢？这看似简单的一个答案，却是很多OEM所最头疼的。因为软件的种类那么多，业务领域也很多，究竟该如何搞呢？无论如何，我们还是要首先思考清楚自己最想把哪个部分的软件能力建起来，千万不要企图一口吃成个胖子。要有一个切实可行的目标和方法。下面是几个可以考虑的方向。

1. 从组织形式来说：

独立的软件开发部门。这个独立的软件部门作为软件开发的主体，承接整个公司级的软件开发任务。这样做的好处是资源可以共享，相当于一个资源池。因为在上层的需求输入比较清晰准确的情况下，软件开发的主要工作就是代码的编写、调试。这时，软件人员不需要对业务有很深的理解，只要按照需求来编码就行了。

这就像现在流行的软件外包，一个软件团队今天可能是在做一个服务器的软件，过几天可能就去开发一个手机的APP了。这是一个效率很高的模式。只是这个模式能够可行的基本条件是上游能够给出准确的设计需求。这是为什么我一直在推广MBSE的原因，如果OEM的架构和系统工程师队伍不够强大，不能给出标准化的输出，那么这个模式就会出现问题。

按照业务领域来建多个软件团队，并将软件团队作为业务领域的一部分。现在的OEM大多将部门划分为车身、动力、底盘、新能源、信息娱乐、智驾等。这么划分在目前来看并没有问题，也是很高效的，可是即将到来的域控制器时代，这么做的问题就很多了。如果一个域控制器集成了车身、动力和底盘的很多控制功能，那么这个控制器的软件哪个部门负责呢？

大家都是平等的业务部门，凭什么我就要听你的？解决这个问题的方式只能是高层介入，将大家适当融合，由其中的一个部门负责整个控制器的总体集成和测试，每个部门各自负责其中的一部分涉及到自己业务领域的软件的开发。这样做的好处是各个专业的软件人员与自己的系统工程师沟通会比较好，软件工程师也会比较熟悉业务需求。

弊端是：每个业务部门的软件开发能力难以保证一致，负责整体的集成工作的部门必然是要投入更多的资源，并承担更多的压力；另外，不是每个部门都会有持续的开发任务，所以必然造成某个时间段中一部分人忙的要死，而另一部分的人却无事可做。但是这个模式却是OEM建立软件队伍时最容易做的方法，因为暂时不需要对组织形式做大的改动。

2. 从业务领域来讲：

涉及到软件的部门至少有车身、动力、底盘、新能源、信息娱乐、智驾等，一刀切全部自己搞显然是不现实的。那么究竟从哪个领域搞起？这个大家只能看自己的积累了，在新能源领域，现在很多OEM都已经自己在搞VCU和BMS了，而其他领域自己做软件的却不是很多。还是以前一直在强调的一句话：软件本身并没有价值，只有承载了业务的软件才有价值。而想自己做软件的前提一定是自己在某些领域已经有了相当的积累。如果连很多领域内系统层级的详细设计都没有，那么就只能是一边补课一边编码了。

3. 从软件的层级来讲：

任何一个ECU或者域控制器的软件基本上都可以分为底层的操作系统OS，中间件，应用层软件。越往下需要投入的资源也越多，距离OEM们现有的能力与经验也越远。所以，这里的建议还是从上层的应用层软件开始。中间件与OS现在至少都是可以花钱买来的，至少从短期来说，买来的成本绝对比自己做划算。如果真的财大气粗，也可以啥都自己做，不过要想在时间周期、质量等都想要与成熟的商业产品相比有竞争力还是相当难的。

在搞定了软件开发队伍之后，还没有万事大吉。因为软件只是整车开发中的一个环节而已，而且是比较靠后的环节。决定软件应该如何写的不是程序员，而是软件上层的各个层级的设计。让我们再回顾一下《谈谈“正向开发”》中的一个图。

如果不考虑云端的软件，车上的软件只是在零件的实现中才会出现的，不论是域控制器还是传统的ECU，零件仍然是软件的载体，而零件及其所包含的软件所存在的目的还是为了实现整车的功能与性能。功能开发将是所有OEM所必须具备的能力。靠对标来进行自己的所谓创新，将不会有美好的未来。

借用一个朋友的话：从来没有见过有人靠抄作业得第一名。A货没有办法超越原版的。外观可以抄，名字可以抄，但是软件的逻辑却是永远无法抄来的！（请原谅我的情绪激动）分享一个切身的感受：我发的文章中绝大多数原创都大受欢迎，而那些转载过来的文章没有一个有高阅读量。有原创性的功能设计、开发与验证将是各个OEM必备的基本能力。而要想持续性的有原创性的东西输出，一个稳定的、专职的功能开发部门就是必不可少的。专业的事情要让专业的人去做，如果还是靠领导的灵光一闪或偶尔的头脑风暴才能输出一些新的Idea，那么这样的企业注定是不会有持续的竞争力的。

上面的V流程图就是一个构建组织架构的参考。从专职的功能开发部门、架构部门、系统开发团队、再到零部件的软硬件开发，OEM在想通自己将来靠啥生存之后，可以决定每个部门的体量，而无论如何，这些基本的职能都是不可或缺的。

这里要强调一个看似废话但是却被很多人所忽略的事实：OTA中更新的的确是软件，但是用户关注的永远都是功能和性能。只有拥有强大的功能开发能力，OTA才有内容有意义。而只有强大的架构设计和系统开发团队才能让好的Idea变成现实。

搞软件是一个投入巨大的事情，一定要思考清楚了再大规模投入，而且这是一个对于传统的OEM的管理层都陌生的领域，最怕的就是低估软件的复杂度，尤其是数量级上认知的差异。

举个例子，大众为了搞MEB平台号称招了8000名软件人员。咱们没有那么多钱，两三千总是需要的吧。按照目前的行情，三千名软件开发人员，一年的综合成本可能要达到30亿。这个成本绝不只是人员工资，还要包括各种综合管理成本（水电物业费，固定资产折旧等），使用的各种工具软件的License费用。如果再算上开发过程中所需要的各种设备费用、试验验证费用等，这个总成本还要增加。再看看咱们国内的大部分OEM，自主品牌的净利润超过30亿的也是凤毛麟角了，因此，如果没有钱还要企图自己掌控软件开发，本身就只能是一个理想了。

变革期的转型是一项充满了风险与未知数的任务。在没有全盘想清楚前，你的确可以什么都不做，但是当一切都明朗的时候，你做什么可能都已经来不及了。诺基亚的失败不是因为他做错了什么，而是因为他什么都没有做。柯达的失败不是因为他做错了什么，而是因为他什么都没有做。为什么？因为维持现状是最容易的选择，但也是最危险的选择。只有破釜沉舟的决心，壮士断腕的勇气，才能迎来凤凰涅槃的重生。

在变革的时期，没有人知道未来谁会活下来，但是如果只是被动的等待，做一个跟随者，就一定会成为一个失败者。变革来临的时候，一定会有人抓住机遇而崛起，就如同特斯拉、蔚来们一样；一定会有人因为没有熬到黎明而提前倒下了，就如那些现在已经被人遗忘的上百家新势力；也一定会有这个行业的既得利益者因为不忍心自己革自己的命而被别人吃掉。

特斯拉、蔚来们都是在同数百个同时期的竞争对手的对决中、在各大传统的主机厂不屑一顾下杀出了一条血路，冲出重围，才有了今天的成绩，而他们的明天是否依然还像今天这么好，亦或是像昨天那样面临生死危机，谁都不得而知。而有一件事情是几乎可以确定的：得软件者得天下。

未来的汽车世界，软件将是重要的引领因素，因为其他的车辆的基本的属性所涉及的技术，大家之间的差距越来越小，唯有软件相关的各种设计与能力是区别OEM实力的重要标志物。而软件绝不只是代码，没有上层的良好设计，多少行的代码都只能是垃圾。

软件相比于硬件最大的特点就是可以不断的迭代，而将来软件的迭代速度将是强者与弱者的重要差别。传统的汽车世界是大鱼吃小鱼，而软件的世界是快鱼吃慢鱼。如何构建一个可以快速迭代的软件开发体系，将是大家必须要解决的问题。而MBSE则是一个明确的被证明绝对有效的方法。

《史记.项羽本纪》：项羽乃悉引兵渡河，皆沉船，破釜甑，烧庐舍，持三日粮，以示士卒必死，无一还心。

在这个变革的时代，如果你还想再活500年，那么，赶快忘记昨日的辉煌。唯有破釜沉舟的决心与行动，才能让自己在未来的竞争中活下来。留给OEM们的时间窗口已经不多了。

---

作者:侯哥@Roy 专注汽车电子电气架构开发

编辑:文昌@Vincent 汽车信息安全从业者

---

—END—