熟悉的朋友都知道，我的聚焦點在于汽車軟件研發(fā)管理上，而企業(yè)專職研發(fā)管理的職能經(jīng)常落在質(zhì)量的角色上，但我很少專門寫這個角色的文章。

原因是，我始終覺得軟件質(zhì)量的“工夫在詩外”。不過，出于對這個職能的尊重，今天系統(tǒng)寫一篇，看這個活兒到底該怎么干？主要會分三大板塊：基本工作內(nèi)容、質(zhì)量管理水平階梯、行業(yè)對軟件質(zhì)量的要求。

1

基本工作內(nèi)容

第一部分純談理論。

軟件質(zhì)量保證的目的是提供獨立和客觀的證據(jù)，以證明產(chǎn)品和過程符合組織要求。質(zhì)量保證的工作主要分5大步驟：

1.1定義軟件質(zhì)量保證計劃

根據(jù)項目特定的質(zhì)量目標，準備軟件質(zhì)量保證計劃。

在項目計劃中安排質(zhì)量保證活動。

批準軟件質(zhì)量保證計劃。

1.2執(zhí)行過程軟件質(zhì)量保證活動

根據(jù)項目進度和軟件質(zhì)量保證計劃執(zhí)行過程合規(guī)性檢查。

按照軟件質(zhì)量保證計劃定義軟件質(zhì)量控制面板。

匯總過程檢查狀態(tài)和結(jié)果。

在特定的管理工具中記錄差距、確定行動項、責任人和截止日期。

1.3 執(zhí)行產(chǎn)品軟件質(zhì)量保證活動

根據(jù)項目變更級別、軟件項目計劃和軟件質(zhì)量保證計劃，定義軟件里程碑評審計劃。

召開軟件里程碑評審會議，團隊對最終紅黃藍評價達成一致。

匯總質(zhì)量閥檢查狀態(tài)和結(jié)果。

在特定的管理工具中記錄差距、確定行動項、責任人和截止日期。

1.4匯總和溝通質(zhì)量保證活動與結(jié)果

總結(jié)過程與產(chǎn)品質(zhì)量保證的結(jié)果，包括差距、行動項及行動項的最新狀態(tài)。

在相關的項目管理會議上，進行質(zhì)量狀態(tài)匯報或升級。

1.5確保行動項關閉

針對差距和行動項進行跟蹤直至合理關閉。

這是一套最基本的PDCA循環(huán)，邏輯也并不復雜，這也是前些年汽車行業(yè)軟件質(zhì)量一直以來的主流做法，但我們這么干夠嗎？

可以說，在如今內(nèi)卷到極致的汽車行業(yè)，幾乎沒有任何價值彰顯的空間，所以，一定需要拓展和進階。

2

質(zhì)量管理水平階梯

至于如何拓展，我們可能需要再次思考一下質(zhì)量管理的不同水平。按有效性遞增排列的5種質(zhì)量管理水平如下。

2.1第一級：客戶發(fā)現(xiàn)缺陷

通常，代價最大的方法是讓客戶發(fā)現(xiàn)缺陷。這種方法可能會導致?lián)�保問題、召回、商譽受損和返工成本。

第一級別屬于質(zhì)量的失職，不用多說。

2.2 第二級：檢測和糾正缺陷

控制質(zhì)量過程包括先檢測和糾正缺陷，再將可交付成果發(fā)送給客戶。該過程會帶來相關成本，主要是評估成本和內(nèi)部失敗成本。

第二級是常說的QC，遷移到軟件領域，通常是測試或修復bug。

2.3 第三級：質(zhì)量保證

通過質(zhì)量保證檢查并糾正過程本身，而不僅僅是特殊缺陷。

第三級就是QA，是我們最常說的軟件質(zhì)量的職能主體，也是我們第一部分論述的內(nèi)容，但當組織質(zhì)量文化比較差時，經(jīng)常會滑到第二級。

2.4 第四級：質(zhì)量融入

將質(zhì)量融入項目和產(chǎn)品的規(guī)劃和設計中。

第四級屬于頂層設計，這部分通常是我們對QA的進一步期待，但也要把質(zhì)量工作本身作為業(yè)務的一環(huán)。

2.5 第五級：質(zhì)量文化

在整個組織內(nèi)創(chuàng)建一種關注并致力于實現(xiàn)過程和產(chǎn)品質(zhì)量的文化。

第五級是最重要的，但比較玄虛，個體無法掌控。

所以，汽車軟件質(zhì)量本身應該要向第四級努力。

3

行業(yè)對軟件質(zhì)量的要求

努力需要有一些實實在在的方向，這部分會寫得最實在。

我收集了近三萬字的軟件質(zhì)量相關的JD（由于是招聘網(wǎng)站找的，可能會有重復的，但在多渠道發(fā)布也能一定程度上說明其緊缺程度和熱度，所以就不做去重處理），并對其關鍵詞進行了分析，或許略能代表現(xiàn)在這個圈子對于其的認識和要求，可作為各位方向上的參考。

直接看結(jié)果。

下面來逐一分析。

3.1體系/流程/過程

“體系/流程/過程”是數(shù)量最多的，很顯然，脫離于獨特問題，而針對體系進行系統(tǒng)性預防的質(zhì)量保證，依然是這份工作的主體。

流程&體系是我們的最主要的專業(yè)能力和工作對象，基礎不牢，地動山搖，首先要做一個公司內(nèi)對流程與體系最熟悉的人。

3.2 開發(fā)

第二個關鍵詞是“開發(fā)”，也是意料之內(nèi)的，畢竟在軟件整個生命周期內(nèi)主要著力點在開發(fā)階段的，不像機械產(chǎn)品SOP后會有老化損耗的問題，軟件可靠性更多地依賴開發(fā)設計。

3.3溝通/合作/協(xié)作/協(xié)調(diào)/組織

“溝通/合作/協(xié)作/協(xié)調(diào)/組織”高居第三位，比預想高一些。

仔細想來，也是合理的，質(zhì)量不寫代碼，也不做測試，不會給項目直接增值，卻還要挑毛病，溝通的能力和雙贏的情商就很重要了。

3.4評審/審計/審核/檢查/評估/度量

“評審/審計/審核/檢查/評估/度量”，不同角度的說法，但粗略理解就是“檢查”，質(zhì)量的來源就是檢查。到目前為止，檢查依然是主要的工作手段。

3.5 問題/風險

那么，“檢查“是檢什么、查什么呢，也只能是“問題/風險”了。

沒有它們，就不需要質(zhì)量。有人會說，質(zhì)量還要找到做的好的，不能只看差的，道理沒錯，有些情況確實會提好的，可是要是都是好的，就說明項目組已經(jīng)可以自驅(qū)動做好了，質(zhì)量作為支持角色的價值自然弱化，質(zhì)量不會這么做的，沒有驅(qū)動力。

3.6落地/推動/實施/執(zhí)行

做一個居高臨下、站著說話不腰疼的說教者，不光是做事的人不服，組織也不會允許，“落地/推動/實施/執(zhí)行”是組織對質(zhì)量的期望，養(yǎng)這些人不只是為了挑毛病，還要負責支持解決毛病，質(zhì)量最喜歡談的PDCA，最喜歡談的閉環(huán)，肯定也會被人要求在自己身上。

3.7改進/優(yōu)化/改善

當然，解決個例的、具體的問題還得是專業(yè)的人，質(zhì)量要更側(cè)重于從流程和體系層面解決，“改進/優(yōu)化/改善”這部分也正是體現(xiàn)質(zhì)量高階水平的環(huán)節(jié)了。就像8D有8步，但核心在Root Cause的分析上。

3.8ASPICE/CMMI

“ASPICE/CMMI”幾乎是比較具象的軟件質(zhì)量的代名詞了。

據(jù)我了解，汽車行業(yè)的軟件流程目前基本都在映射ASPICE（與CMMI一脈相承，在這里的統(tǒng)計中CMMI約占1/3），特別是Tier1&2迫于OEM的審核壓力，也在不停地進行相關部署、認證和宣傳。

質(zhì)量比較虛一些，ASPICE算是一個抓手，可以認真研究下。

3.9功能安全/ISO26262、敏捷/Scrum和ISO9001/16949

依次排后面的“功能安全/ISO26262”、“敏捷/Scrum”和“ISO9001/16949”也是抓手。

除了最后的“ISO9001/16949”，雖然是基礎，但太成熟，不用多講，ISO26262與敏捷和ASPICE的融合是一個非常重要的話題，值得深思。

此外，值得提的是IPD，雖然占比不多，但作為在華為獲得成功的流程，或許在汽車行業(yè)內(nèi)會是一個新鮮的視角。

3.10分析/總結(jié)、表達/語言/寫作/報告/匯報

“分析/總結(jié)”可以類比于醫(yī)生的手術刀、軍人的槍和作家的筆。日常實操中，我們要用“分析/總結(jié)”的頭腦工具處理獲取的“數(shù)據(jù)”輸入，然后，進行“表達/語言/寫作/報告/匯報”的輸出。

獲取數(shù)據(jù)、分析總結(jié)及匯報輸出這幾個環(huán)節(jié)是質(zhì)量日常工作模式，也可見出功底厚薄，尤其是匯報，通常也是質(zhì)量的權(quán)力與威望來源。

3.11 業(yè)務/研發(fā)

“業(yè)務/研發(fā)”，我覺得可以這樣理解，質(zhì)量很多時候都是理論的，但這不是質(zhì)量的目的，理論之后要結(jié)合實際業(yè)務，這和前面講到的落地是同一范疇的。

至于為什么把研發(fā)和業(yè)務放在一起，因為汽車行業(yè)里對于研發(fā)的理解比開發(fā)外延更大，會更接近于所謂的業(yè)務。

比如，ASPICE4.0相比較3.1，也擴充了硬件、結(jié)構(gòu)和機器學習，關注點不僅僅在（軟件）開發(fā)上了。

3.12 工具

“工具”這塊分了兩部分。

一部分是常規(guī)意義的質(zhì)量工具，或者叫方法論也行，比如，F(xiàn)MEA、FTA、MBSE、7大工具之類。

另一部分是數(shù)字化工作，現(xiàn)在大家都在推動數(shù)字化轉(zhuǎn)型，比如，Polarion、Doors、JIRA都屬于這一類。

特別對于軟件質(zhì)量，沒有數(shù)字化工具的支持，幾乎無法進行。

3.13 測試

“測試”這部分占比也較多，測試和質(zhì)量在識別問題的角度是一致的，質(zhì)量非常需要從測試專業(yè)的角度理解產(chǎn)品和項目，也非常需要和測試密切合作。

3.14 培訓/指導

“培訓/指導”不多擴展，對于流程的創(chuàng)立者、守護者和推廣者，自然需要這項技能。

3.15 意識

“意識”或者也可以稱之為質(zhì)量文化，極其重要，同時又極其虛，極其難建立，畢竟改變思想、改變意識談何容易，但是一旦真的能撼動這塊硬骨頭，就會是軟件質(zhì)量工作源源不斷的原動力。

再說一句，關鍵的是領導認可和組織有土壤。

3.16 認證/證書/PMP/ACP

“認證/證書/PMP/ACP”以及ASPICE PA、Scrum Master、內(nèi)審員等這類資格認證，就像是各種含金量不怎么高的證書。一句話，有比沒有強。

3.17 英語

雖說文化自信，這幾年國外文化輸入也有所淡化，但“英語”的重要性短期內(nèi)仍然是有的，特別是外企。

3.18 項目管理

“項目管理”的經(jīng)歷和意識對于做好質(zhì)量溝通有很大幫助，但確實不需要承受項目經(jīng)理那樣的“壓力”。

3.19 編程/C語言/JAVA

“編程/C語言/JAVA”排在了最后，大體可以說明這本身的技能至少不起決定性作用。當然，懂的話更好了。

對于數(shù)據(jù)的分析就這么多了，限于數(shù)據(jù)的有效性和分析的水平，結(jié)論未必精準，供參考，并歡迎討論。

4

全文小結(jié)

軟件質(zhì)量是個務虛的管理性工作，但切不可一直沉迷于務虛。所以，我們從虛到實，依次講了PDCA的基本工作套路、通過流程與體系保證質(zhì)量的理念以及行業(yè)對軟件質(zhì)量的理解。

5

寫在最后

在這個環(huán)境下，干務虛的活兒，最怕沉迷于務虛，虛虛實實，虛中一定要有實，不可不察。

完

       原文標題 : 汽車軟件質(zhì)量這個活兒到底該怎么干？