關于復雜汽車軟件bug管理的簡單思考和探索

項目逐漸上線，最近我又深陷在bug中，不能自拔。

這種不能自拔有兩層意思，第一層是難以自拔，因為尤其在后期，大多數人的大多數精力都集中在bug上，寫bug，測bug，分bug，數bug，解bug，而第二層是不愿自拔，畢竟，追著條理分明的bug去做事，相對簡單，也相對體現價值......

如果要問，現如今的汽車軟件項目的top 5關鍵詞是哪些？其中，必然少不了bug，甚至在項目中后期，說bug牽引著項目的運轉，都不算過分。

這篇文章會做一個簡單思考和探索。

最好的過程——bug管理

雖然不能自拔，但從研發管理的角度，我對bug的評價和印象都還算不錯，bug的管理基本算是目前汽車軟件開發過程的最好典型，無論是過程規范度上，還是數字化程度上，或者協同合作度上。

總結下來，原因大抵有以下3個：

1.1 前景效應與軟件增多

前景效應是一種行為心理學模型，就是說大多數人面對獲利時是風險規避的，所謂落袋為安，見好就收。

對于bug，早期規范管理、優化設計及測試前移可能會降低后期bug的發生概率，這是潛在的獲利，但不做這些活動就能立馬減少工作量和加快交付速度，這是明確的獲利。

也就是說，對比當下明確的獲利和未來即便更多的潛在獲利，大家還是傾向于前者，這在當下這種“長期主義者”有可能活不過今年的內卷環境里，尤其如此。自然而然，bug會在中后期暴露不少。

此外，汽車上的軟件越來越多，軟件bug也自然越來越多，體現在實際項目中數量也是非常明顯的，以前傳統ECU的開發，量產交付時，bug清零似乎是一個常規要求，但現在，遺留幾十、幾百、上千的bug逐漸成為不可避免的常態。

大量的bug就為bug管理提供了充足的原料。

1.2?汽車軟件bug很復雜

汽車軟件不是單一的，bug經常也就不是單一問題，尤其在如今各種跨模塊、跨系統、跨域功能定義的架構下，一個bug可能是多個ECU共同造成的，至少需要調查多個ECU之后才能有定論。

即便聚焦到一個ECU，還會分多個軟件模塊，仍然需要層層分析。此外，汽車軟件有時涉及的不單是軟件問題，還會有來自算法、標定、硬件甚至機械結構的耦合影響。

這種技術復雜性又給了好好管理bug的必要性。

1.3?汽車軟件bug涉眾多

bug的復雜主要是技術層面的復雜，技術復雜的簡化方式就是打散與拆分，但拆分后一定會涉及到眾多的人，眾多不同職能的人。

諸如工程、質量、生產、市場等，不同職能就會有不同立場，不同立場就會將技術問題推波助瀾為政治問題，而一旦成為政治問題，如何解決就有了多種思路。

這種涉眾復雜性繼續給bug順暢流轉與信息透明提出了要求。

這是汽車軟件bug管理目前的背景，似乎被迫促成了bug管理成為一個比較好的典范。

但是，這不妨礙bug依然是開發的痛點，所以，我們仍然有必要繼續深入探討一些優化的方向。

problem與bug

考慮到以上所講的汽車軟件的特點，我們可以嘗試另外一種更系統化且更精細化的思路。

首先，我們先建立兩個概念：problem（問題）與bug（缺陷）。

probIem是指產品發生了與預期不符合的行為，面向項目、面向系統、面向整車、面向發現問題者，還處于汽車管理維度。

bug是指技術層面的偏差，面向組件、面向子系統、面向軟件、面向解決問題者，已經落于軟件工程維度。

bug作為細化子項來服務于粗化的父項problem，二者可以是n對n的關系。

這種拆分至少有3個好處，主要體現在解耦上：

將造車與軟件解耦，讓學科復雜的造車活動與學科單純的軟件互不干涉。

將管理與工程解耦，讓心思復雜的管理者與心思單純的工程師各司其職。

將軟件與軟件解耦，讓負責不同軟件但都與這個problem相關的人員并行推進（有時也涉及硬件等）。

當然，這種拆分也是有前提的：

組織足夠大

problem足夠復雜

角色拆分足夠細

ALM工具足夠友好

如果只是解決一個小開發團隊自己測試發現的問題，去區分problem與bug的意義就弱了很多。

有一天，problem發生了......

理論上，所有人都可能遇到與預期不符的產品表現，例行測試自然會遇到，開發、驗收、試駕、生產、售后等環節也都會，相應地，所有發現問題的人都可以去提problem。

當然，基于項目經驗，基本會集中在PM、測試這兩類領外面問題和提內部問題的角色上。

還要注意，problem 的提出還要盡量滿足兩個原則：顆粒度要大（涵蓋范圍廣）、視角要面向價值，以避免提出太多瑣碎且信息重復的小問題，讓人陷入這問題戰爭的汪洋大海中，problem的存在就是要具備牽引作用，這在如今功能與問題都多的座艙類產品里頗有必要，一種思路是面向大的feature來識別problem。

當問題需要提出時，其具體內容的撰寫及流轉也并不容易，一般至少要反映如下基礎內容：

問題整體描述：這多少有點考驗語文功底，最好一句話能說完，而且僅從一句話中能理解應該怎么樣實際怎么樣，也就是準確的問題點是什么。基本原則是描述便于在組織內、項目內傳遞。

問題發生組織：現在很多汽車軟件都是多方跨組織協同開發的，如果站在供應鏈的維度看一個復雜問題，就有必要知道問題所處的組織層級，是主機廠，是Ter1，是第三方軟件，還是芯片，或者軟件平臺提供方。當問題跨組織時，往往會涉及不同的流程體系要求。

問題發現階段：這個是從V鏈條的角度看的，看問題是在從代碼到整車售后的整個開發周期中的哪個階段，不同階段的問題自然面對不同的相關方，也有不同的處理策略。

問題等級：通常，我們可以從產品本身嚴重度（如涉及法規、政治、功能安全、客戶高抱怨的都算比較嚴重）和項目推進的時間優先級這兩個視角來評價等級，但實際判斷時基本是糅合在一起的，高嚴重度問題經常也就是高優先級。一般會有3~5個級別劃分，這在統一組織溝通語言和標準化流程上多有裨益。比如，不同嚴重度的問題需要不同的分析反饋周期。

責任方：責任方可以區分為團隊和個人兩個顆粒度，團隊責任方用于團隊績效整體評價或者打包管理，個人責任方是一個問題具體推進的負責人。因為problem經常面向交付，所以由PM類角色主要負責是一種選擇。

時間信息：各類時間要求或時間戳對于定義問題目標和分析問題都有幫助，一般有截止日期、計劃日期，發生日期，提出日期等等。

輔助信息：對于proplem，重點放在提出上，重點也就是講清楚、講完整，除了常規的預期結果、實際結果、發生環境、軟硬件版本信息，還可以提供整車表現或模式（如儀表燈、電源模式等）。另外，總線或ECU內部的日志數據以及視頻、錄音、照片也都是后續分析的重要資料。

分析與解決信息：針對一個problem，整體的分析情況和最終結論當然也是關鍵信息，可能分析后認為不是problem要拒絕，或者雖然是 problem但可以偏差許可，再或者確實是problem也需要修復。無論如何，都要有較為明確的書面記錄。

狀態變更：problem的狀態沒必要設置得非常復雜，整體分為新建、分析中、solution已獲取、solution已導入、已關閉這幾大類即可。

其他驅動：在汽車行業，有時候也會驅動出8D、DFMEA、LLs等其他工作，具體要視problem本身的重要性與復雜性來決定。

總體來說，我們可以把problem視為與汽車軟件有關的問題，側重于通過管理的手段解決汽車或者說系統的問題。

從problem進入bug

當系統性問題problem被提出后，就非常需要系統架構師、系統工程師、軟件專家或者具備系統知識經驗的角色對其進行初步分析和任務分配。

當然，有時將problem第一分析人交給受直接影響的某具體軟件模塊或feature owner，或許效率會更高。

而具體的分析與分配結果就可以通過一到多個bug 來體現，bug就會開始作為子項服務父項proplem的解決，從這里開始真正進入軟件bug的解決。在這里，有時候也需要將已有的其他bug與problem建立聯系，以聚攏問題與資源。

從提出者來對比，problem屬于問題發現者提出，bug則為問題（缺陷）解決者提出。

此外，在bug的具體推進上，除了和problem類似的信息類別，bug需要在root cause分析與solution識別上著墨更多，也要更技術、更軟件、更翔實，包括但不限如下內容：

缺陷產生的細節：什么狀態機階段、什么模式、哪個配置、什么特定手順用例、違背了哪一條需求或設計要求以及底層技術機理是什么......

缺陷影響到的工件：諸如軟件組件、各類文件版本等，這些都屬于缺陷的一部分，都需要統一維護并服務于problem的關閉。

缺陷帶來的影響：評估的維度可能包括法規、安全、功能、下游測試、產線下線、消費者抱怨以及相關項目或產品線等，盡管這塊內容本身不算那么軟件，但只有深入到一定的軟件技術深度，才能對影響有較深的理解，這些內容也將決定problem的應對策略，所以，在bug分析階段，更high-level的系統層級角色仍然需要參與或提供信息。

臨時與長期措施：面臨項目或下游客戶的壓力，有時需要給出臨時的權宜之計，或者叫臨時措施，以解決當下交樣、造車、測試等緊急需求。隨后，在相對寬裕的時間里再完成長期措施的導入。

缺陷驗證情況：驗證方式、測試用例、測試結果等相關信息也應有所體現，以明確缺陷確實被修復。

缺陷引入階段：這部分信息算是經驗復盤，識別出到底是需求沒澄清，還是設計不合理，或者程序員碼代碼粗心，又或者是平臺問題的傳遞，這都有助于后續的持續改善。

詳細風險評估：如果該bug面向的problem很嚴重且無法及時修復集成，詳細的風險評估或許是必要的，這可能會涉及到FMEA的詳細評估、PPM的計算、特定用例的測試等等。

狀態變更：不同于problem，bug的狀態可以更軟件些，通常可以按照軟件開發的過程來標記，比如，新建、分析中、root cause已識別、編碼中、代碼評審、已集成、已測試、已關閉等。

當所有子項 bug被關閉后，父項problem就可以被關閉交付了。

可能的挑戰

挑戰無處不在，對于以上的想法，在如今的現實中，我們更可能面臨如下挑戰：

問題太多，沒有精力去進行這類層級梳理。

項目緊急，沒有時間去做這種規范操作。

產品復雜，沒有能力整體分析problem的定義及與bug的關系。

信息雜亂，沒有渠道串聯對齊各級信息。