“麦肯锡陈晴：软件定义汽车时代，车企怎么打造卓越软件开发能力”

由格斯坦汽车、汽车公司、上海车展三方共同主办的sdvf2021第二届软件定义汽车峰会论坛暨autosar2021中国将于4月19-21日在上海举行，此次活动也将是2021上海车展的同步活动 这次会议由麦肯锡咨询企业副董事合伙人陈晴先在本次论坛上诞生，“软件定义了汽车时代，汽车企业如何构建卓越的软件开发能力。 以下是他这次演讲的第一个拷贝。

因为车企在做软件的路上进了很多坑，努力摆脱坑，所以有些经验，今天也想分享给大家。

综上所述，软件驱动的背后有许多大的领域趋势基础，，15年新四化开始爆发。 可以看到新四化背后的自动驾驶、远程通讯技术。 这些无疑是以软件为基础逻辑支撑的，也是电动化的。 虽然电池靠近硬件，但可以看到电池管理、散热管理、创新的创意(例如，今后将电动汽车变成驾驶内燃机的感觉)，这样的场景模拟大多也受软件支持。

在这样的基础上领域的创伤很明显，可以看到这条红线。 红线是我们模拟了未来整个领域迅速发展，从软件的角度，汽车软件多，复杂度会增加到什么程度。 现在是2021年，可以看到曲线整体的倾斜度在上升。 因此，未来几年汽车软件多，复杂程度要井喷，整个软件的迭代、创新会在2030年左右缓慢一些。 那个时候还在成长，但是增长率会稍微缓和一些。

从今天开始到2030年，你会发现整个软件很多，复杂度可能会增加四倍。 在这种情况下，让我们来看看汽车企业的软件开发效率吧。 这条线比较平坦，处于比较停滞的状态。 这里我还想强调一点，软件分为不同类型。 汽车企业开发软件时，特别涉及域级和系统级软件，其开发效率比深度嵌入等以前流传下来的软件开发效率低25-35%。 在这种情况下，软件诉求和自己团队的能力如何在此空之间得到补充？

在此基础上，还发现不同公司的状态完全不是同一水平。 这张图是我们根据15000个软件开发项目的端到端数据观察到的，很多项目都是麦肯锡在背后和他们一起工作。 我们根据所有项目的最后结果，将公司分为不同类型、最坏的25%、最好的25%。 第一个是全职软件工程师，可以看到，比较差的公司和比较好的公司，他的效率、机组生产率都差了三倍。 中间部分从整个公司来看，当然包括全职工程师自身的效率，包括利用供应商的计划和管理能力，这一差距会更大。

可见不仅产量和效率的差别，差别也有质量的一面。 例如，最好的公司和最差的公司在第一波软件有多少缺陷的立场上，基本上有6-7倍的差距。 我们觉得整个汽车领域现在软件诉求那么大的情况下，在大家都在挣扎的情况下，特别是我们还在业绩不好的公司的话，他的压力会更大。

必须在这种状态下进行变革，怎样才能成立公司？ 你怎么全面了解？ 如何贴近汽车软件开发的诉求？ 我们从几个大的维度来看，可以总结为两个大的层面。 一个是软件多，复杂度一定会高，但是在变高的过程中怎么多，管理复杂度。 多，杂并不是好，多一点，不需要杂。 另外，可以知道在复杂度被设定的情况下开发效率如何提高，左上角增加是如何管理复杂度的。 这里有几点。 首先是整个体系结构。 前一周我说过，现在很多趋势并不像以前那样因为有软件功能的诉求而开始开发。 实际上有体系结构的概念，但是体系结构本身是如何管理的？

我们在诉求方有包括供应商在内的很多车企，但是在开发时不知道这是顾客需要的吗？ 结果从大数据观察来看顾客没有使用这些功能，这些都是无用的投入资源。 即使认识到了顾客需要的软件功能，但如何从软件诉求到体系结构分解、开发验证，贯穿了整个逻辑链呢？ 这是我们说要从多而复杂的管理角度来进行这些事件。

要实际开发并提高效率，这里有几个大模块。 你必须做那么多案子，但没有身体能解决所有案子。 其中那些是自己做的，那些是给供应商和合作伙伴做的吗？ 我们估算，光是新的四化板块，由一家公司自己制作，各模块要提高领域的可靠性，就需要3000亿美元。 即使知道要做什么，也要决定自己要做什么，伙伴要做什么，在此基础上看现在软硬件的组织结构包括人才在哪里，能否承担我们所追求的事件。

其次，这样的架构设计后有具体的开发。 具体开发包括软硬件解耦开发、双速度开发、敏捷开发。 敏捷开发不同于it行业，汽车有自己的优势，硬件有自己的规律，硬件和软件必须集成。 规模化敏捷，边界在哪里？ 边界内的敏捷开发是如何管制的？ 具体的操作流程包括自动测试、集成逻辑思路、最终性能透明度、数字化工具等许多自动化的系统辅助，并贯穿整个流程。

今天时间有限，我将比较几点分享给大家。 首先，我们管理着汽车的多样性和复杂性的维度。 我刚才提到了很多大家可以想到的，就是我的软件分层和平台化管理。 这个概念并不新鲜，包括APP应用层集中在软件开发上。 实际上，底层硬件应该脱离它，关系不大。 人工智能、高级分解日益增加的原因是，所有特定硬件调用的逻辑关系都非常清晰。 其基础是，中间层对硬件的抽象管理、操作系统在不同域之间的比较有效的信息表达等，具有强大的中间层。 这个逻辑非常明确，但我至少在个人和所有主机制造商合作的感觉上，大家都想往那个方向走。 但是，在真正的研发过程中，大部分公司都卷入到硬件中，各车型层出不穷地寻求软件诉求。 的底层控制器、硬件都非常多样，结果都是平台化规划和设计过程的节奏、预算根本无法落地。 这个逻辑很明确，但是在实际技能的过程中非常困难。

另外，我们有诉求。 即使客户的诉求正确，该做的事件也确实是我们应该做的事件。 这个时候，我经常问车企市场端和研发端之间的pk流程，研发端说你说的我做不到，相反市场端诉求，最后你做了之后，说这个东西是什么，完全不是我说的，为什么 他必须有一个非常完善的系统支持所有落地的期望。 一开始我的控诉是怎么真的进来的？ 这需要一个工具链，保证这些指控如何转换为系统的体系结构要求，并一直执行到组件的指控为止。 组件指控还需要将员工管理工具、这些指控实际转化为当前敏捷开发中的迭代冲刺计划、员工管理等。 完成这些后，就需要连接员工和编码工具，和后面的验证系统取得联系。 如果这些都说得通的话，这个时候在前面说的研究开发面前就做不到了，但是这也是没有道理的。 毕竟，那个有反复和自己计划的过程。 也不会输入到前端。 最后制作的软件在客户验证之前不是我的初步想法。 那个因为这个系统完全有保证，所以可以消除一切浪费。

另外，据说没有一家主机厂能自己处理所有事件，这个时候是和它们的对外合作有关的。 这又多又杂。 以前的主机厂的想法很简单，所以我每次外包系统或者做这样的决定都至少需要从三个维度来考虑。

一、与供应商的合作模式与以前不同。 包括我从前端的诉求输入在内，从软件角度的切割方法非常灵活，它不一定全外包，可以在某个维度上外包。

(/S2 ) ) 2、从技术上剪到什么程度进行出租？ 包括提供功能的性能管理、后台、功能提供工具等。

三、包括车上的各个域和其他辅助功能，但外包哪个域呢。 以操作系统为例，这个外包？ 还是自研？ 这没有明确回答你要做什么。 因为我们需要知道操作系统将在哪个域进行合作，还是在外包时整个出去，或者在定义阶段进行深入的干预。 这些问题决定了作为主机制造商，也作为生态伙伴，要确定控制点在哪里。 我怎么引出自己想做的事件呢？ 这里有很多笑话。 因为涉及到采购体系的重新整理。

例如，在一家主机厂的采购系统中，每当软件团队提出请求时，他的第一句话总是“这个软件被捆绑在哪个硬件上？ 所有的申请都必须和我的硬件在一起。 从这个维度来看，购买可能与硬件无关，也可能无法推进。 更有趣的是，其主机厂是供应商和研发团队的信息表达，可以预装小硬件，在硬件后面共享了很多增值服务和客户数据。 这个供应商说我的商业模式，甚至硬件不需要钱，你放我进去给你钱。 这位研发同事很高兴，然后向采购报告，最后采购的决定是买了同样的硬件，结果是另一家供应商，那个供应商向他们要了2000元。 最后研发人员很生气，拍着桌子对采购说，为什么要别人给它呢？ 结果表明，该采购系统不能输入负值。 因为，其采购的目标是销售给主机厂的设备，主机厂拿到了1500元。 结果，申报资料从一开始就错误地记入了购买系统，购买者完全没有看到这个应标。 我们真的必须通过这个模式，采购体系对供应商来说必须重新整理整个逻辑和结构。 这样的例子很多，可以看出，有些事件在战术上真正落地之前，有很多细小的枝叶需要解决。

刚才我说过，即使在我要做的时候，软件也想朝着敏捷迭代的方向发展。 但是，这里的汽车软件和其他领域不同。 因为敏捷迭代有很多特别的挑战。 你终究不能把硬件和软件完全分开。 其次汽车与安全有关。 法律法规对你敏捷的反复有很多限制。 最后，迭代不仅是内部的敏捷迭代，还有如何与供应商原有的合作模式进行协调和解决。 这里有几个值得思考的地方:

第一，既然有了硬件，其开发周期和模式就不能与软件敏捷地同步重复。 此时，我们必须从各个层面来看，它们是完全的软件敏捷，它们与硬件相关，它们结合在一起。 例如，我们从技术栈上分开，你的各种应用可以敏捷地重复它。 但是，APP中也必须包括与安全相关的东西。 例如，自动驾驶的重复有点不同。 例如，涉及中间的os系统。 理论上，可以比较敏捷地反复，但万一基础控制器发生了较大的更新变革，它还是必须与上面结合。 主机厂一开始并不完全了解。 大家都很敏捷。 但是，要清楚地看到，敏捷并不是每个脑袋都敏捷，而是那些地方都可以敏捷，所以这些地方必须进行调整。

我们既然在汽车敏捷方面有这样的优势，那就要保证我是敏捷的，而且有不敏捷的地方。 这你必须非常清楚。 什么时候敏捷重复的东西和从以前开始就瀑布式开发的东西，在那个时候能结合起来吗？ 否则，很多软件出来后真的要坐车了。 后面的问题特别多。 这里还有基础设施。 产品本身的结构是否可以扩展，与供应商的合作关系是否可以，重要的是汽车中有很多样品车的实验。 如果你的软件迭代周期不一样的话，这辆样品车能做得非常敏捷吗？ 硬件测试、软件测试也同样保证样品车可以以不同的节奏提供。 这里要做的事件也非常多。

另外，也有过激的东西。 一些公司会从头到尾改变它，推进原定义诉求、体系结构定义、开发，开发后进行整合和验证。 目前，前端的定义、体系结构的定义、功能的定义和后续的开发测试重复进行，因此要求更高，涉及整个流程。 例如是里程碑式的，但现在被取消了开发。 包括与供应商的合作模式在内，以前由不同的里程碑供应商基于数据支持进行交接。 该模型是供应商和知识库，主机制造商有可持续获取的知识库获取模型。 这又将从底层全面再现合作与开发模式。

最后一个维度是，该如何管制开发是否真的进行了？ 这也有很多经验。 大家都说要求百米冲刺反复速度，但有时并不顺利。 发生这种情况的原因是整个后端的敏捷开发、系统支持，包括最初做的所有活动是否合适、目标设置是否合理。 包括所有不同的开发团队、功能开发团队和功能基础软件开发团队到底在做什么、做到了什么阶段、取得了怎样的进步等等。 它作为中央统制非常清晰，所以在敏捷开发的过程中，从诉求输入到最后的生产，保证大家到最后都是完美的数据。 不是一团糟。

敏捷有很多基本的管理逻辑诉求。 当然，这里的供应商合作伙伴很清楚管理逻辑的支持。 它具有数字化的工具功能。 虽然主机厂至今仍有很多伙伴在使用excel，但这种方法效率低下，即使是许多复杂的系统，也不容易在人工管理模式下顺利调整不同的副本。 我们也在项目中引入了很多管理工具，发现开发时间缩短和故障排除率大幅提高。 这需要在主机上与供应商很好地合作。 因为不能马上引进，所以这个时候最大的痛处是什么？ 内部能力能接受什么样的设备、基础，这需要很多合作。

当然最好的状态是难度的管理和效率的提高，每个环节能做的非常好。 现在，没有哪家公司能开花。 你得走一点路，做一点措施。 切口在哪里？ 因为这里不是全景，所以可以想象，因公司而异。 有很多战术选择。 有几个要点是，在整体想法不明确的情况下切入，在做之前画出应该做的事件。 这也许是一些公司应该做的。 另一家公司知道自己想做什么和做什么。 这越来越有效率了。 这里涉及管理工具的部署、流程标准化和许多其他不同的战术切入模式，在此不赘述。

在我们看来，以前对软件定义的汽车有很多争论，现在已经没有争论了，越来越清楚了，但迈出这一步不容易，前面的漏洞很多。 目前的软件定义汽车上半场还没有结束，所有这些问题本身还没有成熟稳定或达到最佳状态。 即使是已经想好的公司，也要经常回顾看它是否正确。 这里有很多探讨的机会。 虽然前面很痛苦，但是我们觉得机会非常大，有令人兴奋的前途。 希望在座的业内朋友在软件方面有前途。

麦肯锡陈晴在这次大会上度过了越来越美好的瞬间: