出品 | 汽車電子與軟件
前言
當甲方要求“交出所有文檔”時，你真的準備好了嗎？
在汽車行業，有一個經典場景：主機廠（甲方）向零部件供應商（乙方）索要某個樣件的配置項管理清單，乙方發給甲方一份Excel表格，而當甲方想進一步查看表格中對應的文檔及其相關的評審記錄、基線記錄時，乙方苦笑著翻開一個包含數百個文件的文件夾，里面堆滿了評審記錄、變更日志、基線證明……
ASPICE中的配置管理（Configuration Management, CM）究竟是一套嚴謹的研發規范，還是變成了“文檔游戲”的代名詞？
到底什么是配置管理？
先忘掉那些翻譯腔
ASPICE 3.1的官方文檔上寫的是：
配置管理過程的目的是:，建立和維護過程或項目的所有工作產品的完整性，并使其對受影響方可用。
The purpose of the Configuration Management Process is to establish and maintain the integrity of all work products of a process or project and make them available to affected parties.
說人話就是：在車載系統開發過程中，要時時刻刻記錄完整的工作產物。
那工作產物是啥？
對整車廠而言，是車，對零部件廠商而言，則是整個零部件，包含了軟件和硬件的部分。
為什么要記錄工作產物的完整性？
這個也比較好理解，比如供應商A給主機廠B供應了一個版本的零部件，比如C樣，那么主機廠需要知道，這個C樣，是基于哪些需求文檔、哪些測試用例實現的，交過來的是哪個軟件版本、硬件版本。這樣主機廠才能一清二楚，方便主機廠后續去做驗證、集成，以及進一步開發。
到此為止，我覺得都是比較合理的要求。
但為什么，今天的配置管理變成了“文檔收割機”？
我們用一個V模型場景來實際還原一下：
需求階段
乙方寫了《泊車系統需求規范》v1.0，評審發現5個問題，修改后v1.1。
架構階段
基于v1.1，架構師輸出《軟件架構設計》v2.0，評審發現3個問題，修改后v2.1。
測試階段
測試工程師基于v2.1寫《系統測試用例》v3.0，發現需求理解有偏差，回溯修改需求到v1.2，再回到測試用例v3.1。
此時，甲方要求乙方交付C樣件，配置項清單需要提供：
需求v1.2 + 評審記錄（含5次問題閉環）
架構v2.1 + 評審記錄（含3次問題閉環）
測試用例v3.1 + 評審記錄（含2次迭代）
變更請求單 + CCB會議紀要 + 影響分析
代碼、編譯報告、刷寫腳本、標定數據……
工程師算了一筆賬：一份需求文檔，衍生出至少12份附屬文檔。
一個ECU項目平均200份需求，就是2400份文檔。
一個項目2000人天，其中80%在寫這些“證明你媽是你媽”的材料。甲方收到的文檔堆中，90%是“形式合規”，而非“實質合規”。
相信聰明的讀者已經看出來了，上述問題最簡單的“解決方法”就是，在評審記錄里面，全部標記為通過，文檔至少少了一半。這也是目前最常見的方法（手動狗頭）
但實際開發項目，研發文檔都是一次寫對的？評審一次全通過？這樣的團隊，別說12個月造車了，我覺得6個月都有可能。
甲方的“信任危機”
與乙方的“形式主義”
甲方要求乙方提供全部過程文檔，既是對乙方研發能力的信任缺失，更是對自己真正需要什么的定位不清。
這種信任缺失，無可批判，因為即使在一家公司內部，也有部門墻，部門與部門之間也有自身的利益沖突，互相不信任天然存在，更不用說甲方與乙方呢？大家都不是好哥倆兒。
不過，對于自己真正需要什么，甲方需要想清楚。
從上面的分析也可以看出，甲方所要求的正向研發、合規、追溯性，其實更多已經淪為了形式文檔。
而他真正需要的“產品”，在如此繁雜的文檔要求下，事實上，質量大打折扣。
舉個例子，某供應商在ASPICE評審中，將需求評審記錄中的問題數量從10個“優化”為0個，評審結論直接標注“一次性通過”。甲方雖存疑，但因缺乏技術能力深入核查，最終驗收通過。
我嘗試來猜測一下甲方的真正訴求：
確保C樣件和上一次交給乙方的需求一致
出了問題，乙方能快速定位
乙方流程合規、可信，滿足汽車行業規范
如果甲方想用“文檔完整性”來代償“流程可信度”，實際上是在蒙著眼睛，糊弄瞎子呢。文檔越多，可信度越低——因為工程師開始“批量通過”評審記錄，CCB會議紀要，有一份固定模板，只需要改日期即可。
解決方案：
從“寫文檔”到“做產品”
配置管理的核心不是“堆積文檔”，而是通過工具鏈自動化和流程可信度設計，讓甲方無需查看所有文檔，也能信任乙方的能力。
解決方案：
工具鏈自動化：
使用研發管理ALM工具自動生成版本記錄、基線化證明、評審日志等等，減少人工干預。
流程可信度設計：
通過標準化的評審流程、CCB（變更控制委員會）機制、問題跟蹤閉環，確保每次變更都有跡可循，這些變更在系統中自動生成，無論是甲方還是乙方，都無法修改，甲方自然而然可以相信這些記錄。
用抽查代替全部文檔交付：
隨時抽查乙方提供的任何一份文檔在工具鏈系統中的正向研發、可追溯性、評審、基線等等，而避免讓乙方一次性將這些文檔全部導出，進行整理。
案例：某Tier 1廠商的文檔交付實踐
某頭部Tier 1廠商通過工具鏈整合，使用一站式的研發平臺ALM，每次交付時，除了交付最終定稿的研發文檔之外，過程文檔都留存在乙方研發系統中。甲方通過平臺可實時查看：
當前版本的基線狀態
所有變更的審批記錄
問題跟蹤的閉環狀態
最終，甲方只需點擊幾下鼠標，即可驗證合規性，無需接收紙質文檔。
敏捷開發強調“快速迭代、最小化文檔”，而ASPICE要求“過程合規、可追溯”。兩者的沖突看似不可調和，但核心目標一致：交付高質量、可驗證的產品。
融合路徑：
以產品為核心：
敏捷團隊在開發過程中，最小化地寫下實現的feature、story、task的ticket，由工具鏈自動組裝成完整的文檔，并完成版本管理、基線管理、變更評審等相關的功能。
輕量化文檔：
用自動化工具生成評審記錄、變更日志，避免人工撰寫冗長文檔。同時，借助AI工具，快速生成文檔框架，在此基礎上進行修改，節約至少50%人力。
寫在最后
給甲方的三句話
你要的不是文檔，是可控性。
可控性可以通過工具鏈+抽查實現，而不是通過文檔堆疊。
你要的不是歷史，是此刻的確定性。
交付基線就是此刻的確定性，歷史版本留在工具系統上，需要時再查。
你要的不是流程，是結果。
如果C樣件在臺架上跑不過測試，給你1000份文檔也沒用。
給乙方的三個行動
今晚就把ALM上線提上日程，沒有工具鏈，線下用Word、Excel實現這一切，除非你愿意把團隊規模擴大一倍，另一半人專門寫文檔。
明天和甲方開一次對齊會，重新定義“交付基線”的范圍，把歷史版本、評審記錄等，從交付清單里刪掉。
下周把CCB會議從線下搬到ALM，讓每一次變更都有跡可循，但不必每次都打印出來。
羅宇超，云體科技創始人，前蔚來汽車軟件質量工程師，工具鏈工程師。
