王懌愷 桂靈峰 祖欣然 曹裕
軟件定義汽車已成行業共識。軟件正深度參與到汽車定義、開發、驗證、銷售、服務等過程中,不斷改變和優化各個過程,實現體驗持續優化、過程持續優化、價值持續創造。
在面向軟件的組織方式下,傳統的軟件開發模型太過復雜龐大,在應對靈活多變的客戶需求時,顯得冗長拖沓。這體現在結果上,就是整車廠即使把軟件提到了企業戰略的高度,在關鍵控制點還是會出現戰略不清、組織分工不明的情況,使得整個組織在數字化轉型、軟件技術開發相關的領域里決策失效。
因此,源自科技行業的敏捷開發模式逐漸被初創車企采用,并逐漸普及到全行業——對軟件架構進行模塊化分解,形成標準化、即插即用的組件,以適應軟件產品的快速迭代,并達到節省開發成本、提高開發效率的目的。
與此相對應的,車企在組織與流程、資源與能力、心態與文化方面都需要做出調整。我們認為,傳統車企面向軟件的轉型,需要推進開發流程的敏捷度、提升組織的靈活度,具體涉及五大核心能力,歷經三大關鍵階段。
我們發現,整車廠和主要高科技廠商在軟件研發方面的支出有明顯區別。
谷歌每年的軟件研發支出是320億美元,蘋果是220億美元,在所有統計對象中遙遙領先。在整車廠中,大眾汽車集團和旗下軟件公司Cariad的軟件支出最多,為每年35億美元;隨后是豐田,每年20億美元;梅賽德斯、斯特蘭蒂斯、寶馬、福特、通用等老牌整車廠,每年在軟件研發上的開銷大概在8億美元到15億美元之間。
我們留意到,Rivian、特斯拉和蔚來等初創車企,也致力于大力投入軟件研發,每年花在軟件上的錢分別是7.5億、6億和5.5億美元,甚至投入規模超過了部分傳統整車廠。
總體投入規模和車企銷量規模有密不可分的關系,這正是大眾和豐田作為全球汽車銷量前兩名,在軟件研發上的投入同樣領先行業的原因之一。因此,研發效率,也就是單輛汽車的軟件研發支出,是同樣值得關注的指標。
數據顯示,Rivian和蔚來的單車研發成本最高,都超過了1000美元,每輛車上的軟件研發成本分別是1500美元和1100美元。當然,這是因為兩家初創車企的銷量規模還比較小,在總體投入規模大的前提下,單車成本無法被攤薄。
更值得關注的信號是,傳統車企的單車研發成本高。比如梅賽德斯的單車軟件成本是750美元,寶馬是400美元,大眾汽車集團和旗下軟件公司Cariad的這一數字是350美元。
傳統整車廠的單車研發成本高,這背后有三個方面原因。
首先,傳統整車廠在新技術領域,尤其是軟件技術方面的投入和成熟度并不高,導致即使把軟件提到了企業戰略的高度,其在關鍵控制點還是會出現戰略不清、組織分工不明的情況。
以德系整車廠為例,新成立的軟件部門關鍵崗位人員往往還是以傳統汽車背景,甚至是硬件工程類背景為主,使得整個組織在數字化轉型、軟件技術開發相關的領域里決策失效。
另外更直接的影響也在于,軟件相關智能網聯功能的開發周期,在保證高可用性體驗和更新及時性的同時,無法與傳統硬件周期有效協同。這一系列的“運行不暢”可能會進一步造成產品管理、生產,乃至營銷體系的堵點,從而造成不可避免的管理成本。
我們在初創企業里面看到的精英團隊主義、明星產品經理主義,是以團隊的主觀能動性、組織的敏捷性和精英向的企業文化為前提的。針對這類企業,軟件研發投入高的原因主要還是對于自研比例的追求,還有前期“學費型”的投入過高。
以蔚來為例,其在軟件領域的組織能力形成也走過了相對較久的摸索期,深深體會到對于“想要何種數字化體驗”“軟硬件載體和環境選擇”“自研還是外采”“需要哪種研發協同組織”“招募哪類人才和如何激勵”這幾個階段的從無到有,其實沒有捷徑可走。
其次,在市場需求理解層面,雙方也有區別。
傳統整車廠由于受到內部話語權和產品規劃設計流程機制影響,對客戶需求及其體驗水平缺乏系統化定義,尤其是創新功能與服務,個人主觀判斷仍占主導。
盡管普遍采取定期調研、第三方數據整合等做法大量采集數據,但用戶需求的盲點依然存在,且對所得數據的系統化處理、大數據分析能力等尚待提升。即使能夠在當前產品周期開始之前及時獲得了準確的客戶洞察,仍需要多部門高效地把洞察轉化為產品定義的需求,并整合到全生命周期管理的環節當中去。
最后,在合作伙伴層面,傳統整車廠的集采加整合的路徑,在數字化軟件領域不再適用,導致不得不重新摸索全新生態環境下,與軟件開發商、內容和數字化服務提供商的合作模式。這就意味著全新的供應商體系搭建,包括能力評估要求、合作框架,甚至數字信息的合規化運營。而每一項變革都會給廠商帶來額外的運營成本。
對于大部分日系、美系及部分歐洲整車廠而言,軟件研發投入比例還沒有那么顯性的原因,或許是在于各廠商的戰略野心與實際落地方案之間的平衡,雖然耗時,但事實上大部分整車廠還是更愿意“想清楚再干”。

注:關鍵假設包括:梅賽德斯的數據是MB.OS 2.0;每輛車的數據是基于2021年單位銷量計算的,但蔚來汽車和Rivian除外,這兩家車企的數據是基于2026年共識預測僅研發支出-沒有關于硬件采購成本的假設。資料來源:科爾尼 制圖:顏斌
因為在搭建軟件能力和數字化產品體系的同時,務必會帶來更多與終端客戶的數字觸點,如何規整這些觸點的體驗,讓其能夠傳遞一致的品牌信息與調性,并讓這些額外產生的數字交互為己所用。
這樣往小了說,能夠承接各條線的業務目標和戰略,比如網絡直銷帶來的增量銷量,和用戶社區帶來的用戶黏性;往大了說,就能加速拉動整體研發組織的數字化轉型,比如設計與測試階段的仿真應用,更進一步打通軟硬件周期、賦能技術創新。
以此為愿景,我們可以預期接下來很長一段時間內,這些后發制人的整車廠或許會出現更高比例的投入支出。
目前應用V模型進行軟件開發是整車廠的主流,也是A-SPICE(Automotive Software Process Improvement and Capability)這一汽車行業廣泛應用的軟件開發體系的基石。
V模型將軟件開發過程中的技術要求、需求分析、開發以及測試環節以V形排布。從整體到架構層,到系統層,到功能層進行需求分析,再開始開發,待開發工作完成后,又逐層向上從功能測試,到系統測試到整車測試認證,以及系統集成工作。
通過應用該模型,汽車整車廠可以一步步深化拆解分析需求,在開發后,又能夠自下而上的層層驗證測試。該模型能夠很好滿足車企對于大型復雜系統和軟件的管理需求,因而得到了歐美系車企的大力推廣和應用。自A-SPICE于2005年發布以來,越來越多汽車整車廠不僅在自身的研發部門需要使用,甚至開始要求其Tier1一級供應商在進行軟件交付時也要應用V模型并符合A-SPICE的標準。
但問題是,傳統的V模型軟件開發太過復雜龐大,在應對靈活多變的客戶需求時,顯得冗長拖沓。隨著中央計算架構的不斷發展,以及OTA的逐漸普及,終端功能性應用的日益增多,整車廠也越來越多地需要快速迭代軟件版本,以滿足客戶需求,同時在與其他車企競爭中能夠保持領先一步。
舉例來說,一個完整的V模型開發過程,通常需要12個-18個月的時間,而軟件更新在V模型下也需要3個-6個月的時間,而這顯然是無法滿足客戶需求的,因此整車廠開始引入敏捷開發(Agile)模式,希望能夠在部分需要快速迭代的軟件功能開發上,實現對消費者需求的快速滿足。
何為敏捷開發?這是一個閉環的開發流程模型,從規劃、代碼、編譯打包、測試、發布、部署,到反饋,調整持續改進,并最終回到規劃環節。
可以看出該模型的特點在于以客戶為中心,持續獲得反饋,持續改進;由于不像V模型那樣每次都將收集獲得的全部需求統一分析處理,而是分布式漸進式的逐步改進調整,因此其軟件開發以及版本迭代的時間也被大幅縮減。
V模型和敏捷模型這兩種開發體系,在適用軟件特性、開發時間、靈活度以及對客戶需求的反應速度上存在差異。比如敏捷模型更多應用于智能駕駛艙、互聯網等相關應用,而關于動力總成、電池等仍然需要依照V模型,其中具體功能可通過敏捷方式迭代。

資料來源:科爾尼
長期來看,兩者會共存,也因此整車廠需要熟練掌握這兩類開發體系。
對于V模型,各個整車廠近年來已經有了較多的應用;對于敏捷模式,由于是從高科技行業引入,傳統整車廠還需要進一步掌握該流程的使用,而具有互聯網基因的新興整車廠如特斯拉、“蔚小理”(蔚來、理想、小鵬)等,已經能夠比較好的應用該模式進行開發工作。
根據敏捷開發模型的特點,我們分析了從開發測試到部署再到改進優化的端到端流程,并提煉出了實現卓越開發的15個賦能手段,幫助整車廠更好地實現敏捷開發。
15個階段的賦能手段可以根據整車廠對敏捷開發的應用熟練度分為三個階段,分別是“敏捷軟件開發能力建設”“敏捷軟件開發可規模化擴張”以及“敏捷軟件開發成為戰略優勢”。
其中第一階段可謂重中之重,是二、三階段順利開展的先決條件,整車廠需要在第一階段夯實能力基礎,包括以功能為導向的敏捷開發、以功能為導向的軟件設計與架構、關鍵人才賦能的軟件開發、端到端測試與集成的自動化更新機制和已售出車輛的持續更新與集成流程,后續才能在中長期的第二、三階段發揮優勢。
接下來我們會重點分析第一階段的五大措施。
第一,以功能為導向的敏捷開發,意味著在代碼階段就需要一個以功能為導向的敏捷開發組織,其人員一般來自于傳統的部門架構,由業務單元高層管理人員、工程與軟件團隊的核心人員以及開發工程師組成,但其工作方式則以功能開發為導向。
在職能分工上,不再強調人員在企業內的上下級匯報關系,而是會設定一個核心領導負責項目規劃、時間計劃以及功能集成,其他人員則包括:系統經理負責項目預算及資源調配,測試工程師負責驗證,軟件硬件工程師負責軟硬件需求分析、方案設計與集成,客戶需求服務工程師負責分析客戶需求及其解決方案規劃,制造工程師負責在硬件制造方面的需求對接與系統集成。該團隊在敏捷開發的規劃階段一起工作,然后將并行開展開發和集成與測試工作。
這樣的工作方式可以最大化地實現以客戶需求為導向,以產品為核心的開發,以及成本高效的持續迭代。
第二,除了開發團隊,也需要在代碼階段考慮以功能為導向的軟件設計與系統架構。中央計算架構在此則起到了重要的作用。現今雖然中央計算架構被各大車企反復提及,但真正得到實際量產應用的平臺并不多,以特斯拉為例,其中央架構涵蓋了目前與客戶感受最相關的自動駕駛域、座艙娛樂域以及網絡安全與車聯網域。基于此設計,可以將軟件需求拆解為上車軟件以及后臺軟件,通過網關實現交互。
這樣的中央平臺架構可以實現通用的軟件設計,并且能夠應用一個軟件版本去覆蓋大多數在售車型。綜上所述,有中央平臺架構做基礎,通過高成本性價比的架構、高通用性的軟件,以及基于不同平臺定制化的模塊軟件,能夠幫助整車廠實現卓越的敏捷開發。
第三,需要在人才層面進行儲備、培養與賦能,并建立起與之匹配的人才機制,進行關鍵人才賦能的軟件開發。
在人才儲備層面,需建立起完善的招募與培養機制來保證具有全局觀或是具備某個模塊專長的技術人員儲備——包括整車系統層面、應用層面、車聯網方向、移動端開發方向等。
在授權管控層面,創建扁平化的決策委員會機制,并充分考慮技術因素與決策的敏捷性。決策委員會成員以各BU主要負責人和技術領導人作為主導,其他各相關方輔助配合,保證決策會議有效記錄,會議結果的輸出是產品特征優先級排序。
在賦能機制層面,充分賦予每一位工程師參與產品建議的權利,充分調動每一位技術人員的積極性,以保證全員參與到產品提升的過程中。
這樣的人才機制能夠大大提高流程效率。通過將決策權交給真正有能力的工程師,能夠最大限度地發揮人才潛力;通過扁平化和高效率的決策流程能夠快速應對消費者反饋與市場變化。
第四,建立端到端測試與集成的自動化更新機制。持續集成和持續交付需要快速完成計劃、編碼、測試、發布的循環,自動化的測試和自動化的發布是不可或缺的組成部分。而這一過程應用于每一次提交,意味著每一次代碼的提交、合并都會經過自動化的測試,成為一個新的發布版本。
以特斯拉為例,在硬件、系統與整車層面建立平行測試機制,依托Jenkins開源軟件工具創建自動化的測試體系,在每一次軟件版本更新迭代后自動觸發。依次通過軟件虛擬模擬、真實/虛擬外設環境下的硬件測試、真實外設環境下的系統測試、整車系統測試、真人道路測試環節,其中硬件、系統與整車層面的全部測試能夠在20小時內完成,從而使得全部測試時間控制在24小時以內。
這樣的自動化測試機制提供了一個全自動的中心化測試機制,使得全部測試與集成能夠在24小時內完成,并且可以在無需更改已經通過驗證的功能下完成自動化更新。
第五,對于已售出車輛的持續更新與整合也是卓越開發的重要一環。根據軟件開發的分支管理模型,分別按照軟件開發、軟件測試和已售管理三個典型分支進行(實際可能存在更多分支),并對應單一的數據存儲庫。
以特斯拉為例,對于開發分支而言,在軟件構建階段保證每周200次的更新,以及測試與集成階段每周7次更新和15%的完成率;對于測試分支,在軟件構建階段保證每周30次的更新,以及測試與集成階段每周14次更新和50%的完成率,以及在現場部署階段每周0.5次更新;對于客戶分支,在軟件構建階段保證每周20次的更新,以及測試與集成階段每周10次更新和80%的完成率,以及在現場部署階段每周3次更新。
這種已售車輛的更新與集成模型以模塊化發布的方式進行,能夠根據發布的準備成熟度來保證集成或是排除某一特定功能,并使得功能分支在單一的存儲庫中隨時更新,尤其是對于已售車輛的客戶端功能保持在80%及以上部署完成的狀態。
經過敏捷模型第一階段的發展,整車廠將完成向敏捷軟件開發的初步轉型,并形成以下五大核心基礎能力,為“敏捷軟件開發可規模化擴張”(第二階段),以及“敏捷軟件開發成為戰略優勢”(第三階段)奠定堅實基礎:
1.以客戶需求為導向、軟件功能為核心、貫穿規劃-開發-集成與測試環節的敏捷組織架構。確保全員圍繞敏捷開發為核心愿景,進行全鏈路資源的長期合理分配。
2.基于中央平臺架構的模塊化、通用化、定制化軟件設計體系。以優異的性價比和適配性助力整車廠實現規模化擴張。
3.軟件人才的長期儲備、培養與賦能體系。激發精英人才潛力,提高流程效率,持續保障產品競爭力,并為最終實現敏捷軟件開發戰略優勢提供長期人才支撐。
4.高效的端到端、全自動、中心化測試與更新機制。大幅縮短軟件更新迭代周期,形成以市場敏捷應對為核心的軟件開發戰略優勢。
5.模塊化的已售車輛軟件持續管理與更新機制。基于功能成熟度匹配最合理的發布周期,有效平衡功能部署完成率與優質的客戶使用體驗,降低已售車輛管理復雜度,以實現更為快速、平穩的規模化擴張。
(作者是科爾尼全球合伙人、董事、項目經理和咨詢顧問;編輯:王靜儀)