代码为王的时代：车企如何掌握卓越软件开发能力

作者：Ondrej Burkacky、Johannes Deichmann、Stefan Frank、Dominik Hepp、André Rocha

软件正在迅速重塑汽车行业。近年来，业内的四股颠覆浪潮——自动驾驶化、网联化、电动化、共享化（ACES）——全都重度依赖先进的软件。这些领域未来还将迎来更多的颠覆发展。全行业的整车厂（OEM）、供应商和新企业无不希望自己能在这条由软件驱动的新价值链上把握住关键的控制点。

随着行业格局改变，缺少软件能力的车企将面临重大风险，包括量产（SOP）延期和预算超支。它们甚至可能落后于竞争对手和新入场者，倘若后两者能以快得多的速度将新颖得多的产品推向市场的话。更糟的是，软件问题可能导致大规模召回，或是让车企无力防范因黑客攻击而产生的客户安全风险。

我们的研究显示，软件能力强的企业和能力弱的企业之间的差距是显著的，能力最强的企业报告中公布的产量和质量，比能力垫底的企业高出三到六倍【1】。这一开发效率差距远大于不同能力的硬件生产商之间可产生的差距。很多车企已认识到强大的软件开发能力带来的各种优势，也正在采取大刀阔斧的措施改善业绩。一些车企计划在今后几年提升软件能力，并将招聘数以千计的软件工程师；另一些则将重新定义治理模式，建立合作关系，并在全球推广卓越软件开发中心。

然而，我们认为这些措施是不够的，因为只有当车企针对软件开发更新了基础运营模式的时候，真正的变革才会到来。根据我们的研究，在那些认为软件是主要颠覆因素的车企研发领导当中，仅有40%的人觉得自己已为必要的运营变革做好了准备【2】。虽然一些领军车企已在软件工程实践上取得长足进步，但大部分车企仍然远远落后于佼佼者。目前车企的问题集中在几个领域：敏捷实践、持续集成、自动化测试。

软件开发转型的风险如此之大，车企必须对一整套软件开发方法进行重新思考，包括基础运营模式等。本文分享了我们通过与车企、供应商，以及生态圈中其他合作伙伴密切合作，收获的关键理念和洞见。这些洞见还建立在两项基础上：一是针对技术专家开展的广泛访谈，二是利用麦肯锡SottCoster专有数据库进行的大规模对标。

若干趋势凸显了汽车软件与日俱增的重要性。第一个趋势与软件和电气/电子市场的迅速扩张有关，2020年到2030年，这个市场预计将实现12%的年复合增长率——比普通汽车销量的预期增速高出三倍多。有几个领域增长最为强劲，包括软件功能（年复合增长率达11%）以及集成测试（年复合增长率为12%）【3】。

复杂度不断升高，但开发效率进步缓慢

无论功能层面还是架构层面，汽车软件的复杂度都在升高，而开发工作的效率却没有以同等速率跟上。我们的研究显示，软件复杂度在过去十年已增加到原来的4倍，而软件开发效率只提升了1到1.5倍（图1）。这个问题在变得日益复杂的大型模块中最为严重，如信息娱乐系统和高级驾驶辅助系统（ADAS）。相比传统的深度嵌入式软件，开发这些模块的效率大约低25%到35%。

这个日渐扩大的差距可能会影响车企未来的成功。车企需要投入更多资源开发软件，并在软件生命周期中对其进行维护，这可能会削弱自身在创新和应对竞争对手方面的能力。访谈期间，有位企业领导注意到，如果复杂度持续升高，而效率原地踏步，那么仅软件维护这一项，就会迅速耗尽所有的软件开发资源，不会给创新留下丝毫余裕。最终，复杂度和效率之间的差距将削弱成本竞争力，造成严重的财务和商誉问题。

显而易见，软件开发实力排在前25%的企业，相比实力垫底者，效率高出3倍，产量高出3.5倍，质量好上6倍（图2）。因此，它们的产品面市时间更短，软件功能每提升一个档次所需的开发成本也更低。

硬件方面，实力最强和最弱的企业在业绩上的差距相对不那么明显，因此，在这个领域追求差异化的机会也相应更少。

为了在这个迅速变化的环境中取得成功，企业应当通过减少开发和维护软件需要做的工作，以求最大限度地降低复杂度。这个策略涉及限制各平台和生命周期阶段的功能和特性的版本数量，同时，企业必须加大对构件的重复利用。至于开发效率，企业应当尝试在软件开发速度上向数字原生企业看齐，以提升开发效率。由于软件创新的整体水平不会下降，企业还必须提高其软件开发和维护的产出量，以便交付在市场上取得成功所需的产品和服务。

降低复杂度和提高效率需要一个新的软件运营模式，该模式着重考量四个维度：

• 开发什么软件，包括架构、设计以及各项要求

  
  

• 在哪里开发软件，由企业内部哪个部门开发，包括涉及到的地点、人才及合作关系

  
  

• 采取什么方式开发软件，这个维度考量的是开发工作的方法论，如大规模敏捷开发，或是开发和测试流程的改变

  
  

• 采取什么方式推动软件开发，包括绩效管理和工具链基础架构

第一个维度——开发什么软件——聚焦的是通过模块化和解耦的硬件/软件架构、以用户为中心的设计，以及需求管理，来降低开发复杂度。其他三个维度所聚焦的，则是通过提供合适的结构、流程和基础设施，提高软件开发的效率。我们从四个维度出发，明确了11项最佳实践，这些做法能帮助车企成功地解决在软件上面临的挑战（图3）。理想情况下，企业将同时处理好所有维度。

在新的运营模式下，企业必须把与软件相关的开发目标和业务机会转化为产品、功能和模块等层面上的可行架构、产品及投资组合需求。通过这个流程，企业可以详细了解能为其创造价值的软件类型。这个流程还将助力企业降低架构的复杂度，应用以用户为中心的设计流程，改善对软件需求的管理。

根据我们的研究，如果汽车软件的模块化程度不够，就会使设计复杂度提高，也会提高项目的整体难度。另外，汽车软件的架构构件边界往往是不理想的，这有可能导致更多的相互依存关系，使开发人员在添加新功能时必须修改的构件数量成倍增加。这些依存关系还可能造成一个后果：检测到缺陷时，需要更长的时间和更高的专业水平来追踪特定软件模块和开发团队的错误。

为解决此类问题，OEM必须大幅提高标准化和模块化程度，这样就能实现软件在各平台之间的可扩展性，使软件复杂度维持在可以管理的水平。车企还必须重视两项工作，一是促成软硬件之间的解耦，二是应用服务导向型设计。

解耦架构。车企可以引入一个强大的中间件层次，利用它提取硬件能力，并通过上层使用的标准化应用程序接口（API）使这些能力对软件功能开放（图4）。这种软件架构可以利用各平台之间的共性，降低设计上的复杂度，不必多次重复开发相同的软件。

除了解耦，车企还应当创建一系列标准化的操作系统，利用它们支持各构件之间的协调，确保互通性。很多企业已宣布将要开发此类操作系统，但目前尚不存在统一的方法。

而且企业也还没有明确这些系统的确切研发重点和功能。

通过遵循明确的架构原理和指导原则，企业能够有效地应对更高的系统和软件复杂度。硬件/软件解耦允许多个实体参与模块化开发。反过来，由于代码共性增多，模块化软件构建技术可增加对代码的重复利用，并减少需要的代码总量。很多企业已着手引入软件产品线工程（PLE）方法，以增加重复利用，同时处理产品变更。这个方法能让一个软件服务于多个产品、产品变体和产品系列，还可以兼容不同的硬件版本。软件PLE显著降低了开发和测试工作的难度，这两项工作都只需进行一次。

换句话说，促使硬件从软件上解耦，可促使硬件实现进一步的“自主化”，硬件提供了标准的计算、存储、输入/输出和电源功能，而软件则定义了终端用户功能。对于需要标准性能的应用，不同的软件功能可以利用虚拟化和容器化技术在相同的硬件上运行，如有必要，还可以动态地分布到其他硬件（例如在硬件发生故障的情况下）。对于ADAS等存在实时性能要求的应用，针对特定硬件的软件开发工作对于实现最优效率仍然至关重要。

以服务为导向的架构。该架构应当遵循各项服务的定义，反过来，这些定义则应将业务或用户需求代码化。以服务为导向的架构设计既能让企业实现各核心要素的标准化，也能让各部门和各业务单位之间的接口实现标准化。企业还应对单项硬件和软件要素应用标准化的设计，以便在不影响性能的情况下，针对其他支持设备和功能规模化地配置资源，如计算和存储资源。以服务为导向的架构对OEM尤为重要。实现从车辆到云端的迅速连接，不仅将提升车企各种车型的长期价值，也将推动车企能力的迅速更新和升级。

综观各行业，专注于开发以用户为中心的强大设计、创造最优用户体验（UX）的企业，将实现更高的财务收益[4]。随着ACES概念持续受到追捧，软件定义的汽车成为常态，对于OEM的整体竞争力而言，这些特征将会变得越来越重要。即便是顶尖企业也需要做改进，原因在于汽车行业在设计良好的软件用户体验、提供最优的客户价值等方面仍然落后于其他行业。

按照最佳实践奉行的设计原则，OEM应当与终端用户合作对新软件进行迭代，无论交付前后都应如此。车企也应当采用新的交付模式，以便以每周或每月一次的频率对软件进行更新或添加，从而实现持续的优化。这些工作的周期相比经典软件开发工作短了许多，后者通常需要几年时间。新的交付模式还有一个好处，它可以让OEM与客户实现持续的直接接触，从而使OEM持续收到反馈，而这些反馈有助于它们优化软件需求，提供积极的用户体验提升。当OEM依赖硬件实现升级时，此类互动是不可能实现的，因为接触只会在通过经销商网络进行的一次性销售或市场调研期间发生一次。为了达到这个目标状态，OEM需要落实必要的先决条件，例如配套的软件和电子架构，以及可实现云端更新的工具链。

希望成为用户体验领导者的OEM必须对自己的数据善加利用。随着车载软件和传感器数量不断增多，OEM如今能够获取大量的数据，以了解客户如何使用汽车。OEM可以挖掘此类数据，识别对客户最重要的特性，以及配置超标或根本没人用的特性。这些洞见将为明确配置和未来型号需求提供参考。

最终，新的交付模式将给开发效率带来积极影响。鉴于车企将对软件进行频繁的变更、调适、修改，它们不需要从项目一开始的时候就确定极端详细的需求。由于用在定义需求上的时间缩短了，产品面市时间也将缩短。

历史上，汽车行业曾是在集成的价值链上管理各项需求的领导者。但是，OEM主要关注的是硬件需求，而且它们的既有流程并未针对软件调适到最优状态。随着车载软件成为重要的差异化因素，OEM必须采用新的做法来管理需求。管理需求的变更尤为重要，因为我们的研究显示，对汽车软件的种种需求已经变得过于细化，以至于拖慢了开发进程。

按照最佳实践，OEM应当基于客户价值对各项需求进行聚类。第一个层级应当主要包括面向客户的需求（通常被表述为用例）。另一个层级主要包括技术或实施方面的需求（通常被表述为赋能因素），比如某个特性所需的内存。这个方法可以保证OEM着重关注价值创造，并能在软件开发期间设定合理的优先事项。随着车企将各种需求划分到多个层级，以下工作能够起到帮助作用。

将需求与战略和客户价值挂钩。成功的软件开发需要根据客户反馈对需求进行持续的调整和修正。虽然企业在初期就应根据其商业战略和目标定义软件需求，但它们也应根据客户反馈和开发进度周期性地做出调整。

确保端到端的可追溯性。通过在整条价值链上对需求进行密切追踪，车企可避免做无用功，加快开发进程。但是，只有当车企的开发流程和工具链能够从定义到验收全过程实现需求的严格可追溯性时，车企才能做到这一点。这种明确性有助于车企了解清楚各项需求（客户观点）、需要的功能（开发者观点），以及各项交付成果（测试者观点）。

车企必须分四步实现端到端的追踪，这要么需要用到少数几种高度集成的工具，要么用到四种专业工具，并搭配相应的接口。这些步骤是：

• 对需求进行追踪，从特性到构件对这些需求进行细化和具体说明

  
  

• 管理待办清单，这项工作有助于各团队在软件开发冲刺时管理好各项需求的覆盖范围（与下一个步骤密切相关）

  
  

• 追踪代码变更，包括对代办项目的更新

  
  

• 通过开展测试案例对需求进行验证，并检查测试案例的通过-失败状态

利用工具将各项需求关联起来，用户能够高效地在项目的每个阶段实施变更，从而满足监管对端到端可追溯性的各种要求（例如，ASPICE或UNECE[5]）。利用这个方法，我们能迅速弄清楚哪些变更影响到了哪些工作成果。当遵循敏捷流程开发软件时，此类需求变更是正常的，也是可取的（如基于客户反馈的变更），企业应当利用各种流程和工具对它们予以支持。在软件开发工作的传统瀑布式流程当中，此类变更是罕见的，而且通常也预见不到。

避免过度细化，创建明确的需求类别。企业可以建立一些最佳实践，对软件需求进行具体说明和分类，并拟定精简的测试办法。一份优秀的需求说明应当是清晰明确的，而且允许测试工作不受其他需求影响。与组合管理一样，企业应当对不同类型的需求加以区分。常见的需求类别包括法律监管类、安全类、战略类，以及必要改进、客户价值、成本赋能等因素。另外，企业还必须确保，凡是需求之间的依存关系都应当是透明的。很多企业已经将这些规则融入到自己的软件开发流程和培训课程之中，以便优化对需求的处理和评审过程。

开展优先排序，进行持续调整。企业既应根据具体的商业论证和战略目标，也应根据在整个开发过程中（例如在测试过程中）获得的客户反馈和经验对软件需求进行评估和优先排序。企业应当定期对需求进行重新评估，并在一份公开透明的待办清单中对其加以维护。

很多企业任命了产品负责人，这些人拥有宽广的知识面，可以做出产品功能取舍，组建跨职能团队，并确保各职能部门就各项需求达成共识。根据最佳实践，产品负责人还需要负责遵循最佳实践，并对需求和用例的待办清单进行维护。

[1] 基于麦肯锡的SoftCoster专有数据库的信息，该数据库包含多个行业的14000多个软件开发项目。

[2] 麦肯锡未来研发调研。

[3] Ondrej Burkacky、Johannes Deichmann、Jan Paul Stein合撰的文章《2030年的汽车软件与电子市场：梳理行业的未来格局》（Automotive software and electronics 2030: Mapping the sector’s future landscape），2019年7月9日，McKinsey.com；文章续篇即将出炉。

[4] 基于针对业务发展的麦肯锡设计指数评分的相关分析。如欲了解更多信息，参阅Benedict Sheppard、Hugo Sarrazin、Garen Kouyoumjian和Fabricio Dore合撰的文章《设计的商业价值》（The business value of design），McKinsey Quarterly，2018年10月25日，McKinsey.com。

[5] 汽车软件流程改进及能力评定（Automotive Software Performance Improvement and Capability determination）；联合国欧洲经济委员会（United Nations Economic Commission for Europe）。

关于作者：

Ondrej Burkacky是麦肯锡全球董事合伙人，常驻慕尼黑分公司；

Dominik Hepp是麦肯锡全球董事合伙人，常驻慕尼黑分公司； 

Johannes Deichmann是麦肯锡全球董事合伙人，常驻斯图加特分公司；

Stefan Frank是麦肯锡咨询顾问，常驻汉堡分公司；

André Rocha是麦肯锡全球董事合伙人，常驻东京分公司。

作者感谢Silviu Apostu、Georg Doll、JuliaGößwein、Anna Gomulec、Virginia Herbst、Shannon Johnston、Maximilian Lemmens和Henrik Rochlitz对本文的贡献。

本文中文版由麦肯锡全球董事合伙人彭波与全球副董事合伙人陈晴审阅。

麦肯锡公司版权所有©2021年。未经许可，不得做任何形式的转载和出版。转载请在消息栏回复“转载”查阅须知。