由盖世汽车、AUTOSAR组织、上海车展三方联合主办的SDVF2021第二届软件定义汽车高峰论坛暨AUTOSAR2021中国日于4月19-21日在上海举办，本次活动也是2021上海车展的同期活动之一，同时也是AUTOSAR组织在中国区唯一官方活动。本次会议邀请到了麦肯锡咨询公司副董事合伙人陈晴先生在本次论坛进行了题为《软件定义汽车时代，车企如何打造卓越软件开发能力》的主题演讲，以下是他在本次演讲的主要内容：
车企在打造软件的道路上入了很多坑，也努力地从坑里爬出来，所以有些经验，今天也想跟大家分享一下。
刚才大家提到软件驱动背后有很多大的行业趋势基础，2014、15年新四化开始爆棚，我们可以看到新四化背后的自动驾驶、车联网，这些无疑是软件作为底层逻辑支撑的，甚至是电动化。虽然电池更偏向硬件，但我们可以看到电池的管理、热管理、创新想法（例如，以后把电动汽车变成开内燃机一样的感觉），很多这样的场景模拟也是软件支持的。
在这样的基础上行业痛点明显，我们可以看到这个红线，红线是我们模拟未来整个行业发展，从软件角度，汽车软件复杂度会增长到什么程度。我们可以看到现在处于2021年，整个曲线斜率是上翘的，所以未来几年汽车软件复杂度要有井喷的过程，在2030年左右，整个软件的迭代、创新会稍微缓慢一点，那个时候还在增长，但增长率会比较平缓一些。
我们可以看到从今天到2030年，整个软件复杂度可能还要翻四倍。在这个情况下我们看一看车企软件开发效率，这根线是比较平的，处于相对停滞的状态。这里还要强调一个点是软件会分为不同类型，车企在开发软件时，特别是涉及到域级别和系统级别的软件，它的开发效率比深度嵌入等相对传统软件的开发效率还要低25-35%。在这个情况下软件需求和自己团队的能力，这个空间怎么弥补起来？
在这个基础上我们也看到不同企业状态完全不在同样的水平，这个图是我们基于15000个软件开发项目端到端的数据分析，很多项目是麦肯锡在背后跟他们一同工作的。我们按所有项目的最后结果，把企业分成不同的类型，最差的25%，最好的25%。大家可以看到第一个是说单个全职软件工程师，在比较差的企业和比较好的企业，他的效率、单元产出差了三倍。中间部分从整个企业来看，当然包括全职工程师自己的效率，也包括利用供应商的规划和管理能力，这个差距会更大（3.5倍）。
除了从产出量和效率的差距，我们也可以看到差距还有质量方面。比如最好的企业和最差的企业在第一波出来软件缺陷有多少的角度，基本上差了6-7倍。我们觉得整个汽车行业现在在软件需求那么大的情况下，在大家都在挣扎的过程中，特别是我们还处于绩效表现偏低的企业，他的压力会更加的大。
在这样的状态下必须要做转型，怎么才能做企业？怎么全面的打通？怎么贴近汽车软件开发的需求？我们会次几个大维度看，但可以归结为两个大的层面，一个是软件复杂度一定是增高，但在增高的过程中怎么管理复杂度，不是越复杂越好，有些复杂性是不需要的。另外是在复杂度既定情况下开发效率怎么提高，我们可以看到左上角更多是怎么管理复杂度。这里有几个点，首先是整个架构，刚才周总提到现在很多趋势不像以前有一个软件功能需求就开始开发，其实有架构的概念，但架构本身怎么管理？
我们在需求端有很多车企，包括供应商，开发的时候并不清楚这个东西客户到底要不要？结果从大数据分析上看到客户没有用这些功能，那这些就是浪费的投入资源。哪怕是识别出来客户需要的软件功能，它怎么在软件需求到架构分析、开发验证等等整个逻辑链打通？这是我们说从复杂度管理的角度进行这些事情。
真正到切实开发怎么提升效率，这里有几个大的模块。你要做那么多事情，但没有一个人能够把所有事情搞定，在这个里面哪些自己做，哪些给供应商和合作伙伴做？我们测算了一下，仅仅是新四化板块，如果一个企业要自己做下来，而且每个模块做到行业靠谱程度，它需要花3000亿美金。哪怕我知道要做什么，我要定位好自己做什么和合作伙伴做什么，在这个基础上看现在软硬件组织架构能否承接我们要的事情，包括人才在哪里。
其次有这样的架构设计好之后具体开发，具体开发涉及到软硬件解耦开发、双速开发、敏捷开发。敏捷开发跟IT界不一样，汽车有自己的特点，硬件有自己的规律，软硬件要整合。规模化敏捷，边界在哪里？边界内的敏捷开发怎么管控？在具体运作过程中还有很多自动化的系统帮助，包括自动测试、集成逻辑思路，最后赋能这些包括绩效透明度、数字化工具，把整个过程打通。
今天时间有限，我会针对某些点跟大家分享一下。首先是我们在管理汽车复杂度的维度，刚才讲到很多大家能够想到的，我的软件分层和平台化管理。这个概念已经不是很新了，包括应用层专注在软件开发，其实底层硬件应该跟它脱离，没有太多的瓜葛。人工智能、高级分析更多的是所有特定硬件调用逻辑关系非常清楚，这个基础是你有强大的中间层，包括中间层对硬件的抽象管控，也包括操作系统能在不同域之间的有效沟通。这个逻辑非常清楚，但我至少个人跟所有主机厂合作下来的感觉是大家想往那个方向走，但在真正的研发过程中，绝大多数企业还是被硬件牵扯鼻子走，每台车型出来要这个那个软件需求，下面底层控制器、硬件全部都是非常多元化，这就导致所有要做平台化规划和设计的过程节奏、预算完全没有办法落地。这个逻辑很清楚，但在实操过程中非常困难。
另外是我们有需求想法，就算用户需求抓得准，做的事情确实是我们应该做的事情。这个时候我经常听到车企市场端和研发端之间的PK过程，研发端说你提的我做不了，反过来市场端提需求，最后说你做出来之后这个东西是什么，完全不是我原来提的东西，为什么会出现这种状态？他要有一个非常完整的体系支撑所有要落地的期望，最初是我的需求如何真的进来，它需要一个工具链保证这些需求怎么转化为系统的架构要求，再落实到组件需求，组件需求又要跟工作量管理工具，怎么把这些需求真正转化为现在敏捷开发中迭代冲刺规划、工作量管理等等，这些有了之后还要把工作量与编码工具联系，跟后面的验证系统打通。如果这些能够打通，这个时候就算之前说的研发跟前端说做不了，那这个就是理直气壮的做不了，毕竟它有迭代和自己规划的过程。那也不会出现前端输入进来，最后做出来的软件等到消费者验证时完全不是我初步的想法，那这个系统都可以完全的保证，这样所有的无用功都能避免掉。
另外大家提到了没有任何一家主机厂能自己做所有的事情，这个时候涉及到哪些向外合作，这个又比较复杂。因为以前主机厂的想法很简单，我要么把系统外包，但每做这样的决策至少需要从三个维度考虑：
一，跟供应商合作模式与之前不一样。包括我从前端的需求输入过程中，从软件的角度切法非常灵活，它不一定整个外包出去，它可以在某个维度外包出去。
二，从技术上到底切到哪里包出去。包括赋能的绩效管理、后台、赋能工具等等，
三，包括车上各个域及其它辅助功能，我到底哪个域要进行外包。我们以OS为例，这个外包？还是自研？这个没有回答清楚你要做什么，因为你要知道OS是哪个域进行合作，还是外包时整个全部出去，又或者定义阶段深入介入。这些问题作为主机厂，甚至生态合作伙伴明确要识别出来控制点在哪里，我自己到底要怎么抓住自己想做的事情。这里有很多笑话，因为涉及到采购体系的重新整理。
举个例子，比如一家主机厂采购体系，每次软件团队去提要求，他第一句永远是问：你这个软件跟哪个硬件捆绑，所有的申请必须跟我的硬件一起。如果你从这个维度看，有些时候你的采购根本不涉及到任何的硬件，它就推动不了。还有更有意思的，那个主机厂是一个供应商和研发团队沟通，它有一个小硬件可前装，硬件后面有很多增值服务和客户数据共享。这个供应商说我的商业模式，甚至硬件不要钱，你装一个我倒贴给你钱。这个研发同事很开心，然后就上报采购，最后采购出来的决策是买了同样的硬件，结果是另外一家供应商，那家供应商要了他们2000元。最后研发人非常生气，拍着桌子跟采购说你为什么要人家那个？结果后来发现它的采购系统当中不能输入任何负值，因为它采购的标的是卖给主机厂一个设备，主机厂拿到1500元，结果导致申报资料被采购系统从开始就默认为错误填写，采购根本没有看到这个应标书。我们真的要打通这种模式，采购体系对供应商来说整个逻辑和结构都要重新梳理。这种例子很多，有些事情战略上真的到落地会发现有很多细枝末节需要处理好。
刚才提到就算自己内部要做的时候，软件都想往敏捷迭代的方向走。但这里汽车的软件跟其它行业还不一样，因为它的敏捷迭代有很多特殊挑战。你毕竟是软硬件不能完全割离，其次汽车会涉及到安全，法律法规对你的敏捷迭代还有很多的限制。最后是说迭代不仅仅是内部自己的敏捷迭代，它跟供应商原来的合作模式怎么调整和处理。这里有几个我们可以思考的点：
一，既然你有硬件，它的开发周期和模式跟软件没有办法敏捷同步迭代，这个时候你就要看从各个层级哪些是完全软件的敏捷，哪些是硬件相关的，哪些是耦合的。比如我们从技术栈上面来分，你的各种应用它可以敏捷迭代。但应用里面也要包括涉及安全的，比如自动驾驶迭代会稍微有所不一样，比如涉及到中间的OS系统，理论上你可以相对敏捷迭代，但万一底层控制器有重大更新变革，它还是要跟上面进行耦合。主机厂刚开始没有完全理解，大家都在敏捷，但敏捷不是一股脑的敏捷，而是看清楚哪些地方可以敏捷，哪些地方还要做调整。
既然我们在汽车敏捷有这样的特点，它就要保证我在敏捷的同时有不敏捷的地方，这个你要非常清楚，在哪个时间点敏捷迭代出来的东西和用传统瀑布式开发出来的东西，能够在时间点上进行耦合。不然很多软件出来之后真的要上车，后面问题特别多。这里还有基础架构，包括产品本身的结构是不是可拓展的，跟供应商的合作关系是不是能够做的比较好，关键的是汽车里面有很多样车实验。如果你的软件迭代周期不一样，那这个样车能不能做的非常敏捷，保证硬件的测试、软件测试，同样能够在不同节奏上有样车进行提供。这里需要做的事情也非常多。
还有比较激进的，有些企业从头到尾的推进把它变了，甚至是原来定义需求、架构定义、开发，开发好以后再进行集成与验证。现在甚至前端的定义、架构定义、功能定义和后面的开发测试双迭代，这样要求会更加的高，它会涉及到整个流程。比如原来是里程碑式的，现在变成开发放行。包括我们跟供应商的合作模式，以前是在不同里程碑供应商基于数据支持交接，在这种模式下跟供应商都是知识库，主机厂有持续可获取的知识库获得模式。这个又从底层上会对合作和开发模式进行全盘的复盘。
最后一个维度是到底如何管控开发是否真的做的比较好，这个也有很多经验。大家说要百米冲刺迭代速度，但有些时候做出来效果不是很好，这种情况出现是后端整个敏捷开发、系统支持，包括刚开始所有做的事情是否比较合适，目标设定是否合理。包括所有不同开发团队、功能开发团队和功能底层赋能软件开发团队到底在做什么、做到什么阶段、进步怎么样等等。这个是作为中央管控非常清楚，所以敏捷开发过程中，从需求输入到最后的产出，保证大家到最后都是完美的数据，而不是一团糟。
敏捷还有很多底层的管理逻辑需求，当然管理逻辑的支撑在座供应商伙伴会比较了解，它有一些数字化的工具赋能。在主机厂现在还有很多小伙伴在用Excel，这个效率低下，甚至很多复杂系统很难用人工管理模式把不同内容协调好。我们也会在项目当中导入很多管理工具，确实发现从开发时间缩短或者故障排除率上都有很大的提升。这个需要主机上跟供应商有很好的配合，因为你不可能一下都导入，这个时候最大的痛点是什么？内部能力能够承接住什么样的设备、基础，这个需要多方协同合作。
当然最佳的状态是对难度的管理及效率提升，每个环节都可以做的非常好。现在没有一家企业能够遍地开花，你必须要走一些路，做一些举措，切入点到底在哪里？这里不是全景，所以你能想到的，每个企业不一样，它可以有很多战略选择。有些点是整个思路不清晰的情况下开始切入，在做之前先把要做的事情描绘出来，这可能是某些企业需要做的。还有一些企业是自己想清楚做什么，也知道要做什么，这更多的是效率提升，这里涉及到管理工具引入、流程规范化，还有其它很多不同的战略切入模式，这里不一一赘述。
我们的观点是以前对软件定义汽车还有很多争议，但现在争议没有了，看的越来越清楚，但迈出这一步很难，前面的坑很多。现在的软件定义汽车连上半场都没有结束，而且所有的这些问题本身都没有到成熟稳定或者最佳的状态，就算已经想好的企业，它经常要回顾看看走的对不对，这里有很多探讨的机会点。虽然前面非常痛苦，但我们觉得机会非常大，也有让人激动的前景，希望在座业界朋友在软件道路上前程似锦。
麦肯锡陈晴先生在本次大会的更多精彩瞬间：
