玺锐科技应邀参加软件定义汽车高峰论坛，车企如何打造卓越软件能力
文章内容来源于 盖世直播 盖世汽车社区
由盖世汽车、AUTOSAR组织、上海车展三方联合主办的SDVF2021第二届软件定义汽车高峰论坛暨AUTOSAR2021中国日于4月19-21日在上海举办，本次活动也是2021上海车展的同期活动之一，同时也是AUTOSAR组织在中国区唯一官方活动。本次会议邀请到了麦肯锡咨询公司副董事合伙人陈晴先生在本次论坛进行了题为《软件定义汽车时代，车企如何打造卓越软件开发能力》的主题演讲，以下是他在本次演讲的主要内容：
车企在打造软件的道路上入了很多坑，也努力地从坑里爬出来，所以有些经验，今天也想跟大家分享一下。
刚才大家提到软件驱动背后有很多大的行业趋势基础，2014、15年新四化开始爆棚，我们可以看到新四化背后的自动驾驶、车联网，这些无疑是软件作为底层逻辑支撑的，甚至是电动化。虽然电池更偏向硬件，但我们可以看到电池的管理、热管理、创新想法（例如，以后把电动汽车变成开内燃机一样的感觉），很多这样的场景模拟也是软件支持的。
在这样的基础上行业痛点明显，我们可以看到这个红线，红线是我们模拟未来整个行业发展，从软件角度，汽车软件复杂度会增长到什么程度。我们可以看到现在处于2021年，整个曲线斜率是上翘的，所以未来几年汽车软件复杂度要有井喷的过程，在2030年左右，整个软件的迭代、创新会稍微缓慢一点，那个时候还在增长，但增长率会比较平缓一些。
在这个基础上我们也看到不同企业状态完全不在同样的水平，这个图是我们基于15000个软件开发项目端到端的数据分析，很多项目是麦肯锡在背后跟他们一同工作的。我们按所有项目的最后结果，把企业分成不同的类型，最差的25%，最好的25%。大家可以看到第一个是说单个全职软件工程师，在比较差的企业和比较好的企业，他的效率、单元产出差了三倍。中间部分从整个企业来看，当然包括全职工程师自己的效率，也包括利用供应商的规划和管理能力，这个差距会更大（3.5倍）。
在这样的状态下必须要做转型，怎么才能做企业？怎么全面的打通？怎么贴近汽车软件开发的需求？我们会次几个大维度看，但可以归结为两个大的层面，一个是软件复杂度一定是增高，但在增高的过程中怎么管理复杂度，不是越复杂越好，有些复杂性是不需要的。另外是在复杂度既定情况下开发效率怎么提高，我们可以看到左上角更多是怎么管理复杂度。这里有几个点，首先是整个架构，刚才周总提到现在很多趋势不像以前有一个软件功能需求就开始开发，其实有架构的概念，但架构本身怎么管理？
真正到切实开发怎么提升效率，这里有几个大的模块。你要做那么多事情，但没有一个人能够把所有事情搞定，在这个里面哪些自己做，哪些给供应商和合作伙伴做？我们测算了一下，仅仅是新四化板块，如果一个企业要自己做下来，而且每个模块做到行业靠谱程度，它需要花3000亿美金。哪怕我知道要做什么，我要定位好自己做什么和合作伙伴做什么，在这个基础上看现在软硬件组织架构能否承接我们要的事情，包括人才在哪里。
另外大家提到了没有任何一家主机厂能自己做所有的事情，这个时候涉及到哪些向外合作，这个又比较复杂。因为以前主机厂的想法很简单，我要么把系统外包，但每做这样的决策至少需要从三个维度考虑：
一，跟供应商合作模式与之前不一样。包括我从前端的需求输入过程中，从软件的角度切法非常灵活，它不一定整个外包出去，它可以在某个维度外包出去。
二，从技术上到底切到哪里包出去。包括赋能的绩效管理、后台、赋能工具等等。
三，包括车上各个域及其它辅助功能，我到底哪个域要进行外包。我们以OS为例，这个外包？还是自研？这个没有回答清楚你要做什么，因为你要知道OS是哪个域进行合作，还是外包时整个全部出去，又或者定义阶段深入介入。这些问题作为主机厂，甚至生态合作伙伴明确要识别出来控制点在哪里，我自己到底要怎么抓住自己想做的事情。这里有很多笑话，因为涉及到采购体系的重新整理。
刚才提到就算自己内部要做的时候，软件都想往敏捷迭代的方向走。但这里汽车的软件跟其它行业还不一样，因为它的敏捷迭代有很多特殊挑战。你毕竟是软硬件不能完全割离，其次汽车会涉及到安全，法律法规对你的敏捷迭代还有很多的限制。最后是说迭代不仅仅是内部自己的敏捷迭代，它跟供应商原来的合作模式怎么调整和处理。这里有几个我们可以思考的点：
一，既然你有硬件，它的开发周期和模式跟软件没有办法敏捷同步迭代，这个时候你就要看从各个层级哪些是完全软件的敏捷，哪些是硬件相关的，哪些是耦合的。比如我们从技术栈上面来分，你的各种应用它可以敏捷迭代。但应用里面也要包括涉及安全的，比如自动驾驶迭代会稍微有所不一样，比如涉及到中间的OS系统，理论上你可以相对敏捷迭代，但万一底层控制器有重大更新变革，它还是要跟上面进行耦合。主机厂刚开始没有完全理解，大家都在敏捷，但敏捷不是一股脑的敏捷，而是看清楚哪些地方可以敏捷，哪些地方还要做调整。
既然我们在汽车敏捷有这样的特点，它就要保证我在敏捷的同时有不敏捷的地方，这个你要非常清楚，在哪个时间点敏捷迭代出来的东西和用传统瀑布式开发出来的东西，能够在时间点上进行耦合。不然很多软件出来之后真的要上车，后面问题特别多。这里还有基础架构，包括产品本身的结构是不是可拓展的，跟供应商的合作关系是不是能够做的比较好，关键的是汽车里面有很多样车实验。如果你的软件迭代周期不一样，那这个样车能不能做的非常敏捷，保证硬件的测试、软件测试，同样能够在不同节奏上有样车进行提供。这里需要做的事情也非常多。
还有比较激进的，有些企业从头到尾的推进把它变了，甚至是原来定义需求、架构定义、开发，开发好以后再进行集成与验证。现在甚至前端的定义、架构定义、功能定义和后面的开发测试双迭代，这样要求会更加的高，它会涉及到整个流程。比如原来是里程碑式的，现在变成开发放行。包括我们跟供应商的合作模式，以前是在不同里程碑供应商基于数据支持交接，在这种模式下跟供应商都是知识库，主机厂有持续可获取的知识库获得模式。这个又从底层上会对合作和开发模式进行全盘的复盘。
最后一个维度是到底如何管控开发是否真的做的比较好，这个也有很多经验。大家说要百米冲刺迭代速度，但有些时候做出来效果不是很好，这种情况出现是后端整个敏捷开发、系统支持，包括刚开始所有做的事情是否比较合适，目标设定是否合理。包括所有不同开发团队、功能开发团队和功能底层赋能软件开发团队到底在做什么、做到什么阶段、进步怎么样等等。这个是作为中央管控非常清楚，所以敏捷开发过程中，从需求输入到最后的产出，保证大家到最后都是完美的数据，而不是一团糟。
当然最佳的状态是对难度的管理及效率提升，每个环节都可以做的非常好。现在没有一家企业能够遍地开花，你必须要走一些路，做一些举措，切入点到底在哪里？这里不是全景，所以你能想到的，每个企业不一样，它可以有很多战略选择。有些点是整个思路不清晰的情况下开始切入，在做之前先把要做的事情描绘出来，这可能是某些企业需要做的。还有一些企业是自己想清楚做什么，也知道要做什么，这更多的是效率提升，这里涉及到管理工具引入、流程规范化，还有其它很多不同的战略切入模式，这里不一一赘述。
我们的观点是以前对软件定义汽车还有很多争议，但现在争议没有了，看的越来越清楚，但迈出这一步很难，前面的坑很多。现在的软件定义汽车连上半场都没有结束，而且所有的这些问题本身都没有到成熟稳定或者最佳的状态，就算已经想好的企业，它经常要回顾看看走的对不对，这里有很多探讨的机会点。虽然前面非常痛苦，但我们觉得机会非常大，也有让人激动的前景，希望在座业界朋友在软件道路上前程似锦。
