（報告出品方/作者：麥肯錫）
報告摘要：
軟件正在迅速重塑汽車行業(yè)。近年來，業(yè)內(nèi)的四股顛覆浪潮——自動駕駛化、網(wǎng)聯(lián) 化、電動化、共享化（ACES）——全都重度 依賴先進(jìn)的軟件。這些領(lǐng)域未來還將迎來 更多的顛覆發(fā)展。全行業(yè)的整車廠（OEM）、 供應(yīng)商和新企業(yè)無不希望自己能在這條由 軟件驅(qū)動的新價值鏈上把握住關(guān)鍵的控 制點。
軟件：關(guān)鍵的行業(yè)轉(zhuǎn)折點
隨著行業(yè)格局改變，缺少軟件能力的車企 將面臨重大風(fēng)險，包括量產(chǎn)（SOP）延期和 預(yù)算超支。它們甚至可能落后于競爭對手 和新入場者，倘若后兩者能以快得多的速 度將新穎得多的產(chǎn)品推向市場的話。更糟的 是，軟件問題可能導(dǎo)致大規(guī)模召回，或是讓 車企無力防范因黑客攻擊而產(chǎn)生的客戶安 全風(fēng)險。
我們的研究顯示，軟件能力強的企業(yè)和能力 弱的企業(yè)之間的差距是顯著的，能力最強 的企業(yè)報告中公布的產(chǎn)量和質(zhì)量，比能力墊 底的企業(yè)高出三到六倍1。這一開發(fā)效率差 距遠(yuǎn)大于不同能力的硬件生產(chǎn)商之間可產(chǎn)生 的差距。很多車企已認(rèn)識到強大的軟件開 發(fā)能力帶來的各種優(yōu)勢，也正在采取大刀 闊斧的措施改善業(yè)績。一些車企計劃在今 后幾年提升軟件能力，并將招聘數(shù)以千計 的軟件工程師；另一些則將重新定義治理 模式，建立合作關(guān)系，并在全球推廣卓越軟 件開發(fā)中心。
然而，我們認(rèn)為這些措施是不夠的，因為只 有當(dāng)車企針對軟件開發(fā)更新了基礎(chǔ)運營模 式的時候，真正的變革才會到來。根據(jù)我們 的研究，在那些認(rèn)為軟件是主要顛覆因素 的車企研發(fā)領(lǐng)導(dǎo)當(dāng)中，僅有40%的人覺得自 己已為必要的運營變革做好了準(zhǔn)備。雖然 一些領(lǐng)軍車企已在軟件工程實踐上取得長 足進(jìn)步，但大部分車企仍然遠(yuǎn)遠(yuǎn)落后于佼 佼者。目前車企的問題集中在幾個領(lǐng)域：敏 捷實踐、持續(xù)集成、自動化測試。
軟件開發(fā)轉(zhuǎn)型的風(fēng)險如此之大，車企必須 對一整套軟件開發(fā)方法進(jìn)行重新思考，包 括基礎(chǔ)運營模式等。本文分享了我們通過 與車企、供應(yīng)商，以及生態(tài)圈中其他合作伙 伴密切合作，收獲的關(guān)鍵理念和洞見。這 些洞見還建立在兩項基礎(chǔ)上：一是針對技 術(shù)專家開展的廣泛訪談，二是利用麥肯錫 SottCoster專有數(shù)據(jù)庫進(jìn)行的大規(guī)模對標(biāo)。
用數(shù)字說話：軟件的重要性是如何后來居上的
苦千趨勢凸顯了汽車軟件與日劇增的重要性。第一個趨勢與軟件和電氣/電子市場的迅速擴(kuò)張有關(guān)，2020年到2030年，這個市場預(yù)計將實現(xiàn)12%的年復(fù)合增長率——比普通汽車銷量的預(yù)期增速高出三倍多。有幾個領(lǐng)域增長最為強勁，包括軟件功能(年復(fù) 合增長率達(dá)11%)以及集成測試(年復(fù)合增長卓為12%) 。
復(fù)雜度不斷升高,但開發(fā)效率進(jìn)步緩慢
無論功能層面還是架構(gòu)層面,汽車軟件的復(fù)雜度都在升高,而開發(fā)工作的效率卻沒有以同等速率跟上。我們的研究顯示，軟件復(fù)雜度在過去十年已增加到原來的4倍,而軟件開發(fā)效率只提升了1到1.5倍。這個問題在變得日益復(fù)雜的大型模塊中最為嚴(yán)重，如信息娛樂系統(tǒng)和高級駕駛輔助系統(tǒng)(ADAS)。相比傳統(tǒng)的深度嵌入式軟件，開發(fā)這些模塊的效率大約低25%到35%。
這個日漸擴(kuò)大的差距可能會影響車企未來的成功。車企需要投入更多資源開發(fā)軟件，并在軟件生命周期中對其進(jìn)行維護(hù),這可能會削弱自身在創(chuàng)新和應(yīng)對競爭對手方面的能力。訪談期間，有位企業(yè)領(lǐng)導(dǎo)注意到，如果復(fù)雜度持續(xù)升高，而效率原地踏步，那么僅軟件維護(hù)這一項，就會迅速耗盡所有的軟件開發(fā)資源,不會給創(chuàng)新留下絲毫余裕。最終，復(fù)雜度和效率之間的差距將削弱成本競爭力,造成嚴(yán)重的財務(wù)和商譽問題。
顯而易見，軟件開發(fā)實力排在前25%的企業(yè)，相比實力墊底者，效率高出3倍，產(chǎn)量高出3.5倍,質(zhì)量好上6倍。因此，它們的產(chǎn)品面市時間更短，軟件功能每提升一個檔次所需的開發(fā)成本也更低。
硬件方面，實力最強和最弱的企業(yè)在業(yè)績上的差距相對不那么明顯，因此，在這個領(lǐng)域追求差異化的機會也相應(yīng)更少。
降低復(fù)雜度，同時提升效率
為了在這個迅速變化的環(huán)境中取得成功，企業(yè)應(yīng)當(dāng)通過減少開發(fā)和維護(hù)軟件需要做的工作，以求最大限度地降低復(fù)雜度。這個策略涉及限制各平臺和生命周期階段的功能和特性的版本數(shù)量，同時，企業(yè)必須加大對構(gòu)件的重復(fù)利用。至于開發(fā)效率，企業(yè)應(yīng)當(dāng)嘗試在軟件開發(fā)速度上向數(shù)字原生企業(yè)看齊，以提升開發(fā)效率。由于軟件創(chuàng)新的整體水平不會下降，企業(yè)還必須提高其軟件開發(fā)和維護(hù)的產(chǎn)出量，以便交付在市場上取得成功所需的產(chǎn)品和服務(wù)。
降低復(fù)雜度和提高效率需要一個新的軟件運營模式,該模式著重考量四個維度:
（1）開發(fā)什么軟件,包括架構(gòu)、設(shè)計以及各項要求；
（2）在哪里開發(fā)軟件,由企業(yè)內(nèi)部哪個部門開發(fā),包括涉及到的地點人才及合作關(guān)系；
（3）采取什么方式開發(fā)軟件，這個維度考量的是開發(fā)工作的方法論,如大規(guī)模敏捷開發(fā)，或是開發(fā)和測試流程的改變；
（4）采取什么方式推動軟件開發(fā)包括績效管理和工具鏈基礎(chǔ)架構(gòu)。
第一個維度——開發(fā)什么軟件——聚焦的 是通過模塊化和解耦的硬件/軟件架構(gòu)、以 用戶為中心的設(shè)計，以及需求管理，來降低 開發(fā)復(fù)雜度。其他三個維度所聚焦的，則 是通過提供合適的結(jié)構(gòu)、流程和基礎(chǔ)設(shè)施 提高軟件開發(fā)的效率。我們從四個維度出發(fā)， 明確了11項最佳實踐，這些做法能幫助車企 成功地解決在軟件上面臨的挑戰(zhàn)。理 想情況下，企業(yè)將同時處理好所有維度。
A. 開發(fā)什么軟件：架構(gòu)、設(shè)計及各 項要求
在新的運營模式下，企業(yè)必須把與軟件相關(guān) 的開發(fā)目標(biāo)和業(yè)務(wù)機會轉(zhuǎn)化為產(chǎn)品、功能和 模塊等層面上的可行架構(gòu)、產(chǎn)品及投資組合 需求。通過這個流程，企業(yè)可以詳細(xì)了解能 為其創(chuàng)造價值的軟件類型。這個流程還將 助力企業(yè)降低架構(gòu)的復(fù)雜度，應(yīng)用以用戶為 中心的設(shè)計流程，改善對軟件需求的管理。
A1.降低架構(gòu)的復(fù)雜度
根據(jù)我們的研究，如果汽車軟件的模塊化程度不夠，就會使設(shè)計復(fù)雜度提高,也會提高項目的整體難度。另外，汽車軟件的架構(gòu)構(gòu)件邊界往往是不理想的,這有可能導(dǎo)致更多的相互依存關(guān)系，使開發(fā)人員在添加新功能時必須修改的構(gòu)件數(shù)量成倍增加。這些依存關(guān)系還可能造成一個后果:檢測到缺陷時，需要更長的時間和更高的專業(yè)水平來追蹤特定軟件模塊和開發(fā)團(tuán)隊的錯誤。
為解決此類問題，0EM必須大幅提高標(biāo)準(zhǔn)化和模塊化程度，這樣就能實現(xiàn)軟件在各平臺之間的可擴(kuò)展性，使軟件復(fù)雜度維持在可以管理的水平。車企還必須重視兩項工作，一是促成軟硬件之間的解耦,二是應(yīng)用服務(wù)導(dǎo)向型設(shè)計。
解耦架構(gòu)。車企可以引入一個強大的中間件層次，利用它提取硬件能力,并通過上層使用的標(biāo)準(zhǔn)化應(yīng)用程序接口(API)使這些能力對軟件功能開放。這種軟件架構(gòu)可以利用各平臺之間的共性，降低設(shè)計上的復(fù)雜度，不必多次重復(fù)開發(fā)相同的軟件。
除了解耦，車企還應(yīng)當(dāng)創(chuàng)建一系列標(biāo)準(zhǔn)化的操作系統(tǒng)，利用它們支持各構(gòu)件之間的協(xié)調(diào)，確保互通性。很多企業(yè)已宣布將要開發(fā)此類操作系統(tǒng)，但目前尚不存在統(tǒng)一的方法。
而且企業(yè)也還沒有明確這些系統(tǒng)的確切研 發(fā)重點和功能。
通過遵循明確的架構(gòu)原理和指導(dǎo)原則，企業(yè)能夠有效地應(yīng)對更高的系統(tǒng)和軟件復(fù)雜 度。硬件/軟件解耦允許多個實體參與模塊 化開發(fā)。反過來，由于代碼共性增多，模塊 化軟件構(gòu)建技術(shù)可增加對代碼的重復(fù)利用， 并減少需要的代碼總量。很多企業(yè)已著手引 入軟件產(chǎn)品線工程（PLE）方法，以增加重復(fù) 利用，同時處理產(chǎn)品變更。這個方法能讓一 個軟件服務(wù)于多個產(chǎn)品、產(chǎn)品變體和產(chǎn)品系 列，還可以兼容不同的硬件版本。軟件PLE 顯著降低了開發(fā)和測試工作的難度，這兩項 工作都只需進(jìn)行一次。
換句話說，促使硬件從軟件上解耦，可促使 硬件實現(xiàn)進(jìn)一步的“自主化”，硬件提供了標(biāo) 準(zhǔn)的計算、存儲、輸入/輸出和電源功能，而 軟件則定義了終端用戶功能。對于需要標(biāo)準(zhǔn) 性能的應(yīng)用，不同的軟件功能可以利用虛擬 化和容器化技術(shù)在相同的硬件上運行，如 有必要，還可以動態(tài)地分布到其他硬件（例 如在硬件發(fā)生故障的情況下）。對于ADAS 等存在實時性能要求的應(yīng)用，針對特定硬件 的軟件開發(fā)工作對于實現(xiàn)最優(yōu)效率仍然至 關(guān)重要。
以服務(wù)為導(dǎo)向的架構(gòu)。該架構(gòu)應(yīng)當(dāng)遵循各 項服務(wù)的定義，反過來，這些定義則應(yīng)將業(yè) 務(wù)或用戶需求代碼化。以服務(wù)為導(dǎo)向的架 構(gòu)設(shè)計既能讓企業(yè)實現(xiàn)各核心要素的標(biāo)準(zhǔn) 化，也能讓各部門和各業(yè)務(wù)單位之間的接口 實現(xiàn)標(biāo)準(zhǔn)化。企業(yè)還應(yīng)對單項硬件和軟件 要素應(yīng)用標(biāo)準(zhǔn)化的設(shè)計，以便在不影響性能 的情況下，針對其他支持設(shè)備和功能規(guī)模化地配置資源，如計算和存儲資源。以服務(wù)為 導(dǎo)向的架構(gòu)對OEM尤為重要。實現(xiàn)從車輛到云端的迅速連接，不僅將提升車企各種 車型的長期價值，也將推動車企能力的迅 速更新和升級。
A2.應(yīng)用以用戶為中心的設(shè)計技術(shù)
綜觀各行業(yè)，專注于開發(fā)以用戶為中心的 強大設(shè)計、創(chuàng)造最優(yōu)用戶體驗（UX）的企業(yè)， 將實現(xiàn)更高的財務(wù)收益4。隨著ACES概念 持續(xù)受到追捧，軟件定義的汽車成為常態(tài)， 對于OEM的整體競爭力而言，這些特征將 會變得越來越重要。即便是頂尖企業(yè)也需 要做改進(jìn)，原因在于汽車行業(yè)在設(shè)計良好 的軟件用戶體驗、提供最優(yōu)的客戶價值等方 面仍然落后于其他行業(yè)。
按照最佳實踐奉行的設(shè)計原則，OEM應(yīng)當(dāng) 與終端用戶合作對新軟件進(jìn)行迭代，無論 交付前后都應(yīng)如此。車企也應(yīng)當(dāng)采用新的 交付模式，以便以每周或每月一次的頻率 對軟件進(jìn)行更新或添加，從而實現(xiàn)持續(xù)的 優(yōu)化。這些工作的周期相比經(jīng)典軟件開發(fā) 工作短了許多，后者通常需要幾年時間。新 的交付模式還有一個好處，它可以讓OEM 與客戶實現(xiàn)持續(xù)的直接接觸，從而使OEM 持續(xù)收到反饋，而這些反饋有助于它們優(yōu) 化軟件需求，提供積極的用戶體驗提升。當(dāng) OEM依賴硬件實現(xiàn)升級時，此類互動是不 可能實現(xiàn)的，因為接觸只會在通過經(jīng)銷商網(wǎng) 絡(luò)進(jìn)行的一次性銷售或市場調(diào)研期間發(fā)生 一次。為了達(dá)到這個目標(biāo)狀態(tài)，OEM需要落 實必要的先決條件，例如配套的軟件和電 子架構(gòu)，以及可實現(xiàn)云端更新的工具鏈。
希望成為用戶體驗領(lǐng)導(dǎo)者的OEM必須對自 己的數(shù)據(jù)善加利用。隨著車載軟件和傳感 器數(shù)量不斷增多，OEM如今能夠獲取大量 的數(shù)據(jù)，以了解客戶如何使用汽車。OEM 可以挖掘此類數(shù)據(jù)，識別對客戶最重要的特性，以及配置超標(biāo)或根本沒人用的特性。 這些洞見將為明確配置和未來型號需求提 供參考。
最終，新的交付模式將給開發(fā)效率帶來積 極影響。鑒于車企將對軟件進(jìn)行頻繁的變 更、調(diào)適、修改，它們不需要從項目一開始 的時候就確定極端詳細(xì)的需求。由于用在 定義需求上的時間縮短了，產(chǎn)品面市時間也 將縮短。
A3.調(diào)整軟件需求管理
歷史上，汽車行業(yè)曾是在集成的價值鏈上管 理各項需求的領(lǐng)導(dǎo)者。但是，OEM主要關(guān)注 的是硬件需求，而且它們的既有流程并未 針對軟件調(diào)適到最優(yōu)狀態(tài)。隨著車載軟件 成為重要的差異化因素，OEM必須采用新 的做法來管理需求。管理需求的變更尤為重 要，因為我們的研究顯示，對汽車軟件的種 種需求已經(jīng)變得過于細(xì)化，以至于拖慢了開 發(fā)進(jìn)程。
按照最佳實踐，OEM應(yīng)當(dāng)基于客戶價值對 各項需求進(jìn)行聚類。第一個層級應(yīng)當(dāng)主要 包括面向客戶的需求（通常被表述為用例）。 另一個層級主要包括技術(shù)或?qū)嵤┓矫娴男?求（通常被表述為賦能因素），比如某個特 性所需的內(nèi)存。這個方法可以保證OEM著重關(guān)注價值創(chuàng)造，并能在軟件開發(fā)期間設(shè)定 合理的優(yōu)先事項。隨著車企將各種需求劃分到多個層級，以下工作能夠起到幫助作用。
將需求與戰(zhàn)略和客戶價值掛鉤。成功的軟 件開發(fā)需要根據(jù)客戶反饋對需求進(jìn)行持續(xù) 的調(diào)整和修正。雖然企業(yè)在初期就應(yīng)根據(jù) 其商業(yè)戰(zhàn)略和目標(biāo)定義軟件需求，但它們也 應(yīng)根據(jù)客戶反饋和開發(fā)進(jìn)度周期性地做出 調(diào)整。
確保端到端的可追溯性。通過在整條價值 鏈上對需求進(jìn)行密切追蹤，車企可避免做 無用功，加快開發(fā)進(jìn)程。但是，只有當(dāng)車企 的開發(fā)流程和工具鏈能夠從定義到驗收全 過程實現(xiàn)需求的嚴(yán)格可追溯性時，車企才能 做到這一點。這種明確性有助于車企了解清楚各項需求（客戶觀點）、需要的功能 （開發(fā)者觀點），以及各項交付成果（測試 者觀點）。
車企必須分四步實現(xiàn)端到端的追蹤，這要 么需要用到少數(shù)幾種高度集成的工具，要么 用到四種專業(yè)工具，并搭配相應(yīng)的接口。這 些步驟是：
（1）對需求進(jìn)行追蹤，從特性到構(gòu)件對這些 需求進(jìn)行細(xì)化和具體說明；
（2）管理待辦清單，這項工作有助于各團(tuán)隊 在軟件開發(fā)沖刺時管理好各項需求的覆蓋范圍（與下一個步驟密切相關(guān)）；
（3）追蹤代碼變更，包括對代辦項目的更新；
（4）通過開展測試案例對需求進(jìn)行驗證，并 檢查測試案例的通過-失敗狀態(tài)。
利用工具將各項需求關(guān)聯(lián)起來，用戶能 夠高效地在項目的每個階段實施變更，從 而滿足監(jiān)管對端到端可追溯性的各種要求 （例如，ASPICE或UNECE5）。利用這個方 法，我們能迅速弄清楚哪些變更影響到了 哪些工作成果。當(dāng)遵循敏捷流程開發(fā)軟件 時，此類需求變更是正常的，也是可取的 （如基于客戶反饋的變更），企業(yè)應(yīng)當(dāng)利用各 種流程和工具對它們予以支持。在軟件開 發(fā)工作的傳統(tǒng)瀑布式流程當(dāng)中，此類變更是 罕見的，而且通常也預(yù)見不到。
避免過度細(xì)化，創(chuàng)建明確的需求類別。企業(yè) 可以建立一些最佳實踐，對軟件需求進(jìn)行具 體說明和分類，并擬定精簡的測試辦法。一 份優(yōu)秀的需求說明應(yīng)當(dāng)是清晰明確的，而且 允許測試工作不受其他需求影響。與組合管 理一樣，企業(yè)應(yīng)當(dāng)對不同類型的需求加以區(qū) 分。常見的需求類別包括法律監(jiān)管類、安全 類、戰(zhàn)略類，以及必要改進(jìn)、客戶價值、成 本賦能等因素。另外，企業(yè)還必須確保，凡 是需求之間的依存關(guān)系都應(yīng)當(dāng)是透明的。很 多企業(yè)已經(jīng)將這些規(guī)則融入到自己的軟件 開發(fā)流程和培訓(xùn)課程之中，以便優(yōu)化對需 求的處理和評審過程。
開展優(yōu)先排序，進(jìn)行持續(xù)調(diào)整。企業(yè)既應(yīng)根 據(jù)具體的商業(yè)論證和戰(zhàn)略目標(biāo)，也應(yīng)根據(jù) 在整個開發(fā)過程中（例如在測試過程中）獲得的客戶反饋和和經(jīng)驗對軟件需求進(jìn)行評 估和優(yōu)先排序。企業(yè)應(yīng)當(dāng)定期對需求進(jìn)行 重新評估，并在一份公開透明的待辦清單中 對其加以維護(hù)。
很多企業(yè)任命了產(chǎn)品負(fù)責(zé)人，這些人擁有寬 廣的知識面，可以做出產(chǎn)品功能取舍，組建 跨職能團(tuán)隊，并確保各職能部門就各項需 求達(dá)成共識。根據(jù)最佳實踐，產(chǎn)品負(fù)責(zé)人還 需要負(fù)責(zé)遵循最佳實踐，并對需求和用例的 待辦清單進(jìn)行維護(hù)。
B. 在哪里開發(fā)軟件：組織、地點、人 才與合作伙伴
大部分車企缺乏處理大規(guī)模軟件開發(fā)工作 所需的組織基礎(chǔ)。它們面臨多重挑戰(zhàn)，有的 在執(zhí)行層面極少或沒有劃分出明確的職責(zé)， 有的沒有足夠的軟件工程師和架構(gòu)師。憑借 明確軟件開發(fā)工作所需的組織架構(gòu)、地點 和人才策略、“自研或外包”策略，以及所需 的合作關(guān)系生態(tài)圈，新的運營模式將會解決 這些問題。
B1. 調(diào)整組織，建立全球卓越軟件中心
在組織層面，大部分車企還沒有做好準(zhǔn)備， 無力應(yīng)對致使軟件重要性攀升的ACES趨勢。 例如，OEM就軟件問題進(jìn)行決策時通常比 較緩慢，很多車企對于車載平臺的軟件、電 子設(shè)備策略，以及相關(guān)預(yù)算的主要權(quán)責(zé)尚 無明確的劃分。為了在新形勢下保持競爭力， 車企必須重新思考其組織設(shè)置。此項工作 的一個主要目標(biāo)，是要在端到端開發(fā)流程期 間減少在架構(gòu)定義、需求定義以及開發(fā)這 幾項工作之中的接口。通過增進(jìn)各團(tuán)隊在各 階段的共識和協(xié)作，車企可以避免做多余 的工作，并優(yōu)化各種既有的和全新的能力。
很多車企已成立一個集中化的職能部門，依 靠該部門負(fù)責(zé)軟件架構(gòu)設(shè)計，并分享已固化 的最佳實踐。例如，一家OEM最近成立了一 個中央職能部門，該部門聚集了5000名軟 件開發(fā)人員。然而，大多數(shù)情況下，OEM對 軟件開發(fā)仍采取較為去中心化的方法。
幾種組織類型。嘗試改進(jìn)軟件開發(fā)工作 時，OEM可以采用幾種常見的組織類型。 對于每家企業(yè)而言，能反映公司優(yōu)先事項 的選項，就是最佳選項，這些優(yōu)先事項包 括加快決策、減少接口、明確職責(zé)等。更重 要的是，企業(yè)必須開展專項工作，以便協(xié) 調(diào)來自不同組織職能的要求，這些職能包 括研發(fā)、采購、生產(chǎn)、銷售和后市場等部門， 這是因為這些職能對軟件的需求和生命周 期變更可能彼此存在沖突。此舉將確保無 縫的用戶接口和高效的開發(fā)流程。除了重塑 組織，車企還必須對彌合軟硬件團(tuán)隊文化 差距和協(xié)調(diào)工作流程進(jìn)行大量投入以開展 相應(yīng)行動。這些工作需要持續(xù)的變革管理， 但它們將有助于車企成為軟件開發(fā)重鎮(zhèn)。
在定義組織架構(gòu)時，汽車軟件開發(fā)單位將 對職能角色、產(chǎn)品或項目，以及技術(shù)構(gòu)建理 想圖景。不過，這個組織架構(gòu)一般會從前 述的幾個維度中選擇一個作為核心。
在此可參考一個強調(diào)職能角色的組織架構(gòu)。 在這種模式下，企業(yè)將從軟件職能組織抽 調(diào)個體成員，派往針對特定產(chǎn)品或平臺的 項目。產(chǎn)品和技術(shù)將通過面向各職能單位 的間接、“虛線式”的匯報架構(gòu)得到體現(xiàn)。這 種架構(gòu)為企業(yè)賦予了最大的靈活性，因為它 們不需要為了適應(yīng)產(chǎn)品/項目和技術(shù)方面的 額外要求而重塑組織。然而，這種架構(gòu)之下 的開發(fā)效率可能不是最佳的，這會使成立 跨部門職能變得更有必要，如項目管理、架 構(gòu)和人員配置部門。
在第二種類型中，組織架構(gòu)側(cè)重的是項目， 諸如針對特定客戶、車系、車型乃至平臺的 項目。這種類型可利用“虛線式”匯報條線和 成熟流程將產(chǎn)品和技術(shù)這兩個維度聯(lián)系起 來。這種類型使得客戶和終端產(chǎn)品成為組 織的首要焦點。從不利方面來看， 它提高了冗余工作的風(fēng)險，也在不同的產(chǎn)品或項目 團(tuán)隊之間造成了各種障礙，這可能對技術(shù) 移交形成干擾。強大的平臺和架構(gòu)有助于 緩解這些風(fēng)險。
在第三種類型中，組織架構(gòu)側(cè)重的是技術(shù) 和專業(yè)領(lǐng)域，如網(wǎng)絡(luò)、人機界面，或是后端。 在這種模式下，企業(yè)從技術(shù)部門抽調(diào)個體 成員派往具體產(chǎn)品的項目。通過虛線匯報 和成熟的工作流程，這個方法能實現(xiàn)對技 術(shù)和職能這兩個維度的聚焦。雖然這個模 式有助于養(yǎng)成深厚的技術(shù)和專長領(lǐng)域，但 它在項目范圍、需求、規(guī)格方面的靈活性很 差，即使這幾方面在項目期間發(fā)生變化時也 是如此。在開發(fā)和維護(hù)多種產(chǎn)品時，企業(yè)通 常會采用這個類型。
B2. 獲得并吸引頂尖人才，開展內(nèi)部能力 建設(shè)
雖然車企必須在諸多方面表現(xiàn)優(yōu)異才能贏 得這場軟件競賽，但吸引和留住頂尖人才很 可能才是最重要的維度。
大部分OEM已將軟件開發(fā)工作大量外包并 依賴戰(zhàn)略合作伙伴關(guān)系。ACES趨勢極大 地提高了軟件的重要性，即便軟件開發(fā)效 率有迎來幾番增長的潛力，2030年前對于 軟件工程師的需求仍可能增加三到四倍。由 于汽車行業(yè)正在與科技企業(yè)以及其他行業(yè) 正面競爭軟件人才，車企需要采取較為大刀 闊斧的舉措才能改善頂級開發(fā)人員的招募 工作。否則，不斷擴(kuò)大的人才缺口還將繼續(xù) 擴(kuò)大。
汽車軟件人才的招聘和挽留計劃應(yīng)當(dāng)側(cè)重 于實現(xiàn)差異化。根據(jù)我們的對標(biāo)分析結(jié)果，相比只具備同質(zhì)化經(jīng)驗的團(tuán)隊，具備多樣 經(jīng)驗的團(tuán)隊在開發(fā)效率方面的績效要高出 兩位數(shù)的百分比。企業(yè)可以通過開展以下幾 項工作改善人才招募現(xiàn)狀， 要加大對全球軟件開發(fā)人才資源的利用。 綜合選址策略有助于企業(yè)擴(kuò)展其軟件開發(fā) 活動、構(gòu)建相關(guān)能力并提升產(chǎn)能，同時確保 成本可控。而這也有助于企業(yè)爭奪頂級人 才。一些創(chuàng)新企業(yè)已經(jīng)在數(shù)字人才熱點地區(qū) 建立了新的汽車工程中心，例如自動駕駛中 心。不過，大多數(shù)傳統(tǒng)型企業(yè)在很大程度上 還是保留了其歷史足跡和硬件中心，但這可 能使其吸引和留住軟件人才的努力變得復(fù) 雜化。如果這些企業(yè)在關(guān)鍵區(qū)域的多個地 點開展業(yè)務(wù)的話，就可以從附近的大學(xué)和 其他教育機構(gòu)吸納人才。為加強聯(lián)系，這些 企業(yè)可以與大學(xué)合作開展訪學(xué)實習(xí)計劃，使 其能夠接觸到應(yīng)屆畢業(yè)生和其他專業(yè)技能 人才。
盡管全球足跡可帶來諸多好處，但也需要 合適的運營模式，才能避免遠(yuǎn)程和/或分布式工作的普遍問題。例如，研究表明，開發(fā) 項目每增加一個新站點，軟件開發(fā)效率平均 會下降約10%。
使企業(yè)對軟件人才更具吸引力。我們的研 究表明，薪酬、職業(yè)發(fā)展機會、工作類型和 企業(yè)文化是留住軟件工程師的首要因素。目 前，車企在上述這些方面均落后于科技企 業(yè)。為彌合差距，前者必須針對所有重要的 影響因素制定獨特且有針對性的雇主價值 主張，不能再簡單地固守傳統(tǒng)福利，如就業(yè) 保障和企業(yè)配車等。
鼓勵內(nèi)部能力建設(shè)。一個合理的做法是，盡 可能重新培訓(xùn)目前以硬件為主的員工，讓其 在技能升級后承擔(dān)軟件相關(guān)職責(zé)。例如，企 業(yè)可以培訓(xùn)硬件項目經(jīng)理來監(jiān)督軟件項目。 但是，只有當(dāng)企業(yè)在軟件專業(yè)人員和經(jīng)過 再培訓(xùn)的硬件專家之間保持良好的平衡時， 這種做法才行之有效。這個平衡視具體企 業(yè)情況可能有所不同，而且難以量化。不過， 根據(jù)經(jīng)驗，許多企業(yè)將比例保持在2：1（即 2位軟件專業(yè)人員：1位再培訓(xùn)硬件專家）時， 效果最好。要獲得最佳結(jié)果，企業(yè)應(yīng)制定有 吸引力的發(fā)展計劃和在職培訓(xùn)計劃，幫助員 工快速學(xué)習(xí)新的軟件語言和方法。此外，還 應(yīng)強調(diào)終身學(xué)習(xí)。
盡管再培訓(xùn)可能會彌補許多人才缺口，但企 業(yè)不應(yīng)忘記，大多數(shù)人都是在工作多年后才 發(fā)展出根深蒂固的解決問題模式。出現(xiàn)意外 問題時，硬件背景的軟件員工可能采用固化 的問題解決方法，而這些方法可能更偏線性 而非敏捷性。因此，企業(yè)應(yīng)嘗試在培訓(xùn)期間 鼓勵采用新的思維方式。若能成功的話，軟 件專家和再培訓(xùn)員工之間的差異將迅速縮 小。相反，忽視這種做法則可能妨礙整個組 織的敏捷轉(zhuǎn)型。
提供職業(yè)路徑。與技術(shù)企業(yè)相比，大多數(shù)車 企在明確職業(yè)路徑和成長機會方面仍存在 不足。之所以出現(xiàn)這種差距，是因為專家職 業(yè)路徑在車企還未廣泛普及。此外，OEM 也很少定義職位期望和資歷級別。想要繼 續(xù)晉升的專家就只能擔(dān)任管理職務(wù)，因為沒 有其他選擇。
為了提高留存率，車企可以引入明確的職業(yè) 路徑，每個級別都有特定的技能要求。一 些路徑面向業(yè)務(wù)專家，另一些則針對管理人 才。晉升路徑可以是縱向的（從初級到高級 開發(fā)人員再到團(tuán)隊負(fù)責(zé)人），或者同樣重要 的橫向輪崗，持續(xù)六個月或以上，側(cè)重培養(yǎng) 不同的技能，包括與領(lǐng)導(dǎo)力、項目管理和軟 件開發(fā)有關(guān)的技能。企業(yè)還應(yīng)制定專門的培 訓(xùn)計劃，包括職位和跨學(xué)科培訓(xùn)，開放給更 大范圍的員工。明確的職業(yè)路徑有望提高效 率，因為專家通常比新手效率更高。
B3. 明確清晰的“自研或外包”策略并建立
合作生態(tài)圈 要保持來之不易的競爭優(yōu)勢并避免成為同 質(zhì)化的硬件平臺開發(fā)商，車企必須制定明 確的客戶戰(zhàn)略，確定差異化配置和價值主張，創(chuàng)建可以對開發(fā)模塊進(jìn)行邏輯性分解的模塊化體系架構(gòu)。完成這些任務(wù)后，車企即可著眼于三大維度，從而制定明確的“自研或外包策略:
（1）開發(fā)工作所在階段,例如系統(tǒng)集成或驗收測試；
（2）軟件技術(shù)棧；
（3）軟件領(lǐng)域或模塊,可能涵蓋信息娛樂或動力總成等領(lǐng)域。
企業(yè)應(yīng)確定并定義這些維度上的控制點，從而基于其整體策略(例如針對關(guān)鍵知識產(chǎn)權(quán)、質(zhì)量標(biāo)準(zhǔn)和差異化創(chuàng)新等)確定“自研或外包”策略。
當(dāng)然，企業(yè)在決策過程中還必須考慮市場采購的難易程度。其他因素(例如成本)也很面要但通常不是決定性的。要改善決策，OEM可基于優(yōu)先級和市場情況權(quán)衡各個因素。
企業(yè)決定內(nèi)部自行開發(fā)軟件時，必須評估對內(nèi)部工程能力的影響，確定現(xiàn)有人員是否且各所有必要的能力，并檢視組織架構(gòu)和流程。如果企業(yè)缺乏合適的能力或能力不足，則應(yīng)探索收購或合資機會、從而確保其對關(guān)鍵控制點的把握。
如果企業(yè)決定外購軟件,則必須在擴(kuò)展評估過程中明確具體的采購模式，擴(kuò)展評估涉及開發(fā)合作伙伴的篩選和簽約工作。針對復(fù)雜軟件系統(tǒng)考慮部分外購時,企業(yè)最多應(yīng)簽約兩到三家供應(yīng)商。
我們的研究表明，超過這個數(shù)量就會導(dǎo)致 開發(fā)效率下降65%以上。
在全面的“自研或外包”策略中，企業(yè)應(yīng)采用 標(biāo)準(zhǔn)的開源組件，因為它們在軟件開發(fā)過程 中可提供巨大的優(yōu)勢。不過，企業(yè)需建立明 確的開源模塊使用規(guī)則和流程，并注意許 可、責(zé)任和維護(hù)問題。通常，OEM和供應(yīng)商 需簽署正式的法律協(xié)議，才能在產(chǎn)品中使用 開源組件。
最后，車企應(yīng)發(fā)展戰(zhàn)略合作伙伴關(guān)系，確定 生態(tài)圈合作企業(yè)，因為這些聯(lián)系有助于相 互學(xué)習(xí)，同時加快開發(fā)速度并保持較低成 本。共同開發(fā)還可降低較晚進(jìn)入市場所產(chǎn)生 的風(fēng)險。
在“自研或外包”策略中，OEM會將差異化功 能的生產(chǎn)留在內(nèi)部，而將非關(guān)鍵軟件的開發(fā) 外包給其他供應(yīng)商或承包商。除前述優(yōu)勢外， 該方法還將大大減少對軟件人才的需求。
C. 如何開發(fā)軟件：敏捷、解耦、測試
傳統(tǒng)上，車企一直都更重視硬件，其次才是 軟件?，F(xiàn)在必須重新審視這種觀點以及開 發(fā)方法，因為軟件現(xiàn)在是產(chǎn)品開發(fā)組合中的 一個主要的價值驅(qū)動力。這個轉(zhuǎn)變要求車企 實施大規(guī)模的敏捷方法，解耦硬件和軟件 開發(fā)流程，同時提高測試自動化和持續(xù)集 成的水平。
C1. 實施大規(guī)模敏捷方法
敏捷方法在硬件和軟件上得到大規(guī)模應(yīng)用 時，可使企業(yè)提高開發(fā)效率并快速應(yīng)對環(huán) 境變化。通過敏捷轉(zhuǎn)型，各行業(yè)企業(yè)都實現(xiàn)了開發(fā)效率和實施速度30%的提升，同時 將發(fā)布時的殘留缺陷減少了70%以上。6 因 為降低了項目預(yù)算、時間和質(zhì)量方面的風(fēng)險， 所以敏捷在應(yīng)對復(fù)雜性挑戰(zhàn)上發(fā)揮了至關(guān) 重要的作用。
迄今為止，只有少數(shù)車企自始至終地推廣敏 捷軟件開發(fā)的實踐做法。盡管許多企業(yè)都 在試點，尤其是在高級開發(fā)項目上，但只有 少數(shù)真正大規(guī)模實施了敏捷方法。
采用率低的原因可能在于汽車行業(yè)的應(yīng)用 有非常具體的要求，因此很難在整個組織中 實施標(biāo)準(zhǔn)的敏捷方法。此外，汽車行業(yè)使用 的敏捷工具必須能夠處理系統(tǒng)復(fù)雜性、與硬 件開發(fā)之間復(fù)雜的相依關(guān)系、以及網(wǎng)絡(luò)安全、 車輛安全性和質(zhì)量相關(guān)的嚴(yán)格法規(guī)要求。
與硬件開發(fā)的依存關(guān)系。要有效管理相依關(guān) 系，OEM可將系統(tǒng)工程與需求管理技術(shù)相 結(jié)合，采用大規(guī)模的敏捷方法。這些做法可 確保流暢的軟硬件集成，以及開發(fā)時間線 的同步。
涵蓋總體架構(gòu)、集成和測試的經(jīng)典系統(tǒng)工 程實踐做法將確保集成化的產(chǎn)品生命周期 管理，并幫助企業(yè)滿足法規(guī)要求。企業(yè)可利用系統(tǒng)工程實踐，明確車輛和領(lǐng)域整體架構(gòu) 。反過來，這又為敏捷團(tuán)隊提供了高 層輸入和邊界條件?；谶@些輸入，敏捷團(tuán) 隊可以先細(xì)化軟件需求，再進(jìn)行組件的開發(fā) 和測試工作。開發(fā)周期結(jié)束時，當(dāng)領(lǐng)域、車 輛集成和測試活動合成完整系統(tǒng)后，團(tuán)隊即 可關(guān)閉系統(tǒng)工程回路。
從項目管理的角度來看，目標(biāo)是使各部門對 控制單元和領(lǐng)域架構(gòu)專用要素的優(yōu)先級和 所需同步點達(dá)成一致意見。例如，企業(yè)應(yīng)優(yōu)先考慮并跟蹤某些功能的交付情況，因為 這些功能的啟動對于時間敏感事件如冬季 測試，是必不可少的。這樣，在看總體需求 完成指標(biāo)時，就只需監(jiān)控那些不太重要的功 能了。
法規(guī)要求和行業(yè)標(biāo)準(zhǔn)。敏捷開發(fā)做法在汽車行業(yè)環(huán)境下完全可行，且大大提升了效率， 但企業(yè)必須考慮法規(guī)以及硬軟件的基本同 步問題。
因此，可能需要更改部分傳統(tǒng)的工作流程， 例如創(chuàng)建認(rèn)證組件的方法（從而符合ISO 26262標(biāo)準(zhǔn)）。在傳統(tǒng)瀑布式開發(fā)模式下，認(rèn) 證組件的生成順序與工程活動相同，即規(guī) 劃、客戶需求、系統(tǒng)架構(gòu)、軟件需求、軟件實 施和軟件測試。而在敏捷開發(fā)模式中，最好 的方法卻是反向認(rèn)證，即在項目結(jié)束時，也 就是所有軟件需求和代碼都確定、固定之后， 創(chuàng)建認(rèn)證組件。這種做法可最大程度地減 少浪費，因為不用多次生成認(rèn)證組件，并且需 要軟件安全審核員從項目支出保持一致，且 與團(tuán)隊關(guān)系良好。軟硬件解耦有望進(jìn)一步簡 化ISO 26262認(rèn)證工作，因為重復(fù)使用的軟 件可能會通過經(jīng)驗證的參數(shù)進(jìn)行合規(guī)驗證，即當(dāng)其他應(yīng)用程序已經(jīng)使用該軟件而未出 現(xiàn)問題，則證明可使用該軟件。
目前，諸如ASPICE之類的行業(yè)標(biāo)準(zhǔn)規(guī)定所 有需求都必須可追溯，并能夠?qū)徲嬎褂玫?流程和工具。需求的可追溯性與敏捷實踐 做法兼容，可通過自動化工具鏈高效實現(xiàn) （請參閱A3部分的需求管理，以及D2部分 的標(biāo)準(zhǔn)化工具鏈）。但是，流程和工具的審 計需求可能會限制敏捷技術(shù)固有的持續(xù)改 進(jìn)系統(tǒng)。盡管“敏捷” 團(tuán)隊可獨立地改善其 流程和工作方法，但汽車團(tuán)隊卻必須符合文 件標(biāo)準(zhǔn)的要求，并確保各個團(tuán)隊之間的同步， 這些行動可能拖慢其進(jìn)度。
何時采用敏捷方法。盡管需要預(yù)定義的待 辦事項以及可審計的流程和工具，汽車軟 件團(tuán)隊仍可即刻采取大多數(shù)敏捷實踐。但是 這會極大地改變他們的工作方式。
轉(zhuǎn)向敏捷方法時，組織必須對宏觀層面的 運營（包括項目組合、資源和項目管理）進(jìn) 行關(guān)鍵設(shè)計的決策。通常，只有先進(jìn)的開發(fā) 部門，例如OEM的“軟件工廠”，才采用規(guī)模 化的敏捷方法，即所有部門都完全采用新 的工作方式。但是也有例外，例如，一些汽 車先驅(qū)企業(yè)已實施了規(guī)模化敏捷方法，例如 規(guī)模化敏捷框架（SAFe），指導(dǎo)其總體研 發(fā)工作。
與之相反，各個團(tuán)隊則應(yīng)始終遵循已建立 的敏捷實踐開展業(yè)務(wù)。例如，跨部門代表 和/或團(tuán)隊成員同址辦公以及有時間限制的 迭代都非常重要。與其他行業(yè)一樣，在將敏捷方法應(yīng)用于負(fù)責(zé)各個功能的團(tuán)隊時，其優(yōu) 勢可能最為明顯。
當(dāng)OEM向敏捷流程過渡時，還必須：
將開發(fā)供應(yīng)商集成到其敏捷流程中，促 進(jìn)全面的應(yīng)用；
調(diào)整采購流程，從有明確預(yù)定義和預(yù)協(xié) 商的基于規(guī)格的合同關(guān)系轉(zhuǎn)變?yōu)榛跊_ 刺的開發(fā)合作伙伴關(guān)系；
解決影響供應(yīng)商與OEM共址辦公或敏捷 合作的法律問題。
C2.軟硬件解耦促進(jìn)雙速開發(fā)流程
在流程方面，車企可采用更動態(tài)的軟件周期計劃，支持經(jīng)常性的發(fā)布,而非受限于嚴(yán)格而遙遠(yuǎn)的車輛平臺SOP日期。將產(chǎn)品及生命周期管理與硬件解耦是脫離獨立整車(one-vehicle)SOP方向的關(guān)鍵。為此，必須保持獨立的待辦事項和路線圖,同時明確軟硬件開發(fā)之間的同步里程碑。在與供應(yīng)商合作時，0EM可能需要重新簽訂新的協(xié)議。最后，OEM必須加強自動化軟件的使用,集成測試和部署。
與敏捷方法一樣，系統(tǒng)開發(fā)團(tuán)隊可管理和定義硬件和軟件團(tuán)隊之間的接口，明確劃分硬件/軟件待辦事項，確保各層級的同步。顯然，如果硬件和軟件彼此獨立，即可分設(shè)架構(gòu)凍結(jié)點，這樣就無需同步了。
像敏捷方法一樣，解耦也需有若干先決條件,包括標(biāo)準(zhǔn)化和模塊化的架構(gòu)以及可靠的測試方法。如前所述，企業(yè)可以使用強大的中間件將軟件與硬件解耦，中間件可以提取硬件能力(middleware layer that abstracts hardware capabilities)，通過標(biāo)準(zhǔn)化API將其提供給需要的功能和服務(wù)。但最關(guān)鍵的解耦抓手其實是具有魯棒性的車輛測試方法。因此，企業(yè)必須定義提供和維護(hù)測試車輛的方法:例如硬件在環(huán)或軟件在環(huán)系統(tǒng)，或者是更廣泛的仿真基礎(chǔ)架構(gòu)。
敏捷方法和硬件/軟件開發(fā)解耦都對價值 鏈的下游有重大影響，尤其是對于采購組織 而言。例如，采購需從傳統(tǒng)的瀑布式采購流 程轉(zhuǎn)變?yōu)楦m合敏捷和解耦開發(fā)方法的模 式。在實踐中，這就要求OEM遵循某些最佳 實踐做法，例如不斷評估軟件要素對于戰(zhàn)略 的重要性，了解需求將如何演變以及確定每 種情況下最合適的采購模式。這些變化要求 對軟件總擁有成本以及新的合作模式有所 了解，新模式側(cè)重戰(zhàn)略合作伙伴關(guān)系而非多 供應(yīng)商采購。
C3. 提高測試自動化、完善持續(xù)集成，確 保盡早發(fā)現(xiàn)錯誤
隨著軟件數(shù)量的增加以及對連續(xù)功能更新 的更大需求，OEM必須盡快發(fā)現(xiàn)并解決漏 洞和接口錯誤。如果無法直接解決問題，漏 洞可能會大量積壓，從而消耗掉所有資源 并使問題跟蹤復(fù)雜化，導(dǎo)致開發(fā)延誤并產(chǎn) 生更多的驗證工作。
與敏捷實踐一樣，幾乎沒有車企大規(guī)模采 用持續(xù)集成或自動化測試的方法。但只要它 們采用這些做法，即可降低發(fā)布風(fēng)險，同時 大大提高開發(fā)效率。根據(jù)我們的經(jīng)驗，企業(yè) 可將開發(fā)效率提高40%以上，同時將殘余 缺陷密度降低60%以上。
要仿效先行企業(yè)，車企應(yīng)采用兩個相互關(guān) 聯(lián)的軟件開發(fā)最佳實踐。首先，應(yīng)每天幾次 將代碼集成到共享存儲庫中并通過自動構(gòu) 建進(jìn)行驗證。盡早集成代碼有助于開發(fā)人員“快速失敗” （及早發(fā)現(xiàn)問題），然后通過 持續(xù)集成實踐、工具和自動化手段，輕松 隔離問題，使之不會產(chǎn)生更大的問題。供應(yīng) 商則可獨立地在系統(tǒng)層面上獲取這些益處。 在整車層面上，OEM需要解決IP限制問題，自研編碼（insource coding）或采用“白盒” 方法，與供應(yīng)商共享完整代碼。解決方案的 第二個要素是測試驅(qū)動開發(fā)和自動化流程， 即在編碼開始前就對測試進(jìn)行定義，然后 在代碼集成后自動進(jìn)行測試。
軟件設(shè)計人員和開發(fā)人員（而不是獨立的測 試部門）在開發(fā)過程中與客戶一起對測試進(jìn) 行優(yōu)化和迭代。該方法迫使開發(fā)人員在編 碼開始前即要考慮如何使用系統(tǒng)以及如何 實施這個問題。最終，全面的自動化測試套 件將使可持續(xù)、沖刺成為可能。
D. 如何促進(jìn)軟件開發(fā)：性能和 工具鏈
為了優(yōu)化軟件驅(qū)動型運營模式的效率，企業(yè) 應(yīng)采用一流的性能管理方法，并通過構(gòu)建軟 件開發(fā)工具鏈，建立最先進(jìn)的軟件開發(fā)基 礎(chǔ)架構(gòu)。
D1. 實施性能管理，涵蓋數(shù)據(jù)驅(qū)動的開發(fā) 效率、項目成熟度和質(zhì)量度量
隨著軟件復(fù)雜性的提升，車企必須升級其 性能管理體系，采用標(biāo)準(zhǔn)化、數(shù)據(jù)驅(qū)動的指 標(biāo)對開發(fā)效率、項目成熟度和質(zhì)量進(jìn)行度量。 只有自動化的、數(shù)據(jù)驅(qū)動的洞見才能賦能基 于事實的實時性能管理方法，主動暴露出時 間、成本和質(zhì)量方面迫在眉睫的軟件問題。
一流的軟件性能管理系統(tǒng)應(yīng)在以下三個關(guān)鍵 事項上脫穎而出：
（1）建立全面的KPI（如成本、時間和質(zhì)量 KPI指標(biāo)）體系，確保每個指標(biāo)都與總體 業(yè)務(wù)目標(biāo)和運營任務(wù)掛鉤；
（2）開發(fā)一個有效的問題上報系統(tǒng)，包括標(biāo) 準(zhǔn)會議這種形式，側(cè)重簡單、快速的匯報、 決策和上報；
（3）采用工具化、自動化的開發(fā)效率測量技 術(shù)和代碼質(zhì)量衡量指標(biāo)，確保對軟件開 發(fā)效率和質(zhì)量進(jìn)行客觀的測量。
D2.升級開發(fā)工具鏈
車企可引入標(biāo)準(zhǔn)化軟件開發(fā)工具鏈，支持 持續(xù)集成和標(biāo)準(zhǔn)API的使用，從而提升開發(fā) 效率。典型的工具鏈組件包括側(cè)重構(gòu)建、持 續(xù)集成和測試自動化的源代碼管理流程和 工具，測試自動化包括測試執(zhí)行、測試結(jié)論 生成和測試報告生成。如上所述，該工具鏈 還無縫集成了需求管理方面的所有工具。
構(gòu)建一套集成、高度自動化的工具鏈可在開 發(fā)過程中帶來極大益處。例如，可降低復(fù)雜 度從而提升內(nèi)部效率，可使用來自外部構(gòu)建模塊的成熟技術(shù)。根據(jù)我們的研究和經(jīng)驗， 先進(jìn)的工具鏈可以：
推動更快、更敏捷的開發(fā)，將代碼發(fā)布 或構(gòu)建所需工作減少90%；
通過嚴(yán)格的質(zhì)量管卡的使用而降低缺陷 密度，從而有可能將故障率降低50%。
允許企業(yè)每天進(jìn)行成千上萬次編譯，而 無需任何人工干預(yù) 總體而言，引入標(biāo)準(zhǔn)化、最先進(jìn)的開發(fā)工具 鏈，是釋放自動化測試和敏捷方法30%至 40%效率潛力的關(guān)鍵推動力。這種性能水 平足以使表現(xiàn)最佳的企業(yè)脫穎而出。車企應(yīng) 將這種軟件開發(fā)工具鏈視為高效率組織的 核心部分，這類組織都支持連續(xù)集成和標(biāo) 準(zhǔn)API的使用。此類工具鏈還可確保整個開 發(fā)過程中軟件與硬件開發(fā)工具之間高效的自 動化接口。
同時，工具鏈還為若干流程步驟的自動化 （例如測試運行）提供了機會?？傮w而言，目 標(biāo)就是加快開發(fā)速度，促進(jìn)盡早測試。
通常，用到的工具鏈和工具的數(shù)量會增加 到難以管理的水平，從而降低透明度。為避 免此問題的出現(xiàn)，經(jīng)驗豐富的工具鏈管理人 員應(yīng)定期檢查工具狀況，必要時采取糾正 措施。
使轉(zhuǎn)型成為現(xiàn)實
許多組織已開始認(rèn)真采取行動，希望從軟 件上獲取價值，從而抓住電動化、網(wǎng)聯(lián)化、 智能化、共享化這個“新四化”趨勢帶來的機 遇并從中受益。典型的轉(zhuǎn)型之旅始于某個單 一挑戰(zhàn)或主題，例如恢復(fù)軟件項目的即時補 救措施、軟件“自研或外包”決策或是軟件開 發(fā)績效方面的重大預(yù)期變化。但是，大多數(shù) 企業(yè)發(fā)現(xiàn)，單一面向的干預(yù)帶來的影響非 常有限，尤其是當(dāng)企業(yè)缺乏持續(xù)改進(jìn)所需 的關(guān)鍵基礎(chǔ)時。因此，要建立世界一流的軟 件開發(fā)能力，企業(yè)應(yīng)采取端到端的轉(zhuǎn)型視角。 考慮到各自現(xiàn)狀的不同，企業(yè)可能以不同的 方式進(jìn)行轉(zhuǎn)型。斟酌初始轉(zhuǎn)型側(cè)重點時，可 以選擇以下的某個切入點：
“是什么”：產(chǎn)品架構(gòu)和“自研或外包”決策
目的是建立一套目標(biāo)軟件架構(gòu)，既有具體的 內(nèi)控點，又有外部合作生態(tài)圈，從而可實現(xiàn) 跨平臺的高效且有競爭力的軟件交付。
“如何做”：開發(fā)效率提升和軟件開發(fā)方法
重點是利用軟件開發(fā)的關(guān)鍵效率杠桿（包 括敏捷研發(fā)、持續(xù)集成）和自動化測試，提 高軟件研發(fā)的效率（請參閱C和D2部分）。
“在哪里做”：以合理的成本獲得人才
面臨產(chǎn)能不足、無法有效提升軟件產(chǎn)出的企 業(yè)可先從該主題切入。解決方案包括改善 其業(yè)務(wù)足跡、使組織對軟件人才更具吸引 力，從而優(yōu)化人才和研發(fā)成本（請參閱B2 部分）。
“如何設(shè)置”：組織與治理
另一個起點是定義最佳的組織架構(gòu)，明確“ 框線”圖架構(gòu)，并說明具體的運營模式，包 括績效引導(dǎo)和績效管理，從而加強軟件交付 。
要克服汽車行業(yè)當(dāng)前的軟件復(fù)雜性和開發(fā) 效率難題，就需要對汽車軟件研發(fā)進(jìn)行全 面的轉(zhuǎn)型。CTO和CEO必須將這一挑戰(zhàn)作為 其日程上的重中之重，并立即加以應(yīng)對，才 能在當(dāng)前的行業(yè)環(huán)境中保持競爭力和成功 的市場地位，而且他們還應(yīng)為更大規(guī)模的 轉(zhuǎn)型做好準(zhǔn)備，因為解決與軟件組織及其 底層運營模式有關(guān)的所有問題可能需要耗 時數(shù)年之久。
詳見報告原文。
（本文僅供參考，不代表我們的任何投資建議。如需使用相關(guān)信息，請參閱報告原文。）
精選報告來源：【未來智庫官網(wǎng)】。
聯(lián)系客服
