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

OEM该如何打造面向软件的队伍？ 在上次的文章《谈谈SDV时代OEM的组织机构设计》发出之后，有一些朋友问我具体应该如何去做？ 说句心里话，每个OEM都是一个巨型的组织，是一个无比复杂的系统，随便哪个OEM都是上万人，研究机构也都有几千人以上的规模，又有着不同的所有制的背景和不同的股权结构，大家的市场策略、技术积累、人员结构和对未来的预期都是不同的，想找出一个普遍适用的方式根本就是一项不可能完成的任务。 不过，既然SDV是一个新的时代，那么这个新的时代一定有一些特有的东西是以前的时代所不具备的。下面，我们就从这些特有的东西来入手，看看在这个新的时代中，我们在组织机构的设计上可能会有什么变化或者特点？ SDV的核心是软件，这是所有人普遍的共识。不管欧美的同行们是否也热衷于谈论软件定义汽车，但是大家对软件的重视已经是毋庸置疑的了。那些已经在软件行业有了相当实力的“局外人”——如苹果、百度、华为和阿里们都已经开始参与到这个游戏中来。虽然，大家的套路各不相同，但是躬身入局已经是不争的事实。为啥？因为既然汽车即将由软件所定义，那么这些软件大佬不可能置身事外，眼看这么大的一个蛋糕被别人所瓜分。 既然软件成为了汽车行业下一个时代的核心，那么，提升软件能力也就是一个必须要做的事情。如何提升软件能力？ 首先要有软件的开发队伍，否则提升什么呢？这看似简单的一个答案，却是很多OEM所最头疼的。因为软件的种类那么多，业务领域也很多，究竟该如何搞呢？无论如何，我们还是要首先思考清楚自己最想把哪个部分的软件能力建起来，千万不要企图一口吃成个胖子。要有一个切实可行的目标和方法。下面是几个可以考虑的方向。 1. 从组织形式来说： 独立的软件开发部门。这个独立的软件部门作为软件开发的主体，承接整个公司级的软件开发任务。这样做的好处是资源可以共享，相当于一个资源池。因为在上层的需求输入比较清晰准确的情况下，软件开发的主要工作就是代码的编写、调试。这时，软件人员不需要对业务有很深的理解，只要按照需求来编码就行了。 这就像现在流行的软件外包，一个软件团队今天可能是在做一个服务器的软件，过几天可能就去开发一个手机的APP了。这是一个效率很高的模式。只是这个模式能够可行的基本条件是上游能够给出准确的设计需求。这是为什么我一直在推广MBSE的原因，如果OEM的架构和系统工程师队伍不够强大，不能给出标准化的输出，那么这个模式就会出现问题。 按照业务领域来建多个软件团队，并将软件团队作为业务领域的一部分。现在的OEM大多将部门划分为车身、动力、底盘、新能源、信息娱乐、智驾等。这么划分在目前来看并没有问题，也是很高效的，可是即将到来的域控制器时代，这么做的问题就很多了。如果一个域控制器集成了车身、动力和底盘的很多控制功能，那么这个控制器的软件哪个部门负责呢？ 大家都是平等的业务部门，凭什么我就要听你的？解决这个问题的方式只能是高层介入，将大家适当融合，由其中的一个部门负责整个控制器的总体集成和测试，每个部门各自负责其中的一部分涉及到自己业务领域的软件的开发。这样做的好处是各个专业的软件人员与自己的系统工程师沟通会比较好，软件工程师也会比较熟悉业务需求。 弊端是：每个业务部门的软件开发能力难以保证一致，负责整体的集成工作的部门必然是要投入更多的资源，并承担更多的压力；另外，不是每个部门都会有持续的开发任务，所以必然造成某个时间段中一部分人忙的要死，而另一部分的人却无事可做。但是这个模式却是OEM建立软件队伍时最容易做的方法，因为暂时不需要对组织形式做大的改动。 2. 从业务领域来讲： 涉及到软件的部门至少有车身、动力、底盘、新能源、信息娱乐、智驾等，一刀切全部自己搞显然是不现实的。那么究竟从哪个领域搞起？这个大家只能看自己的积累了，在新能源领域，现在很多OEM都已经自己在搞VCU和BMS了，而其他领域自己做软件的却不是很多。还是以前一直在强调的一句话：软件本身并没有价值，只有承载了业务的软件才有价值。而想自己做软件的前提一定是自己在某些领域已经有了相当的积累。如果连很多领域内系统层级的详细设计都没有，那么就只能是一边补课一边编码了。 3. 从软件的层级来讲： 任何一个ECU或者域控制器的软件基本上都可以分为底层的操作系统OS，中间件，应用层软件。越往下需要投入的资源也越多，距离OEM们现有的能力与经验也越远。所以，这里的建议还是从上层的应用层软件开始。中间件与OS现在至少都是可以花钱买来的，至少从短期来说，买来的成本绝对比自己做划算。如果真的财大气粗，也可以啥都自己做，不过要想在时间周期、质量等都想要与成熟的商业产品相比有竞争力还是相当难的。 在搞定了软件开发队伍之后，还没有万事大吉。因为软件只是整车开发中的一个环节而已，而且是比较靠后的环节。决定软件应该如何写的不是程序员，而是