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

這種不能自拔有兩層意思，第一層是難以自拔，因?yàn)橛绕湓诤笃?，大多?shù)人的大多數(shù)精力都集中在bug上，寫(xiě)bug，測(cè)bug，分bug，數(shù)bug，解bug，而第二層是不愿自拔，畢竟，追著條理分明的bug去做事，相對(duì)簡(jiǎn)單，也相對(duì)體現(xiàn)價(jià)值......

如果要問(wèn)，現(xiàn)如今的汽車(chē)軟件項(xiàng)目的top 5關(guān)鍵詞是哪些？其中，必然少不了bug，甚至在項(xiàng)目中后期，說(shuō)bug牽引著項(xiàng)目的運(yùn)轉(zhuǎn)，都不算過(guò)分。

這篇文章會(huì)做一個(gè)簡(jiǎn)單思考和探索。

1

最好的過(guò)程——bug管理

雖然不能自拔，但從研發(fā)管理的角度，我對(duì)bug的評(píng)價(jià)和印象都還算不錯(cuò)，bug的管理基本算是目前汽車(chē)軟件開(kāi)發(fā)過(guò)程的最好典型，無(wú)論是過(guò)程規(guī)范度上，還是數(shù)字化程度上，或者協(xié)同合作度上。

總結(jié)下來(lái)，原因大抵有以下3個(gè)：

1.1 前景效應(yīng)與軟件增多

前景效應(yīng)是一種行為心理學(xué)模型，就是說(shuō)大多數(shù)人面對(duì)獲利時(shí)是風(fēng)險(xiǎn)規(guī)避的，所謂落袋為安，見(jiàn)好就收。

對(duì)于bug，早期規(guī)范管理、優(yōu)化設(shè)計(jì)及測(cè)試前移可能會(huì)降低后期bug的發(fā)生概率，這是潛在的獲利，但不做這些活動(dòng)就能立馬減少工作量和加快交付速度，這是明確的獲利。

也就是說(shuō)，對(duì)比當(dāng)下明確的獲利和未來(lái)即便更多的潛在獲利，大家還是傾向于前者，這在當(dāng)下這種“長(zhǎng)期主義者”有可能活不過(guò)今年的內(nèi)卷環(huán)境里，尤其如此。自然而然，bug會(huì)在中后期暴露不少。

此外，汽車(chē)上的軟件越來(lái)越多，軟件bug也自然越來(lái)越多，體現(xiàn)在實(shí)際項(xiàng)目中數(shù)量也是非常明顯的，以前傳統(tǒng)ECU的開(kāi)發(fā)，量產(chǎn)交付時(shí)，bug清零似乎是一個(gè)常規(guī)要求，但現(xiàn)在，遺留幾十、幾百、上千的bug逐漸成為不可避免的常態(tài)。

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

1.2?汽車(chē)軟件bug很復(fù)雜

汽車(chē)軟件不是單一的，bug經(jīng)常也就不是單一問(wèn)題，尤其在如今各種跨模塊、跨系統(tǒng)、跨域功能定義的架構(gòu)下，一個(gè)bug可能是多個(gè)ECU共同造成的，至少需要調(diào)查多個(gè)ECU之后才能有定論。

即便聚焦到一個(gè)ECU，還會(huì)分多個(gè)軟件模塊，仍然需要層層分析。此外，汽車(chē)軟件有時(shí)涉及的不單是軟件問(wèn)題，還會(huì)有來(lái)自算法、標(biāo)定、硬件甚至機(jī)械結(jié)構(gòu)的耦合影響。

這種技術(shù)復(fù)雜性又給了好好管理bug的必要性。

1.3?汽車(chē)軟件bug涉眾多

bug的復(fù)雜主要是技術(shù)層面的復(fù)雜，技術(shù)復(fù)雜的簡(jiǎn)化方式就是打散與拆分，但拆分后一定會(huì)涉及到眾多的人，眾多不同職能的人。

諸如工程、質(zhì)量、生產(chǎn)、市場(chǎng)等，不同職能就會(huì)有不同立場(chǎng)，不同立場(chǎng)就會(huì)將技術(shù)問(wèn)題推波助瀾為政治問(wèn)題，而一旦成為政治問(wèn)題，如何解決就有了多種思路。

這種涉眾復(fù)雜性繼續(xù)給bug順暢流轉(zhuǎn)與信息透明提出了要求。

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

但是，這不妨礙bug依然是開(kāi)發(fā)的痛點(diǎn)，所以，我們?nèi)匀挥斜匾^續(xù)深入探討一些優(yōu)化的方向。

2

problem與bug

考慮到以上所講的汽車(chē)軟件的特點(diǎn)，我們可以嘗試另外一種更系統(tǒng)化且更精細(xì)化的思路。

首先，我們先建立兩個(gè)概念：problem（問(wèn)題）與bug（缺陷）。

probIem是指產(chǎn)品發(fā)生了與預(yù)期不符合的行為，面向項(xiàng)目、面向系統(tǒng)、面向整車(chē)、面向發(fā)現(xiàn)問(wèn)題者，還處于汽車(chē)管理維度。

bug是指技術(shù)層面的偏差，面向組件、面向子系統(tǒng)、面向軟件、面向解決問(wèn)題者，已經(jīng)落于軟件工程維度。

bug作為細(xì)化子項(xiàng)來(lái)服務(wù)于粗化的父項(xiàng)problem，二者可以是n對(duì)n的關(guān)系。

這種拆分至少有3個(gè)好處，主要體現(xiàn)在解耦上：

將造車(chē)與軟件解耦，讓學(xué)科復(fù)雜的造車(chē)活動(dòng)與學(xué)科單純的軟件互不干涉。

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

將軟件與軟件解耦，讓負(fù)責(zé)不同軟件但都與這個(gè)problem相關(guān)的人員并行推進(jìn)（有時(shí)也涉及硬件等）。

當(dāng)然，這種拆分也是有前提的：

組織足夠大

problem足夠復(fù)雜

角色拆分足夠細(xì)

ALM工具足夠友好

如果只是解決一個(gè)小開(kāi)發(fā)團(tuán)隊(duì)自己測(cè)試發(fā)現(xiàn)的問(wèn)題，去區(qū)分problem與bug的意義就弱了很多。

3

有一天，problem發(fā)生了......

理論上，所有人都可能遇到與預(yù)期不符的產(chǎn)品表現(xiàn)，例行測(cè)試自然會(huì)遇到，開(kāi)發(fā)、驗(yàn)收、試駕、生產(chǎn)、售后等環(huán)節(jié)也都會(huì)，相應(yīng)地，所有發(fā)現(xiàn)問(wèn)題的人都可以去提problem。

當(dāng)然，基于項(xiàng)目經(jīng)驗(yàn)，基本會(huì)集中在PM、測(cè)試這兩類領(lǐng)外面問(wèn)題和提內(nèi)部問(wèn)題的角色上。

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

當(dāng)問(wèn)題需要提出時(shí)，其具體內(nèi)容的撰寫(xiě)及流轉(zhuǎn)也并不容易，一般至少要反映如下基礎(chǔ)內(nèi)容：

問(wèn)題整體描述：這多少有點(diǎn)考驗(yàn)語(yǔ)文功底，最好一句話能說(shuō)完，而且僅從一句話中能理解應(yīng)該怎么樣實(shí)際怎么樣，也就是準(zhǔn)確的問(wèn)題點(diǎn)是什么。基本原則是描述便于在組織內(nèi)、項(xiàng)目?jī)?nèi)傳遞。

問(wèn)題發(fā)生組織：現(xiàn)在很多汽車(chē)軟件都是多方跨組織協(xié)同開(kāi)發(fā)的，如果站在供應(yīng)鏈的維度看一個(gè)復(fù)雜問(wèn)題，就有必要知道問(wèn)題所處的組織層級(jí)，是主機(jī)廠，是Ter1，是第三方軟件，還是芯片，或者軟件平臺(tái)提供方。當(dāng)問(wèn)題跨組織時(shí)，往往會(huì)涉及不同的流程體系要求。

問(wèn)題發(fā)現(xiàn)階段：這個(gè)是從V鏈條的角度看的，看問(wèn)題是在從代碼到整車(chē)售后的整個(gè)開(kāi)發(fā)周期中的哪個(gè)階段，不同階段的問(wèn)題自然面對(duì)不同的相關(guān)方，也有不同的處理策略。

問(wèn)題等級(jí)：通常，我們可以從產(chǎn)品本身嚴(yán)重度（如涉及法規(guī)、政治、功能安全、客戶高抱怨的都算比較嚴(yán)重）和項(xiàng)目推進(jìn)的時(shí)間優(yōu)先級(jí)這兩個(gè)視角來(lái)評(píng)價(jià)等級(jí)，但實(shí)際判斷時(shí)基本是糅合在一起的，高嚴(yán)重度問(wèn)題經(jīng)常也就是高優(yōu)先級(jí)。一般會(huì)有3~5個(gè)級(jí)別劃分，這在統(tǒng)一組織溝通語(yǔ)言和標(biāo)準(zhǔn)化流程上多有裨益。比如，不同嚴(yán)重度的問(wèn)題需要不同的分析反饋周期。

責(zé)任方：責(zé)任方可以區(qū)分為團(tuán)隊(duì)和個(gè)人兩個(gè)顆粒度，團(tuán)隊(duì)責(zé)任方用于團(tuán)隊(duì)績(jī)效整體評(píng)價(jià)或者打包管理，個(gè)人責(zé)任方是一個(gè)問(wèn)題具體推進(jìn)的負(fù)責(zé)人。因?yàn)閜roblem經(jīng)常面向交付，所以由PM類角色主要負(fù)責(zé)是一種選擇。

時(shí)間信息：各類時(shí)間要求或時(shí)間戳對(duì)于定義問(wèn)題目標(biāo)和分析問(wèn)題都有幫助，一般有截止日期、計(jì)劃日期，發(fā)生日期，提出日期等等。

輔助信息：對(duì)于proplem，重點(diǎn)放在提出上，重點(diǎn)也就是講清楚、講完整，除了常規(guī)的預(yù)期結(jié)果、實(shí)際結(jié)果、發(fā)生環(huán)境、軟硬件版本信息，還可以提供整車(chē)表現(xiàn)或模式（如儀表燈、電源模式等）。另外，總線或ECU內(nèi)部的日志數(shù)據(jù)以及視頻、錄音、照片也都是后續(xù)分析的重要資料。

分析與解決信息：針對(duì)一個(gè)problem，整體的分析情況和最終結(jié)論當(dāng)然也是關(guān)鍵信息，可能分析后認(rèn)為不是problem要拒絕，或者雖然是 problem但可以偏差許可，再或者確實(shí)是problem也需要修復(fù)。無(wú)論如何，都要有較為明確的書(shū)面記錄。

狀態(tài)變更：problem的狀態(tài)沒(méi)必要設(shè)置得非常復(fù)雜，整體分為新建、分析中、solution已獲取、solution已導(dǎo)入、已關(guān)閉這幾大類即可。

其他驅(qū)動(dòng)：在汽車(chē)行業(yè)，有時(shí)候也會(huì)驅(qū)動(dòng)出8D、DFMEA、LLs等其他工作，具體要視problem本身的重要性與復(fù)雜性來(lái)決定。

總體來(lái)說(shuō)，我們可以把problem視為與汽車(chē)軟件有關(guān)的問(wèn)題，側(cè)重于通過(guò)管理的手段解決汽車(chē)或者說(shuō)系統(tǒng)的問(wèn)題。

4

從problem進(jìn)入bug

當(dāng)系統(tǒng)性問(wèn)題problem被提出后，就非常需要系統(tǒng)架構(gòu)師、系統(tǒng)工程師、軟件專家或者具備系統(tǒng)知識(shí)經(jīng)驗(yàn)的角色對(duì)其進(jìn)行初步分析和任務(wù)分配。

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

而具體的分析與分配結(jié)果就可以通過(guò)一到多個(gè)bug 來(lái)體現(xiàn)，bug就會(huì)開(kāi)始作為子項(xiàng)服務(wù)父項(xiàng)proplem的解決，從這里開(kāi)始真正進(jìn)入軟件bug的解決。在這里，有時(shí)候也需要將已有的其他bug與problem建立聯(lián)系，以聚攏問(wèn)題與資源。

從提出者來(lái)對(duì)比，problem屬于問(wèn)題發(fā)現(xiàn)者提出，bug則為問(wèn)題（缺陷）解決者提出。

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

缺陷產(chǎn)生的細(xì)節(jié)：什么狀態(tài)機(jī)階段、什么模式、哪個(gè)配置、什么特定手順用例、違背了哪一條需求或設(shè)計(jì)要求以及底層技術(shù)機(jī)理是什么......

缺陷影響到的工件：諸如軟件組件、各類文件版本等，這些都屬于缺陷的一部分，都需要統(tǒng)一維護(hù)并服務(wù)于problem的關(guān)閉。

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

臨時(shí)與長(zhǎng)期措施：面臨項(xiàng)目或下游客戶的壓力，有時(shí)需要給出臨時(shí)的權(quán)宜之計(jì)，或者叫臨時(shí)措施，以解決當(dāng)下交樣、造車(chē)、測(cè)試等緊急需求。隨后，在相對(duì)寬裕的時(shí)間里再完成長(zhǎng)期措施的導(dǎo)入。

缺陷驗(yàn)證情況：驗(yàn)證方式、測(cè)試用例、測(cè)試結(jié)果等相關(guān)信息也應(yīng)有所體現(xiàn)，以明確缺陷確實(shí)被修復(fù)。

缺陷引入階段：這部分信息算是經(jīng)驗(yàn)復(fù)盤(pán)，識(shí)別出到底是需求沒(méi)澄清，還是設(shè)計(jì)不合理，或者程序員碼代碼粗心，又或者是平臺(tái)問(wèn)題的傳遞，這都有助于后續(xù)的持續(xù)改善。

詳細(xì)風(fēng)險(xiǎn)評(píng)估：如果該bug面向的problem很?chē)?yán)重且無(wú)法及時(shí)修復(fù)集成，詳細(xì)的風(fēng)險(xiǎn)評(píng)估或許是必要的，這可能會(huì)涉及到FMEA的詳細(xì)評(píng)估、PPM的計(jì)算、特定用例的測(cè)試等等。

狀態(tài)變更：不同于problem，bug的狀態(tài)可以更軟件些，通?？梢园凑哲浖_(kāi)發(fā)的過(guò)程來(lái)標(biāo)記，比如，新建、分析中、root cause已識(shí)別、編碼中、代碼評(píng)審、已集成、已測(cè)試、已關(guān)閉等。

當(dāng)所有子項(xiàng) bug被關(guān)閉后，父項(xiàng)problem就可以被關(guān)閉交付了。

5

可能的挑戰(zhàn)

挑戰(zhàn)無(wú)處不在，對(duì)于以上的想法，在如今的現(xiàn)實(shí)中，我們更可能面臨如下挑戰(zhàn)：

問(wèn)題太多，沒(méi)有精力去進(jìn)行這類層級(jí)梳理。

項(xiàng)目緊急，沒(méi)有時(shí)間去做這種規(guī)范操作。

產(chǎn)品復(fù)雜，沒(méi)有能力整體分析problem的定義及與bug的關(guān)系。

信息雜亂，沒(méi)有渠道串聯(lián)對(duì)齊各級(jí)信息。

問(wèn)題簡(jiǎn)單，沒(méi)有必要搞這么復(fù)雜。

6

設(shè)想一個(gè)場(chǎng)景

面對(duì)此間種種挑戰(zhàn)，我們可以多想一步。當(dāng)然，也不局限在problem或bug上了，我們?cè)O(shè)想一個(gè)理想的、包含bug管理在內(nèi)的汽車(chē)軟件開(kāi)發(fā)場(chǎng)景：

經(jīng)過(guò)精心研究的客戶需求形成統(tǒng)一的整車(chē)feature。

整車(chē)軟件feature與其他feature從管理上解耦。

整車(chē)軟件feature與各域、各子系統(tǒng)、各ECU通過(guò)各級(jí)sub-feature串聯(lián)。

各sub-feature與各域、各子系統(tǒng)、各ECU形成準(zhǔn)確映射關(guān)系。

各problem面向各feature。

各bug面向ECU中的軟件module。

以上內(nèi)容形成多個(gè)平臺(tái)，各車(chē)型或各項(xiàng)目從這個(gè)維護(hù)良好的“綠色”與“透明”的平臺(tái)上衍生釋放分支。

7

寫(xiě)在最后

在如今汽車(chē)向軟件轉(zhuǎn)型的過(guò)程中，bug是個(gè)重頭戲，大家沒(méi)得抓的時(shí)候，就抓bug，不知道該怎么辦了，還是抓bug，多少有些無(wú)奈......

審核編輯：劉清