車企如何進(jìn)行軟件研發(fā)？

王懌愷　桂靈峰　祖欣然　曹裕

軟件定義汽車已成行業(yè)共識。軟件正深度參與到汽車定義、開發(fā)、驗(yàn)證、銷售、服務(wù)等過程中，不斷改變和優(yōu)化各個過程，實(shí)現(xiàn)體驗(yàn)持續(xù)優(yōu)化、過程持續(xù)優(yōu)化、價值持續(xù)創(chuàng)造。

在面向軟件的組織方式下，傳統(tǒng)的軟件開發(fā)模型太過復(fù)雜龐大，在應(yīng)對靈活多變的客戶需求時，顯得冗長拖沓。這體現(xiàn)在結(jié)果上，就是整車廠即使把軟件提到了企業(yè)戰(zhàn)略的高度，在關(guān)鍵控制點(diǎn)還是會出現(xiàn)戰(zhàn)略不清、組織分工不明的情況，使得整個組織在數(shù)字化轉(zhuǎn)型、軟件技術(shù)開發(fā)相關(guān)的領(lǐng)域里決策失效。

因此，源自科技行業(yè)的敏捷開發(fā)模式逐漸被初創(chuàng)車企采用，并逐漸普及到全行業(yè)——對軟件架構(gòu)進(jìn)行模塊化分解，形成標(biāo)準(zhǔn)化、即插即用的組件，以適應(yīng)軟件產(chǎn)品的快速迭代，并達(dá)到節(jié)省開發(fā)成本、提高開發(fā)效率的目的。

與此相對應(yīng)的，車企在組織與流程、資源與能力、心態(tài)與文化方面都需要做出調(diào)整。我們認(rèn)為，傳統(tǒng)車企面向軟件的轉(zhuǎn)型，需要推進(jìn)開發(fā)流程的敏捷度、提升組織的靈活度，具體涉及五大核心能力，歷經(jīng)三大關(guān)鍵階段。

研發(fā)投入很大，但效率高嗎？

我們發(fā)現(xiàn)，整車廠和主要高科技廠商在軟件研發(fā)方面的支出有明顯區(qū)別。

谷歌每年的軟件研發(fā)支出是320億美元，蘋果是220億美元，在所有統(tǒng)計對象中遙遙領(lǐng)先。在整車廠中，大眾汽車集團(tuán)和旗下軟件公司Cariad的軟件支出最多，為每年35億美元；隨后是豐田，每年20億美元；梅賽德斯、斯特蘭蒂斯、寶馬、福特、通用等老牌整車廠，每年在軟件研發(fā)上的開銷大概在8億美元到15億美元之間。

我們留意到，Rivian、特斯拉和蔚來等初創(chuàng)車企，也致力于大力投入軟件研發(fā)，每年花在軟件上的錢分別是7.5億、6億和5.5億美元，甚至投入規(guī)模超過了部分傳統(tǒng)整車廠。

總體投入規(guī)模和車企銷量規(guī)模有密不可分的關(guān)系，這正是大眾和豐田作為全球汽車銷量前兩名，在軟件研發(fā)上的投入同樣領(lǐng)先行業(yè)的原因之一。因此，研發(fā)效率，也就是單輛汽車的軟件研發(fā)支出，是同樣值得關(guān)注的指標(biāo)。

數(shù)據(jù)顯示，Rivian和蔚來的單車研發(fā)成本最高，都超過了1000美元，每輛車上的軟件研發(fā)成本分別是1500美元和1100美元。當(dāng)然，這是因?yàn)閮杉页鮿?chuàng)車企的銷量規(guī)模還比較小，在總體投入規(guī)模大的前提下，單車成本無法被攤薄。

更值得關(guān)注的信號是，傳統(tǒng)車企的單車研發(fā)成本高。比如梅賽德斯的單車軟件成本是750美元，寶馬是400美元，大眾汽車集團(tuán)和旗下軟件公司Cariad的這一數(shù)字是350美元。

傳統(tǒng)整車廠的單車研發(fā)成本高，這背后有三個方面原因。

首先，傳統(tǒng)整車廠在新技術(shù)領(lǐng)域，尤其是軟件技術(shù)方面的投入和成熟度并不高，導(dǎo)致即使把軟件提到了企業(yè)戰(zhàn)略的高度，其在關(guān)鍵控制點(diǎn)還是會出現(xiàn)戰(zhàn)略不清、組織分工不明的情況。

以德系整車廠為例，新成立的軟件部門關(guān)鍵崗位人員往往還是以傳統(tǒng)汽車背景，甚至是硬件工程類背景為主，使得整個組織在數(shù)字化轉(zhuǎn)型、軟件技術(shù)開發(fā)相關(guān)的領(lǐng)域里決策失效。

另外更直接的影響也在于，軟件相關(guān)智能網(wǎng)聯(lián)功能的開發(fā)周期，在保證高可用性體驗(yàn)和更新及時性的同時，無法與傳統(tǒng)硬件周期有效協(xié)同。這一系列的“運(yùn)行不暢”可能會進(jìn)一步造成產(chǎn)品管理、生產(chǎn)，乃至營銷體系的堵點(diǎn)，從而造成不可避免的管理成本。

我們在初創(chuàng)企業(yè)里面看到的精英團(tuán)隊(duì)主義、明星產(chǎn)品經(jīng)理主義，是以團(tuán)隊(duì)的主觀能動性、組織的敏捷性和精英向的企業(yè)文化為前提的。針對這類企業(yè)，軟件研發(fā)投入高的原因主要還是對于自研比例的追求，還有前期“學(xué)費(fèi)型”的投入過高。

以蔚來為例，其在軟件領(lǐng)域的組織能力形成也走過了相對較久的摸索期，深深體會到對于“想要何種數(shù)字化體驗(yàn)”“軟硬件載體和環(huán)境選擇”“自研還是外采”“需要哪種研發(fā)協(xié)同組織”“招募哪類人才和如何激勵”這幾個階段的從無到有，其實(shí)沒有捷徑可走。

其次，在市場需求理解層面，雙方也有區(qū)別。

傳統(tǒng)整車廠由于受到內(nèi)部話語權(quán)和產(chǎn)品規(guī)劃設(shè)計流程機(jī)制影響，對客戶需求及其體驗(yàn)水平缺乏系統(tǒng)化定義，尤其是創(chuàng)新功能與服務(wù)，個人主觀判斷仍占主導(dǎo)。

盡管普遍采取定期調(diào)研、第三方數(shù)據(jù)整合等做法大量采集數(shù)據(jù)，但用戶需求的盲點(diǎn)依然存在，且對所得數(shù)據(jù)的系統(tǒng)化處理、大數(shù)據(jù)分析能力等尚待提升。即使能夠在當(dāng)前產(chǎn)品周期開始之前及時獲得了準(zhǔn)確的客戶洞察，仍需要多部門高效地把洞察轉(zhuǎn)化為產(chǎn)品定義的需求，并整合到全生命周期管理的環(huán)節(jié)當(dāng)中去。

最后，在合作伙伴層面，傳統(tǒng)整車廠的集采加整合的路徑，在數(shù)字化軟件領(lǐng)域不再適用，導(dǎo)致不得不重新摸索全新生態(tài)環(huán)境下，與軟件開發(fā)商、內(nèi)容和數(shù)字化服務(wù)提供商的合作模式。這就意味著全新的供應(yīng)商體系搭建，包括能力評估要求、合作框架，甚至數(shù)字信息的合規(guī)化運(yùn)營。而每一項(xiàng)變革都會給廠商帶來額外的運(yùn)營成本。

對于大部分日系、美系及部分歐洲整車廠而言，軟件研發(fā)投入比例還沒有那么顯性的原因，或許是在于各廠商的戰(zhàn)略野心與實(shí)際落地方案之間的平衡，雖然耗時，但事實(shí)上大部分整車廠還是更愿意“想清楚再干”。

圖1：實(shí)現(xiàn)以軟件為中心轉(zhuǎn)型宏偉目標(biāo)的成本需求

注：關(guān)鍵假設(shè)包括：梅賽德斯的數(shù)據(jù)是MB.OS 2.0；每輛車的數(shù)據(jù)是基于2021年單位銷量計算的，但蔚來汽車和Rivian除外，這兩家車企的數(shù)據(jù)是基于2026年共識預(yù)測僅研發(fā)支出-沒有關(guān)于硬件采購成本的假設(shè)。資料來源：科爾尼 制圖：顏斌

因?yàn)樵诖罱ㄜ浖芰蛿?shù)字化產(chǎn)品體系的同時，務(wù)必會帶來更多與終端客戶的數(shù)字觸點(diǎn)，如何規(guī)整這些觸點(diǎn)的體驗(yàn)，讓其能夠傳遞一致的品牌信息與調(diào)性，并讓這些額外產(chǎn)生的數(shù)字交互為己所用。

這樣往小了說，能夠承接各條線的業(yè)務(wù)目標(biāo)和戰(zhàn)略，比如網(wǎng)絡(luò)直銷帶來的增量銷量，和用戶社區(qū)帶來的用戶黏性；往大了說，就能加速拉動整體研發(fā)組織的數(shù)字化轉(zhuǎn)型，比如設(shè)計與測試階段的仿真應(yīng)用，更進(jìn)一步打通軟硬件周期、賦能技術(shù)創(chuàng)新。

以此為愿景，我們可以預(yù)期接下來很長一段時間內(nèi)，這些后發(fā)制人的整車廠或許會出現(xiàn)更高比例的投入支出。

舊模型日顯拖沓，源自科技行業(yè)的新模型頂上

目前應(yīng)用V模型進(jìn)行軟件開發(fā)是整車廠的主流，也是A-SPICE（Automotive Software Process Improvement and Capability）這一汽車行業(yè)廣泛應(yīng)用的軟件開發(fā)體系的基石。

V模型將軟件開發(fā)過程中的技術(shù)要求、需求分析、開發(fā)以及測試環(huán)節(jié)以V形排布。從整體到架構(gòu)層，到系統(tǒng)層，到功能層進(jìn)行需求分析，再開始開發(fā)，待開發(fā)工作完成后，又逐層向上從功能測試，到系統(tǒng)測試到整車測試認(rèn)證，以及系統(tǒng)集成工作。

通過應(yīng)用該模型，汽車整車廠可以一步步深化拆解分析需求，在開發(fā)后，又能夠自下而上的層層驗(yàn)證測試。該模型能夠很好滿足車企對于大型復(fù)雜系統(tǒng)和軟件的管理需求，因而得到了歐美系車企的大力推廣和應(yīng)用。自A-SPICE于2005年發(fā)布以來，越來越多汽車整車廠不僅在自身的研發(fā)部門需要使用，甚至開始要求其Tier1一級供應(yīng)商在進(jìn)行軟件交付時也要應(yīng)用V模型并符合A-SPICE的標(biāo)準(zhǔn)。

但問題是，傳統(tǒng)的V模型軟件開發(fā)太過復(fù)雜龐大，在應(yīng)對靈活多變的客戶需求時，顯得冗長拖沓。隨著中央計算架構(gòu)的不斷發(fā)展，以及OTA的逐漸普及，終端功能性應(yīng)用的日益增多，整車廠也越來越多地需要快速迭代軟件版本，以滿足客戶需求，同時在與其他車企競爭中能夠保持領(lǐng)先一步。

舉例來說，一個完整的V模型開發(fā)過程，通常需要12個-18個月的時間，而軟件更新在V模型下也需要3個-6個月的時間，而這顯然是無法滿足客戶需求的，因此整車廠開始引入敏捷開發(fā)（Agile）模式，希望能夠在部分需要快速迭代的軟件功能開發(fā)上，實(shí)現(xiàn)對消費(fèi)者需求的快速滿足。

何為敏捷開發(fā)？這是一個閉環(huán)的開發(fā)流程模型，從規(guī)劃、代碼、編譯打包、測試、發(fā)布、部署，到反饋，調(diào)整持續(xù)改進(jìn)，并最終回到規(guī)劃環(huán)節(jié)。

可以看出該模型的特點(diǎn)在于以客戶為中心，持續(xù)獲得反饋，持續(xù)改進(jìn)；由于不像V模型那樣每次都將收集獲得的全部需求統(tǒng)一分析處理，而是分布式漸進(jìn)式的逐步改進(jìn)調(diào)整，因此其軟件開發(fā)以及版本迭代的時間也被大幅縮減。

V模型和敏捷模型這兩種開發(fā)體系，在適用軟件特性、開發(fā)時間、靈活度以及對客戶需求的反應(yīng)速度上存在差異。比如敏捷模型更多應(yīng)用于智能駕駛艙、互聯(lián)網(wǎng)等相關(guān)應(yīng)用，而關(guān)于動力總成、電池等仍然需要依照V模型，其中具體功能可通過敏捷方式迭代。

圖2：V模型：端到端開發(fā)典型實(shí)踐

資料來源：科爾尼

長期來看，兩者會共存，也因此整車廠需要熟練掌握這兩類開發(fā)體系。

對于V模型，各個整車廠近年來已經(jīng)有了較多的應(yīng)用；對于敏捷模式，由于是從高科技行業(yè)引入，傳統(tǒng)整車廠還需要進(jìn)一步掌握該流程的使用，而具有互聯(lián)網(wǎng)基因的新興整車廠如特斯拉、“蔚小理”（蔚來、理想、小鵬）等，已經(jīng)能夠比較好的應(yīng)用該模式進(jìn)行開發(fā)工作。

五大核心能力，三大關(guān)鍵階段

根據(jù)敏捷開發(fā)模型的特點(diǎn)，我們分析了從開發(fā)測試到部署再到改進(jìn)優(yōu)化的端到端流程，并提煉出了實(shí)現(xiàn)卓越開發(fā)的15個賦能手段，幫助整車廠更好地實(shí)現(xiàn)敏捷開發(fā)。

15個階段的賦能手段可以根據(jù)整車廠對敏捷開發(fā)的應(yīng)用熟練度分為三個階段，分別是“敏捷軟件開發(fā)能力建設(shè)”“敏捷軟件開發(fā)可規(guī)模化擴(kuò)張”以及“敏捷軟件開發(fā)成為戰(zhàn)略優(yōu)勢”。

其中第一階段可謂重中之重，是二、三階段順利開展的先決條件，整車廠需要在第一階段夯實(shí)能力基礎(chǔ)，包括以功能為導(dǎo)向的敏捷開發(fā)、以功能為導(dǎo)向的軟件設(shè)計與架構(gòu)、關(guān)鍵人才賦能的軟件開發(fā)、端到端測試與集成的自動化更新機(jī)制和已售出車輛的持續(xù)更新與集成流程，后續(xù)才能在中長期的第二、三階段發(fā)揮優(yōu)勢。

接下來我們會重點(diǎn)分析第一階段的五大措施。

第一，以功能為導(dǎo)向的敏捷開發(fā)，意味著在代碼階段就需要一個以功能為導(dǎo)向的敏捷開發(fā)組織，其人員一般來自于傳統(tǒng)的部門架構(gòu)，由業(yè)務(wù)單元高層管理人員、工程與軟件團(tuán)隊(duì)的核心人員以及開發(fā)工程師組成，但其工作方式則以功能開發(fā)為導(dǎo)向。

在職能分工上，不再強(qiáng)調(diào)人員在企業(yè)內(nèi)的上下級匯報關(guān)系，而是會設(shè)定一個核心領(lǐng)導(dǎo)負(fù)責(zé)項(xiàng)目規(guī)劃、時間計劃以及功能集成，其他人員則包括：系統(tǒng)經(jīng)理負(fù)責(zé)項(xiàng)目預(yù)算及資源調(diào)配，測試工程師負(fù)責(zé)驗(yàn)證，軟件硬件工程師負(fù)責(zé)軟硬件需求分析、方案設(shè)計與集成，客戶需求服務(wù)工程師負(fù)責(zé)分析客戶需求及其解決方案規(guī)劃，制造工程師負(fù)責(zé)在硬件制造方面的需求對接與系統(tǒng)集成。該團(tuán)隊(duì)在敏捷開發(fā)的規(guī)劃階段一起工作，然后將并行開展開發(fā)和集成與測試工作。

這樣的工作方式可以最大化地實(shí)現(xiàn)以客戶需求為導(dǎo)向，以產(chǎn)品為核心的開發(fā)，以及成本高效的持續(xù)迭代。

第二，除了開發(fā)團(tuán)隊(duì)，也需要在代碼階段考慮以功能為導(dǎo)向的軟件設(shè)計與系統(tǒng)架構(gòu)。中央計算架構(gòu)在此則起到了重要的作用?，F(xiàn)今雖然中央計算架構(gòu)被各大車企反復(fù)提及，但真正得到實(shí)際量產(chǎn)應(yīng)用的平臺并不多，以特斯拉為例，其中央架構(gòu)涵蓋了目前與客戶感受最相關(guān)的自動駕駛域、座艙娛樂域以及網(wǎng)絡(luò)安全與車聯(lián)網(wǎng)域?；诖嗽O(shè)計，可以將軟件需求拆解為上車軟件以及后臺軟件，通過網(wǎng)關(guān)實(shí)現(xiàn)交互。

這樣的中央平臺架構(gòu)可以實(shí)現(xiàn)通用的軟件設(shè)計，并且能夠應(yīng)用一個軟件版本去覆蓋大多數(shù)在售車型。綜上所述，有中央平臺架構(gòu)做基礎(chǔ)，通過高成本性價比的架構(gòu)、高通用性的軟件，以及基于不同平臺定制化的模塊軟件，能夠幫助整車廠實(shí)現(xiàn)卓越的敏捷開發(fā)。

第三，需要在人才層面進(jìn)行儲備、培養(yǎng)與賦能，并建立起與之匹配的人才機(jī)制，進(jìn)行關(guān)鍵人才賦能的軟件開發(fā)。

在人才儲備層面，需建立起完善的招募與培養(yǎng)機(jī)制來保證具有全局觀或是具備某個模塊專長的技術(shù)人員儲備——包括整車系統(tǒng)層面、應(yīng)用層面、車聯(lián)網(wǎng)方向、移動端開發(fā)方向等。

在授權(quán)管控層面，創(chuàng)建扁平化的決策委員會機(jī)制，并充分考慮技術(shù)因素與決策的敏捷性。決策委員會成員以各BU主要負(fù)責(zé)人和技術(shù)領(lǐng)導(dǎo)人作為主導(dǎo)，其他各相關(guān)方輔助配合，保證決策會議有效記錄，會議結(jié)果的輸出是產(chǎn)品特征優(yōu)先級排序。

在賦能機(jī)制層面，充分賦予每一位工程師參與產(chǎn)品建議的權(quán)利，充分調(diào)動每一位技術(shù)人員的積極性，以保證全員參與到產(chǎn)品提升的過程中。

這樣的人才機(jī)制能夠大大提高流程效率。通過將決策權(quán)交給真正有能力的工程師，能夠最大限度地發(fā)揮人才潛力；通過扁平化和高效率的決策流程能夠快速應(yīng)對消費(fèi)者反饋與市場變化。

第四，建立端到端測試與集成的自動化更新機(jī)制。持續(xù)集成和持續(xù)交付需要快速完成計劃、編碼、測試、發(fā)布的循環(huán)，自動化的測試和自動化的發(fā)布是不可或缺的組成部分。而這一過程應(yīng)用于每一次提交，意味著每一次代碼的提交、合并都會經(jīng)過自動化的測試，成為一個新的發(fā)布版本。

以特斯拉為例，在硬件、系統(tǒng)與整車層面建立平行測試機(jī)制，依托Jenkins開源軟件工具創(chuàng)建自動化的測試體系，在每一次軟件版本更新迭代后自動觸發(fā)。依次通過軟件虛擬模擬、真實(shí)/虛擬外設(shè)環(huán)境下的硬件測試、真實(shí)外設(shè)環(huán)境下的系統(tǒng)測試、整車系統(tǒng)測試、真人道路測試環(huán)節(jié)，其中硬件、系統(tǒng)與整車層面的全部測試能夠在20小時內(nèi)完成，從而使得全部測試時間控制在24小時以內(nèi)。

這樣的自動化測試機(jī)制提供了一個全自動的中心化測試機(jī)制，使得全部測試與集成能夠在24小時內(nèi)完成，并且可以在無需更改已經(jīng)通過驗(yàn)證的功能下完成自動化更新。

第五，對于已售出車輛的持續(xù)更新與整合也是卓越開發(fā)的重要一環(huán)。根據(jù)軟件開發(fā)的分支管理模型，分別按照軟件開發(fā)、軟件測試和已售管理三個典型分支進(jìn)行（實(shí)際可能存在更多分支），并對應(yīng)單一的數(shù)據(jù)存儲庫。

以特斯拉為例，對于開發(fā)分支而言，在軟件構(gòu)建階段保證每周200次的更新，以及測試與集成階段每周7次更新和15%的完成率；對于測試分支，在軟件構(gòu)建階段保證每周30次的更新，以及測試與集成階段每周14次更新和50%的完成率，以及在現(xiàn)場部署階段每周0.5次更新；對于客戶分支，在軟件構(gòu)建階段保證每周20次的更新，以及測試與集成階段每周10次更新和80%的完成率，以及在現(xiàn)場部署階段每周3次更新。

這種已售車輛的更新與集成模型以模塊化發(fā)布的方式進(jìn)行，能夠根據(jù)發(fā)布的準(zhǔn)備成熟度來保證集成或是排除某一特定功能，并使得功能分支在單一的存儲庫中隨時更新，尤其是對于已售車輛的客戶端功能保持在80%及以上部署完成的狀態(tài)。

經(jīng)過敏捷模型第一階段的發(fā)展，整車廠將完成向敏捷軟件開發(fā)的初步轉(zhuǎn)型，并形成以下五大核心基礎(chǔ)能力，為“敏捷軟件開發(fā)可規(guī)?；瘮U(kuò)張”（第二階段），以及“敏捷軟件開發(fā)成為戰(zhàn)略優(yōu)勢”（第三階段）奠定堅(jiān)實(shí)基礎(chǔ)：

1.以客戶需求為導(dǎo)向、軟件功能為核心、貫穿規(guī)劃-開發(fā)-集成與測試環(huán)節(jié)的敏捷組織架構(gòu)。確保全員圍繞敏捷開發(fā)為核心愿景，進(jìn)行全鏈路資源的長期合理分配。

2.基于中央平臺架構(gòu)的模塊化、通用化、定制化軟件設(shè)計體系。以優(yōu)異的性價比和適配性助力整車廠實(shí)現(xiàn)規(guī)?；瘮U(kuò)張。

3.軟件人才的長期儲備、培養(yǎng)與賦能體系。激發(fā)精英人才潛力，提高流程效率，持續(xù)保障產(chǎn)品競爭力，并為最終實(shí)現(xiàn)敏捷軟件開發(fā)戰(zhàn)略優(yōu)勢提供長期人才支撐。

4.高效的端到端、全自動、中心化測試與更新機(jī)制。大幅縮短軟件更新迭代周期，形成以市場敏捷應(yīng)對為核心的軟件開發(fā)戰(zhàn)略優(yōu)勢。

5.模塊化的已售車輛軟件持續(xù)管理與更新機(jī)制?；诠δ艹墒於绕ヅ渥詈侠淼陌l(fā)布周期，有效平衡功能部署完成率與優(yōu)質(zhì)的客戶使用體驗(yàn)，降低已售車輛管理復(fù)雜度，以實(shí)現(xiàn)更為快速、平穩(wěn)的規(guī)?；瘮U(kuò)張。

（作者是科爾尼全球合伙人、董事、項(xiàng)目經(jīng)理和咨詢顧問；編輯：王靜儀）