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

麦肯锡未来出行研究中心 代 码 为 王 的 时 代 ：车 企 如 何掌握卓越软件开发能力 由于软件正在推动汽车行业的创新，车企研发部门必须迅速掌握软件 开发这项复杂能力。 2021年 1月 JackyLeung/Getty Images 文/ Ondrej Burkacky, Johannes Deichmann, Stefan Frank, Dominik Hepp, and Andr Rocha 软件正在迅速重塑汽车行业。 近 年 来 ，业 内的四股颠覆浪潮自动驾驶化、网联 化、电动化、共享化（ ACES） 全 都 重 度 依赖先进的软件。这些领域未来还将迎来 更 多 的 颠 覆 发 展 。全 行 业 的 整 车 厂（ OEM）、 供应商和新企业无不希望自己能在这条由 软件驱动的新价值链上把握住关键的控 制点。 软件：关键的行业转折点 随 着 行 业 格 局 改 变 ，缺 少 软 件 能 力 的 车 企 将面临重大风险，包括量产（ SOP）延 期 和 预 算 超 支 。它 们 甚 至 可 能 落 后 于 竞 争 对 手 和 新 入 场 者，倘 若 后 两 者 能 以 快 得 多 的 速 度将新颖得多的产品推向市场的话。更糟的 是，软件问题可能导致大规模召回，或是让 车企无力防范因黑客攻击而产生的客户安 全风险。 我们的研究显示，软件能力强的企业和能力 弱 的 企 业 之 间 的 差 距 是 显 著 的 ，能 力 最 强 的 企 业 报 告 中 公 布 的 产 量 和 质 量 ，比 能 力 垫 底的企业高出三到六倍 1。这 一 开 发 效 率 差 距远大于不同能力的硬件生产商之间可产生 的差距。很多车企已认识到强大的软件开 发能力带来的各种优势，也正在采取大刀 阔斧的措施改善业绩。一些车企计划在今 后 几 年 提 升 软 件 能 力 ，并 将 招 聘 数 以 千 计 的 软 件 工 程 师 ；另 一 些 则 将 重 新 定 义 治 理 模式，建立合作关系，并在全球推广卓越软 件开发中心。 然而，我们认为这些措施是不够的，因为只 有当车企针对软件开发更新了基 础运营模 式 的 时 候 ，真 正 的 变 革 才 会 到 来 。根 据 我 们 的研究，在那些认为软件是主要颠覆因素 的 车 企 研 发 领 导 当 中，仅 有 40%的人觉得自 己已为必要的运营变革做好了准备 2。虽 然 一些领军车企已在软件工程实践上取得长 足 进 步，但 大 部 分 车 企 仍 然 远 远 落 后 于 佼 佼者。目前车企的问题集中在几个领域：敏 捷 实 践 、持 续 集 成 、自 动 化 测 试 。 软 件 开 发 转 型 的 风 险 如 此 之 大 ，车 企 必 须 对 一 整 套 软 件 开 发 方 法 进 行 重 新 思 考 ，包 括 基 础 运 营 模 式 等 。本 文 分 享了我 们 通 过 与 车 企 、供 应 商 ，以 及 生 态 圈 中 其 他 合 作 伙 伴 密 切 合 作 ，收 获 的 关 键 理 念 和 洞 见 。这 些洞见还建立在两项基础上：一是针对技 术专家开展的广泛访谈，二是利用麦肯锡 SottCoster专有数据库进行的大规模对标。 1 基于麦肯锡的 SoftCoster专有数据库的信息，该数据库包含多个行业的 14000多个软件开发项目。 2 麦肯锡未来研发调研。 根据我们的研究，在那些认为软件是主要颠 覆 因 素 的 车 企 研 发 领 导 当 中 ，仅 有 40%的人 觉得自己已为必要的运营变革做好了准备 2 代码为王的时代：车企如何掌握卓越软件开发技能 2020 2030 12 11 12 4 1 1.5 1 ADAS 25 35 25 3 3.5 6 2 1 软件复杂度提高的速度比生产力提高的速度更快 资料来源：麦肯锡 SoftCoster嵌入式软件项目数据库 复杂度 生产力 20202010 4 3 2 1 各时期软件复杂度与生产力的相对增幅，已根据汽车软件特征做了指数化 3 Ondrej Burkacky, Johannes Deichmann, Jan Paul Stein 2030 Automotive software and electronics 2030: Mapping the sectors future landscape 2019 7 9 McK 3 代码 为 王 的 时 代 ： 车 企 如 何 掌 握 卓 越 软 件 开 发 技 能 2 软件开发实力位居前25%的企业表现出明显较高的生产力、开发通量和质量 生产力，每人周的复杂度单位 质量，残余设计缺陷开发通量，每周复杂度单位 1 1. 平均水平已指数化，基准值100。每人周复杂度单位代表每个全职员工的生产力。每周复杂度单位代表整个组织的生产力。 +3.0 6.0 +3.5 100 100 65 175 65 100 224 155 27 研发实力处在平均水平和第四四分位上的研发组织在研发业绩上的潜在增长 第四四分位 第一四分位平均水平 1 资料来源：麦肯锡SoftCoster嵌入式软件项目数据库 4 代码 为 王 的 时 代 ： 车 企 如 何 掌 握 卓 越 软 件 开 发 技 能 第一个维度开发什么软件聚焦的 是通过模块化和解耦的硬件/软件架构、以 用 户 为 中 心 的 设 计 ，以 及 需 求 管 理 ，来 降 低 开发复杂度。其他三个维度所聚焦的，则 是 通 过 提 供 合 适 的 结 构 、流 程 和 基 础 设 施 提高软件开发的效率。我们从四个维度出发， 明确了 11项最佳实践，这些做法能帮助车企 成功地解决在软件上面临的挑战（图 3）。理 想 情 况 下，企 业 将 同 时 处 理 好 所 有 维 度 。 A.开发什么软件：架构、设计及各 项 要 求 在新的运营模式下，企业必须把与软件相关 的开发目标和业务机会转化为产品、功能和 模块等层面上的可行架构、产品及投资组合 需求。通过这个流程，企业可以详细了解能 为其创造价值的软件类型。这个流程还将 助力企业降低架构的复杂度，应用以用户为 中心的设计流程，改善对软件需求的管理。 图 3 新的软件开发运营模式需要对四个关键维度做出改变 开发什么软件 A D B C 在哪里开发软 件 如何促进软件 开发 如何开发软件 降低架构的复杂度 应用以用户为中心 的设计 对软件需求的管 理方式进行调整 调整组织并建立 全球卓越中心 确保企业有能力 获取顶尖软件开 发人才资源，并 对其保持吸引力 制定清晰的“自制 或外购”策略并建 立合作生态圈 实施绩效管理 升级到标准化的先进软件开发工具链 实施大规模敏捷 方法 实现硬件与软件 开发之间的解耦 提高测试的自动 化程度，实现成 熟的持续集成 各维度的最佳实践 5 代码为王的时代：车企如何掌握卓越软件开发技能 A1. OEM API 4 4 车企必须力争实现一个理想架构，使之能支持软硬件之间的解耦，而且具备 强大的中间件层次 云平台 联网（回传） 应用 汽车 传感器 执行器 动力构件 用户界面/用户体验/人机界面 中间件层/操作系统 电气/电子硬件 人工智能/高级分析 应用层将围绕服务重构 将根据现代软件开发的各种做法，在不对 基础硬件做假设的情况下打造应用 AI/AA将通过中间件/数据库使用专业硬件 中间件层次将抽取硬件并将API暴露给上层 软件 模块化的中间件架构 API将定义可供上层软件使用的复杂的、 标准化的硬件功能集合 标准化的操作系统将协调各类电子及域 控制单元以及传感器之间的功能，确保 互通性 6 代码 为 王 的 时 代 ： 车 企 如 何 掌 握 卓 越 软 件 开 发 技 能 而且企业也还没有明确这些系统的确切研 发重点和功能。 通 过 遵 循 明 确 的 架 构 原 理 和 指 导 原 则 ，企 业能够有效地应对更高的系统和软件复杂 度。硬件/软件解耦允许多个实体参与模块 化开发。反过来，由于代码共性增多，模块 化软件构建技术可增加对代码的重复利用， 并减少需要的代码总量。很多企业已着手引 入 软 件 产品 线 工 程（ PLE）方 法 ，以 增 加 重 复 利用，同时处理产品变更。这个方法能让一 个软件服务于多个产品、产品变体和产品系 列，还可以兼容不同的硬件版本。软件 PLE 显 著 降 低了开 发 和 测 试 工 作 的 难 度 ，这 两 项 工作都只需进行一次。 换句话说，促使硬件从软件上解耦，可促使 硬件实现进一步的“自主化”，硬件提供了标 准的计算、存储、输入/输出和电源功能，而 软 件 则 定 义了终 端 用户 功 能 。对 于 需 要 标 准 性能的应用，不同的软件功能可以利用虚拟 化和容器化技术在相同的硬件上运行，如 有 必 要 ，还 可 以 动 态 地 分 布 到 其 他 硬 件（ 例 如 在 硬 件 发 生 故 障 的 情 况 下 ）。对 于 ADAS 等存在实时性能要求的应用，针对特定硬件 的软件开发工作对于实现最优效率仍然至 关重要。 以服务为导向的架构 。该 架 构 应 当 遵 循 各 项服务的定义，反过来，这些定义则应将业 务 或 用 户 需 求 代 码 化 。以 服 务 为 导 向 的 架 构设计既能让企业实现各核心要素的标准 化 ，也 能 让 各 部 门 和 各 业 务 单 位 之 间 的 接 口 实现标准化。企业还应对单项硬件和软件 要素应用标准化的设计，以便在不影响性能 的 情 况 下，针 对 其 他 支 持 设 备 和 功 能 规 模 化 地配置资源，如计算和存储资源。以服务为 导向的架构对 OEM尤 为 重 要 。实 现 从 车 辆 到云端的迅速连接，不仅将提升车企各种 车型的长期价值，也将推动车企能力的迅 速更新和升级。 A2.应用以用户为中心的设计技术 综观各行业，专注于开发以用户为中心的 强 大 设 计 、创 造 最 优 用 户 体 验（ UX）的 企 业 ， 将实现更高的财务收益 4。随 着 ACES概念 持续受到追捧，软件定义的汽车成为常态， 对于 OEM的整体竞争力而言，这些特征将 会变得越来越重要。即便是顶尖企业也需 要做改进，原因在于汽车行业在设计良好 的软件用户体验、提供最优的客户价值等方 面仍然落后于其他行业。 按照最佳实践奉行的设计原则， OEM应当 与 终 端 用 户合 作 对 新 软 件 进 行 迭 代 ，无 论 交付前后都应如此。车企也应当采用新的 交付模式，以便以每周或每月一次的频率 对 软 件 进 行 更 新 或 添 加 ，从 而 实 现 持 续 的 优化。这些工作的周期相比经典软件开发 工作短了许多，后者通常需要几年时间。新 的 交 付 模 式 还 有 一 个 好 处 ，它 可 以 让 OEM 与 客 户实 现 持 续 的 直 接 接 触 ，从 而 使 OEM 持续收到反馈，而这些反馈有助于它们优 化软件需求，提供积极的用户体验提升。当 OEM依 赖 硬 件 实 现 升 级 时 ，此 类 互 动 是 不 可能实现的，因为接触只会在通过经销商网 络进行的一次性销售或市场调研期间发生 一次。为了达到这个目标状态， OEM需要落 实必要的先决条件，例如配套的软件和电 子架构，以及可实现云端更新的工具链。 希望成为用户体验领导者的 OEM必须对自 己 的 数 据 善 加 利 用 。随 着 车 载 软 件 和 传 感 器 数量不断增多， OEM如今能够获取大量 的 数 据 ，以 了 解 客 户 如 何 使 用 汽 车 。 OEM 可以挖掘此类数据，识别对客户最重要的 4 基 于针对业务发展的麦肯锡设计指数评分的相关分析。如欲了解更多信息，参阅 Benedict Sheppard, Hugo Sarrazin, Garen Kouyoumjian和 Fabricio Dore合撰的文章设计的商业价值（ The business value of design）, McKinsey Quarterly, 2018年 10月 25日 , McK。 7 代码为王的时代：车企如何掌握卓越软件开发技能 特性，以及配置超标或根本没人用的特性。 这些洞见将为明确配置和未来型号需求提 供参考。 最 终 ，新 的 交 付 模 式 将 给 开 发 效 率 带 来 积 极影响。鉴于车企将对软件进行频繁的变 更 、调 适 、修 改 ，它 们 不 需 要 从 项 目 一 开 始 的 时 候 就 确 定 极 端 详 细 的 需 求 。由 于 用 在 定义需求上的时间缩短了，产品面市时间也 将缩短。 A3.调整软件需求管理 历 史 上 ，汽 车 行 业 曾 是 在 集 成 的 价 值 链 上 管 理 各 项 需 求 的 领 导 者 。但 是 ， OEM主要关注 的 是 硬 件 需 求 ，而 且 它 们 的 既 有 流 程 并 未 针对软件调适到最优状态。随着车载软件 成为重要的差异化因素， OEM必须采用新 的做法来管理需求。管理需求的变更尤为重 要，因为我们的研究显示，对汽车软件的种 种需求已经变得过于细化，以至于拖慢了开 发进程。 按照最佳实践， OEM应当基于客户价值对 各 项 需 求 进 行 聚 类 。第 一 个 层 级 应 当 主 要 包括面向客户的需求（通常被表述为用例）。 另一个层级主要包括技术或实施方面的需 求（ 通 常 被 表 述 为 赋 能 因 素 ），比 如 某 个 特 性所需的内存。这个方法可以保证 OEM着 重关注价值创造，并能在软件开发期间设定 合理的优先事项。随着车企将各种需求划 分到多个层级，以下工作能够起到帮助作用。 将需求与战略和客户价值挂钩 。成 功 的 软 件开发需要根据客户反馈对需求进行持续 的调整和修正。虽然企业在初期就应根据 其商业战略和目标定义软件需求，但它们也 应根 据客户反馈和开发进 度 周期性地做出 调整。 确保端到端的可追溯性 。通 过 在 整 条 价 值 链 上 对 需 求 进 行 密 切 追 踪 ，车 企 可 避 免 做 无 用 功 ，加 快 开 发 进 程 。但 是 ，只 有 当 车 企 的开发流程和工具链能够从定义到验收全 过 程 实 现 需 求 的 严 格 可 追 溯 性 时 ，车 企 才 能 做 到 这 一 点 。这 种 明 确 性 有 助 于 车 企了解 清 楚各项需求（客户观点）、需要的功能 （开发者观点），以及各项交付成果（测试 者 观 点 ）。 车企必须分四步实现端到端的追踪，这要 么需要用到少数几种高度集成的工具，要么 用 到 四 种 专 业 工 具 ，并 搭 配 相 应 的 接 口 。这 些步骤是： 对需求进行追踪，从特性到构件对这些 需求进行细化和具体说明 成功的软件开发需要根据客户反馈对需求 进行持续的调整和修正 8 代码为王的时代：车企如何掌握卓越软件开发技能 管 理 待 办 清 单 ，这 项 工 作 有 助 于 各 团 队 在软件开发冲刺时管理好各项需求的覆 盖 范 围（ 与 下 一 个 步 骤 密 切 相 关 ） 追踪代码变更，包括对代办项目的更新 通过开展测试案例对需求进行验证，并 检查测试案例的通过-失败状态 利 用 工 具 将 各 项 需 求 关 联 起 来 ，用 户 能 够高效地在项目的每个阶段实施变更，从 而满足监管对端到端可追溯性的各种要求 （例如， ASPICE或 UNECE5）。利用这个方 法，我们能迅速弄清楚哪些变更影响到了 哪些工作成果。当遵循敏捷流程开发软件 时，此类需求变更是正常的，也是可取的 （ 如 基 于 客 户 反 馈 的 变 更 ），企 业 应 当 利 用 各 种流程和工具对它们予以支持。在软件开 发 工 作 的 传 统 瀑 布 式 流 程 当 中，此 类 变 更 是 罕见的，而且通常也预见不到。 避免过度细化，创建明确的需求类别 。企 业 可以建立一些最佳实践，对软件需求进行具 体说明和分类，并拟定精简的测试办法。一 份 优 秀 的 需 求 说 明 应 当 是 清 晰 明 确 的 ，而 且 允许测试工作不受其他需求影响。与组合管 理一样，企业应当对不同类型的需求加以区 分。常见的需求类别包括法律监管类、安全 类 、战 略 类 ，以 及 必 要 改 进 、客 户 价 值 、成 本 赋 能 等 因 素 。另 外 ，企 业 还 必 须 确 保 ，凡 是需求之间的依存关系都应当是透明的。很 多企业已经将这些规则融入到自己的软件 开 发 流 程 和 培 训 课 程 之 中，以 便 优 化 对 需 求的处理和评审过程。 开展优先排序，进行持续调整 。企业既应根 据具体的商业论证和战略目标，也应根据 在整个开发过程中（例如在测试过程中）获 得的客户反馈和和经验对软件需求进行评 估 和 优 先 排 序 。企 业 应 当 定 期 对 需 求 进 行 重新评估，并在一份公开透明的待办清单中 对其加以维护。 很 多 企 业 任 命了产 品负 责人 ，这 些 人 拥 有 宽 广 的 知 识 面 ，可 以 做 出 产 品 功 能 取 舍 ，组 建 跨职能团队，并确保各职能部门就各项需 求 达 成 共 识 。根 据 最 佳 实 践 ，产 品 负 责 人 还 需要负责遵循最佳实践，并对需求和用例的 待办清单进行维护。 B. 在 哪 里 开 发 软 件 ：组 织 、地 点 、人 才与合 作伙伴 大部分车企缺乏处理大规模软件开发工作 所需的组织基础。它们面临多重挑战，有的 在执行层面极少或没有划分出明确的职责， 有的没有足够的软件工程师和架构师。凭借 明确软件开发工作所需的组织架构、地点 和人才策略、“自研或外包”策略，以及所需 的 合 作 关 系 生 态 圈 ，新 的 运 营 模 式 将 会 解 决 这些问题。 B1.调整组织，建立全球卓越软件中心 在组织层面，大部分车企还没有做好准备， 无力应对致使软件重要性攀升的 ACES趋势。 例如， OEM就软件问题进行决策时通常比 较 缓 慢 ，很 多 车 企 对 于 车 载 平 台 的 软 件 、电 子设备策略，以及相关预算的主要权责尚 无明确的划分。为了在新形势下保持竞争力， 车企必须重新思考其组织设置。此项工作 的一个主要目标，是要在端到端开发流程期 间减少在架构定义、需求定义以及开发这 几 项 工 作 之中 的 接 口。通 过 增 进 各 团 队 在 各 阶 段 的 共 识 和 协 作 ，车 企 可 以 避 免 做 多 余 的工作，并优化各种既有的和全新的能力。 5 汽车软件流程改进及能力评定（ Automotive Software Performance Improvement and Capability determination）；联 合 国 欧 洲 经 济 委 员 会 （ United Nations Economic Commission for Europe）。 9 代码为王的时代：车企如何掌握卓越软件开发技能 很多车企已成立一个集中化的职能部门，依 靠 该 部 门 负 责 软 件 架 构 设 计 ，并 分 享 已 固 化 的 最 佳 实 践 。例 如 ，一 家 OEM最近 成立了一 个中央职能部门，该部门聚集了 5000名软 件开发人员。然而，大多数情况下， OEM对 软件开发仍采取较为去中心化的方法。 几种组织类型。 尝试改进软件开发工作 时， OEM可以采用几种常见的组织类型。 对于每家企业而言，能反映公司优先事项 的选项，就是最佳选项，这些优先事项包 括加快决策、减少接口、明确职责等。更重 要 的 是 ，企 业 必 须 开 展 专 项 工 作 ，以 便 协 调来自不同组织职能的要求，这些职能包 括研发、采购、生产、销售和后市场等部门， 这是因为这些职能对软件的需求和生命周 期 变 更 可 能 彼 此 存 在 冲 突 。此 举 将 确 保 无 缝的用户接口和高效的开发流程。除了重塑 组织，车企还必须对弥合软硬件团队文化 差距和协调工作流程进行大量投入以开展 相应行动。这些工作需要持续的变革管理， 但它们将有助于车企成为软件开发重镇。 在 定 义 组 织 架 构 时 ，汽 车 软 件 开 发 单 位 将 对职能角色、产品或项目，以及技术构建理 想图景。不过，这个组织架构一般会从前 述的几个维度中选择一个作为核心。 在此可参考一个强调职能角色的组织架构。 在 这 种 模 式 下，企 业 将 从 软 件 职 能 组 织 抽 调个体成员，派往针对特定产品或平台的 项 目 。产 品 和 技 术 将 通 过 面 向 各 职 能 单 位 的间接、“虚线式”的汇报架构得到体现。这 种 架 构 为 企 业 赋 予了最 大 的 灵 活 性 ，因 为 它 们不需要为了适应产品/项目和技术方面的 额 外 要 求 而 重 塑 组 织 。然 而 ，这 种 架 构 之 下 的开发效率可能不是最佳的，这会使成立 跨 部 门 职 能 变 得 更 有 必 要 ，如 项 目 管 理 、架 构和人员配置部门。 在第二种类型中，组织架构侧重的是项目， 诸 如 针 对 特 定 客 户 、车 系 、车 型 乃 至 平 台 的 项目 。这 种 类 型 可 利 用 “ 虚 线 式 ” 汇 报 条 线 和 成熟流程将产品和技术这两个维度联系起 来 。这 种 类 型 使 得 客 户 和 终 端 产品 成 为 组 织 的 首 要 焦 点 。从 不 利 方 面 来 看， 它 提 高 尽管车企必须在诸多方面表现优异才能赢得 这场软件竞赛，吸引和留住顶尖人才很可能 才是最重要的维度 10 代码为王的时代：车企如何掌握卓越软件开发技能 了冗余工作的风险，也在不同的产品或项目 团 队 之 间 造 成了各 种 障 碍 ，这 可 能 对 技 术 移 交 形 成 干 扰 。强 大 的 平 台 和 架 构 有 助 于 缓解这些风险。 在第三种类型中，组织架构侧重的是技术 和 专 业 领 域 ，如 网 络 、人 机 界 面 ，或 是 后 端 。 在 这 种 模 式 下，企 业 从 技 术 部 门 抽 调 个 体 成 员派 往 具 体 产品 的 项目。通 过 虚 线 汇 报 和成熟的工作流程，这个方法能实现对技 术和职能这两个维度的聚焦。虽然这个模 式 有 助 于 养 成 深 厚 的 技 术 和 专 长 领 域 ，但 它 在 项 目 范 围 、需 求 、规 格 方 面 的 灵 活 性 很 差，即使这几方面在项目期间发生变化时也 是 如 此 。在 开 发 和 维 护 多 种 产 品 时 ，企 业 通 常会采用这个类型。 B2. 获 得 并 吸 引 顶 尖 人 才，开 展 内 部 能 力 建设 虽然车企必须在诸多方面表现优异才能赢 得这场软件竞赛，但吸引和留住顶尖人才很 可能才是最重要的维度。 大部分 OEM已将软件开发工作大量外包并 依赖战略合作伙伴关系。 ACES趋势极大 地提高了软件的重要性，即便软件开发效 率有迎来几番增长的潜力， 2030年前对于 软件工程师的需求仍可能增加三到四倍。由 于汽车行业正在与科技企业以及其他行业 正面竞争软件人才，车企需要采取较为大刀 阔斧的举措才能改善顶级开发人员的招募 工作。否则，不断扩大的人才缺口还将继续 扩大。 汽车软件人才的招聘和挽留计划应当侧重 于实现差异化。根据我们的对标分析结果， 相比只具备同质化经验的团队，具备多样 经验的团队在开发效率方面的绩效要高出 两位数的百分比。企业可以通过开展以下几 项工作改善人才招募现状， 要加大对全球软件开发人才资源的利用。 综合选址策略有助于企业扩展其软件开发 活动、构建相关能力并提升产能，同时确保 成本可控。而这也有助于企业争夺顶级人 才。一些创新企业已经在数字人才热点地区 建立了新的汽车工程中心，例如自动驾驶中 心。不过，大多数传统型企业在很大程度上 还 是 保 留 了其 历 史 足 迹 和 硬 件 中 心 ，但 这 可 能使其吸引和留住软件人才的努力变得复 杂 化 。如 果 这 些 企 业 在 关 键 区 域 的 多 个 地 点开展业务的话，就可以从附近的大学和 其他教育机构吸纳人才。为加强联系，这些 企 业 可 以 与 大 学 合 作 开 展 访 学 实 习 计 划 ，使 其能够接触到应届毕业生和其他专业技能 人才。 尽 管 全 球 足 迹 可 带 来 诸 多 好 处 ，但 也 需 要 合 适 的 运 营 模 式 ，才 能 避 免 远 程 和 / 或 分 布 式 工 作 的 普 遍 问 题 。例 如 ，研 究 表 明 ，开 发 项目每增加一个新站点，软件开发效率平均 会下降约 10%。 使企业对软件人才更具吸引力。 我们的研 究表明，薪酬、职业发展机会、工作类型和 企业文化是留住软件工程师的首要因素。目 前，车企在上述这些方面均落后于科技企 业。为弥合差距，前者必须针对所有重要的 影响因素制定独特且有针对性的雇主价值 主张，不能再简单地固守传统福利，如就业 保障和企业配车等。 11 代码为王的时代：车企如何掌握卓越软件开发技能 鼓励内部能力建设。 一个合理的做法是，尽 可 能 重 新 培 训 目 前 以 硬 件 为 主 的 员 工 ，让 其 在技能升级后承担软件相关职责。例如，企 业可以培训硬件项目经理来监督软件项目。 但 是 ，只 有 当 企 业 在 软 件 专 业 人 员 和 经 过 再培训的硬件专家之间保持良好的平衡时， 这 种 做 法 才 行 之 有 效 。这 个 平 衡 视 具 体 企 业 情 况 可 能 有 所 不 同 ，而 且 难 以 量 化 。不 过 ， 根据经验，许多企业将比例保持在 2： 1（即 2位软件专业人员： 1位再培训硬件专家）时， 效果最好。要获得最佳结果，企业应制定有 吸引力的发展计划和在职培训计划，帮助员 工 快 速 学 习 新 的 软 件 语 言 和 方 法 。此 外，还 应强调终身学习。 尽 管 再 培 训 可 能 会 弥 补 许 多人 才 缺 口，但 企 业不应忘记，大多数人都是在工作多年后才 发 展 出 根 深 蒂 固 的 解 决 问 题 模 式 。出 现 意 外 问题时，硬件背景的软件员工可能采用固化 的问题解决方法，而这些方法可能更偏线性 而非敏捷性。因此，企业应尝试在培训期间 鼓 励 采 用 新 的 思 维 方 式 。若 能 成 功 的 话 ，软 件专家和再培训员工之间的差异将迅速缩 小。相反，忽视这种做法则可能妨碍整个组 织的敏捷转型。 提供职业路径。 与 技 术 企 业 相 比 ，大 多 数 车 企在明确职业路径和成长机会方面仍存在 不足。之所以出现这种差距，是因为专家职 业路径在车企还未广泛普及。此外， OEM 也很少定义职位期望和资历级别。想要继 续晋升的专家就只能担任管理职务，因为没 有其他选择。 为了提高留存率，车企可以引入明确的职业 路径，每个级别都有特定的技能要求。一 些路径面向业务专家，另一些则针对管理人 才。晋升路径可以是纵向的（从初级到高级 开发人员再到团队负责人），或者同样重要 的横向轮岗，持续六个月或以上，侧重培养 不 同 的 技 能 ，包 括 与 领 导 力 、项 目 管 理 和 软 件开发有关的技能。企业还应制定专门的培 训计划，包括职位和跨学科培训，开放给更 大 范 围 的 员 工 。明 确 的 职 业 路 径 有 望 提 高 效 率 ，因 为 专 家 通 常 比 新 手 效 率 更 高 。 B3.明确清晰的“自研或外包”策略并建立 合 作生态圈 要保持来之不易的竞争优势并避免成为同 质化的硬件平台开发商，车企必须制定明 确 的 客 户战 略 ，确 定 差 异 化 配 置 和 价 值 主 由于汽车行业正在与科技企业以及其他行 业正面竞争软件人才，车企需要采取较为大 刀阔斧的举措才能改善顶级开发人员的招 募工作。否则，不断扩大的人才缺口还将继 续扩大 12 代码为王的时代：车企如何掌握卓越软件开发技能 5 收 测 试 OEM 5 企业在进行自制或外购决策时应考虑三大维度 需求 网关/联网 ADAS/AD 1 动力总成/底盘 /能源 车身舒适性 信息娱乐 开发 单元测试 系统架构 软件架构 组件架构 系统集成 集成测试 验收 汽车示例 开发过程所处阶段 软件技术栈 软件领域/模块 应用程序和功能 运营系统 硬件抽象 固件和信号处理 指导和管理能力 基础设施和工具 绩效管理 后端 1.先进的驾驶员辅助系统和自动驾驶 + + 13 代码 为 王 的 时 代 ： 车 企 如 何 掌 握 卓 越 软 件 开 发 技 能 我们的研究表明，超过这个数量就会导致 开发效率下降 65%以上。 在全面的“自研或外包”策略中，企业应采用 标准的开源组件，因为它们在软件开发过程 中可提供巨大的优势。不过，企业需建立明 确的开源模块使用规则和流程，并注意许 可 、责 任 和 维 护 问 题 。通 常 ， OEM和供应商 需 签 署 正 式 的 法 律 协 议 ，才 能 在 产 品 中 使 用 开源组件。 最 后 ，车 企 应 发 展 战 略 合 作 伙 伴 关 系 ，确 定 生态圈合作企业，因为这些联系有助于相 互 学 习 ，同 时 加 快 开 发 速 度 并 保 持 较 低 成 本。共同开发还可降低较晚进入市场所产生 的风险。 在“自研或 外包”策略中， OEM会将差异化功 能的生产留在内部，而将非关键软件的开发 外包给其他供应商或承包商。除前述优势外， 该方法还将大大减少对软件人才的需求。 C.如何开发软件：敏捷、解耦、测试 传 统 上 ，车 企 一 直 都 更 重 视 硬 件 ，其 次 才 是 软件。现在必须重新审视这种观点以及开 发 方 法 ，因 为 软 件 现 在 是 产 品 开 发 组 合 中 的 一 个 主 要 的 价 值 驱 动 力 。这 个 转 变 要 求 车 企 实施大规模的敏捷方法，解耦硬件和软件 开发流程，同时提高测试自动化和持续集 成的水平。 C1.实施大规模敏捷方法 敏捷方法在硬件和软件上得到大规模应用 时，可使企业提高开发效率并快速应对环 境变化。通过敏捷转型，各行业企业都实 现了开发效率和实施 速度 30% 的 提 升 ，同 时 将发布时的残留缺陷减少了 70%以上。 6 因 为降低了项目预算、时间和质量方面的风险， 所以敏捷 在应对复杂性挑战 上发挥了至关 重要的作用。 迄今为止，只有少数车企自始至终地推广敏 捷软件开发的实践做法。尽管许多企业都 在试点，尤其是在高级开发项目上，但只有 少数真正大规模实施了敏捷方法。 传统车企一直更重视 硬件，其次才是软件。 现在必须重新审视这种观点以及开发方法， 因为软件是当前产品开发组合中一个主要的 价值驱动力 6 麦 肯锡的 SoftCoster嵌入式软件项目数据库。 14 代码为王的时代：车企如何掌握卓越软件开发技能 采用率低的原因可能在于汽车行业的应用 有非常具体的要求，因此很难在整个组织中 实施标准的敏捷方法。此外，汽车行业使用 的敏捷工具必须能够处理系统复杂性、与硬 件 开 发 之 间 复 杂 的 相 依 关 系 、以 及 网 络 安 全 、 车辆安全性和质量相关的严格法规要求。 与硬件开发的依存关系。 要有效管理相依关 系， OEM可将系统工程与需求管理技术相 结合，采用大规模的敏捷方法。这些做法可 确保流畅的软硬件集成，以及开发时间线 的同步。 涵盖总体架构、集成和测试的经典系统工 程实践做法将确保集成化的产品生命周期 管理，并帮助企业满足法规要求。企业可利 用系统工程实践，明确车辆和领域整体架构 （图 6）。反过来，这又为敏捷团队提供了高 层输入和边界条件。基于这些输入，敏捷团 队可以先细化软件需求，再进行组件的开发 和测试工作。开发周期结束时，当领域、车 辆 集 成 和 测 试 活 动 合 成 完 整 系 统 后 ，团 队 即 可关闭系统工程回路。 从项目管理的角度来看，目标是使各部门对 控制单元和领域架构专用要素的优先级和 所需同步点达成一致意见。例如，企业应优 先 考 虑 并 跟 踪 某 些 功 能 的 交 付 情 况 ，因 为 这些功能的启动对于时间敏感事件如冬季 测试，是必不可少的。这样，在看总体需求 完成指标时，就只需监控那些不太重要的功 能了。 图 6 车企应将总体系统工程与敏捷软件开发相结合 车辆架构 Scrum 流程 域需求和架构 车辆集成与测试 域集成与测试 控制单元需求 和架构 控制单元集成 和测试 组件和软件功 能测试 组件和软件功 能需求 组件设计和软件实施 系统工程 车辆和领域总体架构，作为 敏捷待办事项的输入和边界 条件 系统工程与敏捷相结合 敏捷 15 代码为王的时代：车企如何掌握卓越软件开发技能 法规要求和行业标准。 敏捷开发做法在汽 车 行 业 环 境 下 完 全 可 行，且 大 大 提 升了效 率 ， 但企业必须考虑法规以及硬软件的基本同 步问题。 因此，可能需要更改部分传统的工作流程， 例如创建认证组件的方法（从而符合 ISO 26262标 准 ）。在 传 统 瀑 布 式 开 发 模 式 下，认 证组件的生成顺序与工程活动相同，即规 划 、客 户 需 求 、系 统 架 构 、软 件 需 求 、软 件 实 施 和 软 件 测 试 。而 在 敏 捷 开 发 模 式 中，最 好 的方法却是反向认证，即在项目结束时，也 就是所有软件需求和代码都确定、固定之后， 创建认证组件。这种做法可最大程度地减 少浪费，因为不用多次生成认证组件，并且需 要软件安全审核员从项目支出保持一致，且 与团队关系良好。软硬件解耦有望进一步简 化 ISO 26262认 证 工 作 ，因 为 重 复 使 用 的 软 件可能会通过经验证的参数进行合规验证， 即当其他应用程序已经使用该软件而未出 现问题，则证明可使用该软件。 目 前 ，诸 如 ASPICE之类的行业标准规定所 有需求都必须可追溯，并能够审计所使用的 流程和工具。需求的可追溯性与敏捷实践 做 法 兼 容 ，可 通 过 自 动 化 工 具 链 高 效 实 现 （请参阅 A3部 分 的 需 求 管 理 ，以 及 D2部分 的标准化工具链）。但是，流程和工具的审 计需求可能会限制敏捷技术固有的持续改 进系统。尽管“敏捷” 团队可独立地改善其 流程和工作方法，但汽车团队却必须符合文 件标准的要求，并确保各个团队之间的同步， 这些行动可能拖慢其进度。 何时采用敏捷方法。 尽管需要预定义的待 办事项以及可审计的流程和工具，汽车软 件 团 队 仍 可 即 刻 采 取 大 多 数 敏 捷 实 践 。但 是 这会极大地改变他们的工作方式。 敏 捷 开发 在汽 车 行业 环 境下完 全可行， 且大大提升了效率。但企业必须考虑法规以 及硬软件的基本同步问题 16 代码为王的时代：车企如何掌握卓越软件开发技能 图 7 敏捷方法可推动多个维度上的变革 类别 示例 从 到 团队架构 工作方式、 角色和责任 技术与架构 产品团队设置 每个部门都有独立的团队 兼职人员 全职人员 完全跨部门的团队 持续评估 基于结果的指导/目标 基于活动 基于结果或KPI指标 比照预先定义的项目计划进 行衡量 模块化或解耦化软件架构 单体架构 服务导向 可扩展的IT基础设施 刚性架构；有时IT系统和数据 模型都不完整 精简和可扩展IT基础设施 支持的模块化IT架构 连续发布的节奏 瀑布式，每年3-4次 敏捷方法，每周或每天 决策 层级很多，由高层决策 产品负责人（决定开发什 么）和敏捷团队（决定如 何开发）负责决策 变革示例（非穷尽） 转向敏捷方法时，组织必须对宏观层面的 运营（包括项目组合、资源和项目管理）进 行关键设计的决策。通常，只有先进的开发 部 门 ，例 如 OEM的 “ 软 件 工 厂 ” ，才 采 用 规 模 化的敏捷方法，即所有部门都完全采用新 的工作方式。但是也有例外，例如，一些汽 车先驱企业已实施了规模化敏捷方法，例如 规 模 化 敏 捷 框 架（ SAFe），指 导 其 总 体 研 发工作。 与之相反，各个团队则应始终遵循已建立 的敏捷实践开展业务。例如，跨部门代表 和/或团队成员同址办公以及有时间限制的 迭代都非常重要。