侵權(quán)投訴
訂閱
糾錯
加入自媒體

汽車軟件質(zhì)量這個活兒到底該怎么干?

2023-12-26 16:39
水輕言
關(guān)注

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

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

1

基本工作內(nèi)容

第一部分純談理論。

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

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

根據(jù)項(xiàng)目特定的質(zhì)量目標(biāo),準(zhǔn)備軟件質(zhì)量保證計劃。

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

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

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

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

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

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

在特定的管理工具中記錄差距、確定行動項(xiàng)、責(zé)任人和截止日期。

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

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

召開軟件里程碑評審會議,團(tuán)隊對最終紅黃藍(lán)評價達(dá)成一致。

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

在特定的管理工具中記錄差距、確定行動項(xiàng)、責(zé)任人和截止日期。

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

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

在相關(guān)的項(xiàng)目管理會議上,進(jìn)行質(zhì)量狀態(tài)匯報或升級。

1.5確保行動項(xiàng)關(guān)閉

針對差距和行動項(xiàng)進(jìn)行跟蹤直至合理關(guān)閉。

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

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

2

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

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

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

通常,代價最大的方法是讓客戶發(fā)現(xiàn)缺陷。這種方法可能會導(dǎo)致?lián)栴}、召回、商譽(yù)受損和返工成本。

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

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

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

第二級是常說的QC,遷移到軟件領(lǐng)域,通常是測試或修復(fù)bug。

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

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

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

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

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

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

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

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

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

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

3

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

努力需要有一些實(shí)實(shí)在在的方向,這部分會寫得最實(shí)在。

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

直接看結(jié)果。

下面來逐一分析。

3.1體系/流程/過程

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

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

3.2 開發(fā)

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

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

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

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

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

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

3.5 問題/風(fēng)險

那么,“檢查“是檢什么、查什么呢,也只能是“問題/風(fēng)險”了。

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

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

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

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

當(dāng)然,解決個例的、具體的問題還得是專業(yè)的人,質(zhì)量要更側(cè)重于從流程和體系層面解決,“改進(jìn)/優(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的審核壓力,也在不停地進(jìn)行相關(guān)部署、認(rèn)證和宣傳。

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

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

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

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

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

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

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

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

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

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

至于為什么把研發(fā)和業(yè)務(wù)放在一起,因?yàn)槠囆袠I(yè)里對于研發(fā)的理解比開發(fā)外延更大,會更接近于所謂的業(yè)務(wù)。

比如,ASPICE4.0相比較3.1,也擴(kuò)充了硬件、結(jié)構(gòu)和機(jī)器學(xué)習(xí),關(guān)注點(diǎn)不僅僅在(軟件)開發(fā)上了。

3.12 工具

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

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

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

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

3.13 測試

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

3.14 培訓(xùn)/指導(dǎo)

“培訓(xùn)/指導(dǎo)”不多擴(kuò)展,對于流程的創(chuàng)立者、守護(hù)者和推廣者,自然需要這項(xiàng)技能。

3.15 意識

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

再說一句,關(guān)鍵的是領(lǐng)導(dǎo)認(rèn)可和組織有土壤。

3.16 認(rèn)證/證書/PMP/ACP

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

3.17 英語

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

3.18 項(xiàng)目管理

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

3.19 編程/C語言/JAVA

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

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

4

全文小結(jié)

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

5

寫在最后

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

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

聲明: 本文由入駐維科號的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場。如有侵權(quán)或其他問題,請聯(lián)系舉報。

發(fā)表評論

0條評論,0人參與

請輸入評論內(nèi)容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無評論

暫無評論

    文章糾錯
    x
    *文字標(biāo)題:
    *糾錯內(nèi)容:
    聯(lián)系郵箱:
    *驗(yàn) 證 碼:

    粵公網(wǎng)安備 44030502002758號