谈谈“OEM的软件管理”...

文/侯哥

1

现在汽车行业的软件比重越来越大，大众汽车都已经自己开始招人搞软件开发了，据说是他们估计将来软件的成本将占到整车BOM成本的40%以上。虽然目前还没有那么多，但是德国人向来是做事很谨慎的，这么高调的宣布一个让所有人都感到惊讶的决定，一定是深思熟虑的结果。

我的领英（LinkedIn）上每天都能看到大众软件部门招人的广告，也在谈SDV（软件定义汽车，感兴趣的同志可以看看我前面的文章），而且，据我所知，在几年前国内的好几个主机厂都已经开始招人做一部分软件工作了。

先不谈主机厂自己的软件开发工作了，毕竟这个还是刚刚的起步阶段，OEM自己开发的软件代码量占整车的总体的软件代码量还很少。最多5%~10%（这个没有办法详细统计，先大致估计一下吧，肯定不会超过这个数字的）。其他的90%以上的软件还是靠供应商来开发的。既然这样，对于这么庞大的软件主机厂是如何管理的呢？

每一家做的方法还是差别很大的。总的来说，掌握Knowhow越多的主机厂对软件的管理也越细致、越深入。那些积累不多的主机厂更多的还是给供应商一个大体的功能要求，然后要求供应商按照各个装车节点来交样，把软件当成是控制器的一部分而已。在SOP后，更多的是控制如何让每次的软件更新不出错而已。基本上还是属于被动防范。

虽然大家现在都在说软件管理这个概念，但是作为主机厂该如何管理软件这个花钱多、问题也多的“零部件”却是一个大问题。

下面我们就聊一下作为主机厂该如何管理好供应商负责开发的软件。对于主机厂自己开发的软件，我们先不去谈了，我们就把他们当成是主机厂的内部供应商来看。

2

我们先看看供应商的软件是怎么最终装到车上的。基本如下图所示（我们只考虑正常的情况，中间的变更就暂时先不谈了）。

从供应商交流开始，主机厂考察供应商的一个重要维度就是软件开发能力。对于其他的能力，如：生产加工、物流、质量管控、硬件设计等，基本都可以通过现场考察或者看各种证书来判断，基本不会偏差特别大，但是对于软件能力，却很难去真正评判，大部分人的做法还是去看这个供应商以前的做的项目，甚至是只能凭自己的感觉，去听供应商如何吹牛了。这个显然是不靠谱的，主机厂如果没有一整套的评估工具和方法，是很容易被忽悠的。后果很可能是等到上了车，被各种市场问题扑面而来的时候才恍然大悟，但是已经为时已晚了。

等到定点的时候，所有的供应商都会报出各种数量的软件开发费用，虽然主机厂不会直接接受，但是，羊毛基本上还是要出在羊身上，零部件供应商最终总还是要想方设法的把这笔费用让主机厂买单的。这个软件开发的相关费用怎么评估的确是一个技术活。

这种看不见摸不到的东西的价值很难像硬件和部件的成本一样能够基本准确的估计出来，只能是通过商务手段尽量的压了。其实，软件的成本也还是可以大致估计一下的，只是不一定那么准，其中的一个原因是：同样的软件功能，不同的供应商开发的成本也不一样。

这个跟软件开发流程，能力和积累关系密切。总的来说，除了软件相关的开发工具和模块的购置成本之外，软件最大的成本就是人力成本：码农们的工资、管理成本、测试成本等。现在最值钱的是人，尤其是有经验的软件开发人员，他们的工资还是很高的。

对于交样和测试，无论重复多少次，基本过程都是差不多的：

1、主机厂提出功能目标

2、供应商开发软件后提交

3、主机厂进行集成和系统测试，以及整车级别的测试

4、反馈各种问题给供应商

5、供应商整改后重新提交

6、主机厂再次测试

…… 

---

3

在SOP之前，主机厂确认一个可以SOP的版本后，进入SOP的阶段，企图从此天下太平。然而，这样的好事情太少了，SOP后的软件更新已经是常态了，这个也是为啥很多主机厂急着推出OTA功能的原因之一。是主机厂和供应商的能力弱吗？好像也不一定，以前的汽车软件就很少需要在SOP后更新。主要原因是时代不一样了，软件越来越多，越来越复杂了。而且每个车型的开发周期都在变短。

在这样的新形势下，软件质量管理就是一个大问题了，而且是必须解决的问题和必须建设的核心能力。 

很多人都在谈软件管理，其实软件就是代码和二进制文件，是没有办法真的管理的，我们所能管理的只有软件的质量和软件所承载的功能。而为了管理软件的质量，我们要明白对于几百万甚至千万NBNC（软件术语：非空非注释，也就是有效代码行）行数的软件是极其难的事情。主机厂只能通过管理供应商的软件的开发流程来管理软件开发，同时通过建立自己强大的测试团队来尽量减少软件bug流出的数量。

测试的作用是显而易见的，而且有很多的专门的测试服务商，主机厂在这个方面的投入是很容易获得回报的。但是，就像我们不能只靠医生来保证我们身体健康一样，对软件开发过程的控制其实是更重要的。

对于软件开发过程的控制其实才是最难的。因为主机厂的人很少有自己开发过大规模软件的。我们可以使用CMMI和ASPICE的标准来规范供应商的软件开发流程，以此来减少后期带来的问题。

Automotive SPICE®是由欧洲的主要汽车制造商共同策定的“面向汽车行业的流程评估模型”，主要从“流程维”和“能力维”进行评估。CMMI也是一种改进过程的方法，目的是协助提升组织的绩效， SPICE的标准比CMMI模型更加开放。