<ol id="ebnk9"></ol> 
軟件正在迅速重塑汽車行業。近年來，業內的四股顛覆浪潮——自動駕駛化、網聯 化、電動化、共享化（ ACE S ）——全都重度依賴先進的軟件。這些領域未來還將迎來更多的顛覆發展。全行業的整車廠（ O EM ）、供應商和新企業無不希望自己能在這條由 軟件驅動的新價值鏈上把握住關鍵的控 制點。
軟件：關鍵的行業轉折點 隨著行業格局改變，缺少軟件能力的車企將面臨重大風險，包括量產（ SO P ）延期和預算超支。它們甚至可能落后于競爭對手 和新入場者，倘若后兩者能以快得多的速 度將新穎得多的產品推向市場的話。更糟的是，軟件問題可能導致大規模召回，或是讓車企無力防范因黑客攻擊而產生的客戶安全風險。
我們的研究顯示，軟件能力強的企業和能力弱的企業之間的差距是顯著的，能力最強的企業報告中公布的產量和質量，比能力墊底的企業高出三到六倍 1 。這一開發效率差距遠大于不同能力的硬件生產商之間可產生的差距。很多車企已認識到強大的軟件開 發能力帶來的各種優勢，也正在采取大刀闊斧的措施改善業績。一些車企計劃在今后幾年提升軟件能力，并將招聘數以千計的軟件工程師；另一些則將重新定義治理模式，建立合作關系，并在全球推廣卓越軟件開發中心。
然而，我們認為這些措施是不夠的，因為只有當車企針對軟件開發更新了基礎運營模式的時候，真正的變革才會到來。根據我們的研究，在那些認為軟件是主要顛覆因素的車企研發領導當中，僅有 40 % 的人覺得自己已為必要的運營變革做好了準備 2 。雖然一些領軍車企已在軟件工程實踐上取得長足進步，但大部分車企仍然遠遠落后于佼佼者。目前車企的問題集中在幾個領域：敏捷實踐、持續集成、自動化測試。
軟件開發轉型的風險如此之大，車企必須對一整套軟件開發方法進行重新思考，包括基礎運營模式等。本文分享了我們通過 與車企、供應商，以及生態圈中其他合作伙伴密切合作，收獲的關鍵理念和洞見。這些洞見還建立在兩項基礎上：一是針對技術專家開展的廣泛訪談，二是利用麥肯錫 S o tt C os t er 專有數據庫進行的大規模對標。
根據我們的研究，在那些認為軟件是主要顛覆因素的車企研發領導當中，僅有 4 0 % 的人覺得自己已為必要的運營變革做好了準備
1
基于麥肯錫的 S o f t C os t er 專有數據庫的信息，該數據庫包含多個行業的 1 4 000 多個軟件開發項目。
2
麥肯錫未來研發調研。
軟件復雜度提高的速度比生產力提高的速度更快
各時期軟件復雜度與生產力的相對增幅，已根據汽車軟件特征做了指數化
4 復雜度
3
2
生產力
1
2010
2020
2 0 2 0
2 03 0
1 2
3
O n d r e j B u rk a c k y ,
J oh a nn e s
De ic h m a nn ,
J a n
P a u l
S t e i n
2 03 0
A u t o m o ti v e s o f twar e
a n d
e l e ct ro n i c s
2 0 3 0 :
M a pp i n g
t h e
s e c t o r ’ s
f u tu r e
l a n d s c a p e
2 0 1 9
7
9
M c K i n s ey . c o m
25
3
3 . 5
6
2
1
1 . 5
4
1
ADA S
25
3 5
11
1 2
1
軟件開發實力位居前 25% 的企業表現出明顯較高的生產力、開發通量和質量
第四四分位
平均水平 1
第一四分位
研發實力處在平均水平和第四四分位上的研發組織在研發業績上的潛在增長
生產力， 每人周的復雜度單位 ¹
開發通量， 每周復雜度單位 1
質量， 殘余設計缺陷
+3.5× +3.0×
224
175
155
–6.0×
100
100
100
65
65
27
1.
平均水平已指數化，基準值 100 。每人周復雜度單位代表每個全職員工的生產力。每周復雜度單位代表整個組織的生產力。資料來源：麥肯錫 SoftCoster 嵌入式軟件項目數據庫
2
第一個維度——開發什么軟件——聚焦的是通過模塊化和解耦的硬 件/ 軟件架構、以用戶為中心的設計，以及需求管理，來降低開發復雜度。其他三個維度所聚焦的，則 是通過提供合適的結構、流程和基礎設施 A.
開發什么軟件：架構、設計及各項要求 在新的運營模式下，企業必須把與軟件相關的開發目標和業務機會轉化為產品、功能和 模塊等層面上的可行架構、產品及投資組合 提高軟件開發的效率。我們從四個維度出發，需求。通過這個流程，企業可以詳細了解能 明確了 11 項最佳實踐，這些做法能幫助車企成功地解決在軟件上面臨的挑戰（圖 3 ）。理想情況下，企業將同時處理好所有維度。
為其創造價值的軟件類型。這個流程還將 助力企業降低架構的復雜度，應用以用戶為中心的設計流程，改善對軟件需求的管理。
圖 3
新的軟件開發運營模式需要對四個關鍵維度做出改變
各維度的最佳實踐
調整組織并建立 確保企業有能力 全球卓越中心 獲取頂尖軟件開 發人才資源，并對其保持吸引力 制定清晰的“自制或外購”策略并建立合作生態圈 實施績效管理 實施大規模敏捷方法
實現硬件與軟件開發之間的解耦 提高測試的自動升級到標準化的先進軟件開發工具鏈 化程度，實現成 熟的持續集成 降低架構的復雜度 的設計 理方式進行調整 應用以用戶為中心 對軟件需求的管 如何開發軟件
C
D
如何促進軟件開發
開發什么軟件
在哪里開發軟
件
B
A
車企必須力爭實現一個理想架構，使之能支持軟硬件之間的解耦，而且具備強大的中間件層次 云平臺
聯網（回傳）
應用層 將圍繞服務重構
用戶界面/用戶體驗/人機界面
•
將根據現代軟件開發的各種做法，在不對基礎硬件做假設的情況下打造應用
•
AI/AA 將通過中間件/數據庫使用專業硬件
應用
人工智能/高級分析
中間件層/操作系統
中間件層次將抽取硬件并將 API 暴露給上層軟件
電氣/電子硬件
•
模塊化的中間件架構
•
API 將定義可供上層軟件使用的復雜的、傳感器
執行器
動力構件
標準化的硬件功能集合
•
標準化的操作系統將協調各類電子及域
汽車
控制單元以及傳感器之間的功能，確?；ネㄐ?/p>
A 1 .
AP I 4
O E M
4
而且企業也還沒有明確這些系統的確切研發重點和功能。
通過遵循明確的架構原理和指導原則，企業能夠有效地應對更高的系統和軟件復雜度。硬 件/ 軟件解耦允許多個實體參與模塊化開發。反過來，由于代碼共性增多，模塊 化軟件構建技術可增加對代碼的重復利用，并減少需要的代碼總量。很多企業已著手引入軟件產品線工程（ PL E ）方法，以增加重復利用，同時處理產品變更。這個方法能讓一個軟件服務于多個產品、產品變體和產品系列，還可以兼容不同的硬件版本。軟件 PL E顯著降低了開發和測試工作的難度，這兩項工作都只需進行一次。
換句話說，促使硬件從軟件上解耦，可促使硬件實現進一步的 “ 自主化 ” ，硬件提供了標準的計算、存儲、輸入 / 輸出和電源功能，而軟件則定義了終端用戶功能。對于需要標準性能的應用，不同的軟件功能可以利用虛擬化和容器化技術在相同的硬件上運行，如有必要，還可以動態地分布到其他硬件（例如在硬件發生故障的情況下）。對于 ADA S等存在實時性能要求的應用，針對特定硬件的軟件開發工作對于實現最優效率仍然至關重要。
以服務為導向的架構。該架構應當遵循各
項服務的定義，反過來，這些定義則應將業務或用戶需求代碼化。以服務為導向的架 構設計既能讓企業實現各核心要素的標準化，也能讓各部門和各業務單位之間的接口實現標準化。企業還應對單項硬件和軟件要素應用標準化的設計，以便在不影響性能的情況下，針對其他支持設備和功能規?；嘏渲觅Y源，如計算和存儲資源。以服務為導向的架構對 O E M 尤為重要。實現從車輛 到云端的迅速連接，不僅將提升車企各種車型的長期價值，也將推動車企能力的迅速更新和升級。
A2 . 應用以用戶為中心的設計技術 綜觀各行業，專注于開發以用戶為中心的 強大設計、創造最優用戶體驗（ UX ）的企業，將實現更高的財務收益 4 。隨著 ACE S 概念 持續受到追捧，軟件定義的汽車成為常態，對于 O EM 的整體競爭力而言，這些特征將 會變得越來越重要。即便是頂尖企業也需要做改進，原因在于汽車行業在設計良好的軟件用戶體驗、提供最優的客戶價值等方面仍然落后于其他行業。
按照最佳實踐奉行的設計原則， O EM 應當與終端用戶合作對新軟件進行迭代，無論 交付前后都應如此。車企也應當采用新的 交付模式，以便以每周或每月一次的頻率
對軟件進行更新或添加，從而實現持續的優化。這些工作的周期相比經典軟件開發工作短了許多，后者通常需要幾年時間。新的交付模式還有一個好處，它可以讓 O EM
與客戶實現持續的直接接觸，從而使 O EM持續收到反饋，而這些反饋有助于它們優 化軟件需求，提供積極的用戶體驗提升。當 O EM 依賴硬件實現升級時，此類互動是不可能實現的，因為接觸只會在通過經銷商網絡進行的一次性銷售或市場調研期間發生一次。為了達到這個目標狀態， O EM 需要落實必要的先決條件，例如配套的軟件和電子架構，以及可實現云端更新的工具鏈。
希望成為用戶體驗領導者的 O EM 必須對自己的數據善加利用。隨著車載軟件和傳感器數量不斷增多， O EM 如今能夠獲取大量的數據，以了解客戶如何使用汽車。
O EM可以挖掘此類數據，識別對客戶最重要的
4
基于針對業務發展的麥肯錫設計指數評分的相關分析。如欲了解更多信息，參閱 B e ne dic t
S he pp a r d,
H u go
Sa rr a z i n ,
G a r e n
Kou y ou m j i a n 和 F a b r icio
D or e 合撰的文章《設計的商業價值》（ T h e
b u s i n e ss
v a l u e
o f
d e s i g n ）,
M cKi n s ey
Q u a r t e r l y ,
20 1 8 年 10 月 25 日 ,
M cKi n s ey . c o m 。
成功的軟件開發需要根據客戶反饋對需求進行持續的調整和修正
特性，以及配置超標或根本沒人用的特性。重關注價值創造，并能在軟件開發期間設定 這些洞見將為明確配置和未來型號需求提供參考。
最終，新的交付模式將給開發效率帶來積極影響。鑒于車企將對軟件進行頻繁的變更、調適、修改，它們不需要從項目一開始的時候就確定極端詳細的需求。由于用在定義需求上的時間縮短了，產品面市時間也將縮短。
A3 . 調整軟件需求管理 歷史上，汽車行業曾是在集成的價值鏈上管理各項需求的領導者。但是， O E M 主要關注的是硬件需求，而且它們的既有流程并未 針對軟件調適到最優狀態。隨著車載軟件成為重要的差異化因素， O EM 必須采用新 的做法來管理需求。管理需求的變更尤為重要，因為我們的研究顯示，對汽車軟件的種種需求已經變得過于細化，以至于拖慢了開發進程。
按照最佳實踐， O EM 應當基于客戶價值對各項需求進行聚類。第一個層級應當主要 合理的優先事項。隨著車企將各種需求劃 分到多個層級，以下工作能夠起到幫助作用。
將需求與戰略和客戶價值掛鉤。成功的軟件開發需要根據客戶反饋對需求進行持續的調整和修正。雖然企業在初期就應根據其商業戰略和目標定義軟件需求，但它們也應根據客戶反饋和開發進度周期性地做出調整。
確保端到端的可追溯性。通過在整條價值鏈上對需求進行密切追蹤，車企可避免做無用功，加快開發進程。但是，只有當車企的開發流程和工具鏈能夠從定義到驗收全過程實現需求的嚴格可追溯性時，車企才能做到這一點。這種明確性有助于車企了解清楚各項需求（客戶觀點）、需要的功能 （開發者觀點），以及各項交付成果（測試者觀點）。
車企必須分四步實現端到端的追蹤，這要么需要用到少數幾種高度集成的工具，要么用到四種專業工具，并搭配相應的接口。這 包括面向客戶的需求（通常被表述為用例）。些步驟是：
另一個層級主要包括技術或實施方面的需 求（通常被表述為賦能因素），比如某個特性所需的內存。這個方法可以保證 O EM 著 — 對需求進行追蹤，從特性到構件對這些需求進行細化和具體說明
—
管理待辦清單，這項工作有助于各團隊在軟件開發沖刺時管理好各項需求的覆蓋范圍（與下一個步驟密切相關）
— 追蹤代碼變更，包括對代辦項目的更新 — 通過開展測試案例對需求進行驗證，并檢查測試案例的通過 - 失敗狀態 利用工具將各項需求關聯起來，用戶能
夠高效地在項目的每個階段實施變更，從而滿足監管對端到端可追溯性的各種要求 （例如， A S P I CE 或 U N EC E 5 ）。利用這個方法，我們能迅速弄清楚哪些變更影響到了哪些工作成果。當遵循敏捷流程開發軟件時，此類需求變更是正常的，也是可取的 （如基于客戶反饋的變更），企業應當利用各種流程和工具對它們予以支持。在軟件開發工作的傳統瀑布式流程當中，此類變更是罕見的，而且通常也預見不到。
避免過度細化，創建明確的需求類別。企業可以建立一些最佳實踐，對軟件需求進行具體說明和分類，并擬定精簡的測試辦法。一份優秀的需求說明應當是清晰明確的，而且允許測試工作不受其他需求影響。與組合管理一樣，企業應當對不同類型的需求加以區分。常見的需求類別包括法律監管類、安全類、戰略類，以及必要改進、客戶價值、成本賦能等因素。另外，企業還必須確保，凡是需求之間的依存關系都應當是透明的。很多企業已經將這些規則融入到自己的軟件開發流程和培訓課程之中，以便優化對需 求的處理和評審過程。
開展優先排序，進行持續調整。企業既應根據具體的商業論證和戰略目標，也應根據在整個開發過程中（例如在測試過程中）獲 得的客戶反饋和和經驗對軟件需...
<ol id="ebnk9"></ol>