部分企業(yè)算是突出重圍，定點項目逐漸增多，業(yè)務規(guī)模開始擴大，以及打算瞄向國際車企，所以，軟件質(zhì)量職能被漸次提了出來。
但是，對于軟件質(zhì)量如何干？該設置什么職責？應該抱有什么樣的期望？大家普遍沒達成共識，也沒太想清楚，這在小企業(yè)里尤其突出。
1 確保滿足客戶需求
這是小企業(yè)的生存基礎，也是對應軟件質(zhì)量應該具備的mindset，即作為其判斷尺度的尺度。具體來說：
- 聚焦客戶需求傳遞、收集、版本整理、適用范圍提取等內(nèi)外部接口處工作，最好形成包含來源、渠道、時間、存檔位置等信息的baseline。
- 確保正確的人參與評估、分析、拆解、實現(xiàn)、評審等，也就是“懂的人”和“錯了要受影響的人”。
- 時刻質(zhì)疑需求的合理性，這也是一種意識，要知道客戶接口帶來的不一定是真正的客戶需求，要往上挖，找源頭。
- 評估關(guān)鍵相關(guān)方（主要是內(nèi)部）對需求的理解是否一致和準確。
這里的成熟度主要是針對產(chǎn)品的，主要目的是給管理團隊信心和決策依據(jù)，有很多維度。
- 軟件的成熟度等級，可以是按照feature實現(xiàn)程度（如百分比、已集成/已可驗/已可用）或者適用的使用場景（如臺架、整車、路試）來定義。
- 質(zhì)量閥紅黃綠狀態(tài)，這也是非常典型的質(zhì)量管控形式，簡單粗暴但十分直觀。
- 缺陷率（不同等級缺陷數(shù)量加權(quán)相加）數(shù)值，通常用于不同產(chǎn)品的橫向?qū)Ρ取?/span>
其目的和成熟度基本一致，但需要注意的是，過程透明度通常會關(guān)系到產(chǎn)品成熟度水平和真實性，這是軟件開發(fā)的特點。過程透明也是軟件工程一直追求的目標?？梢杂萌缦乱恍┓绞健?/span>
- 設置環(huán)環(huán)相扣的指標，驅(qū)動真實的開發(fā)行為展示，比如，監(jiān)控各個階段的缺陷檢出率能夠推動缺陷檢出階段數(shù)據(jù)的準確性。
- ALM工具中設置充足的數(shù)據(jù)埋點，即什么人在什么時間進行了什么操作進入了什么狀態(tài)。工具的自動痕跡留存功能能夠很好地反映出真實的開發(fā)狀態(tài)。
- 數(shù)據(jù)同源和工作同平臺。這樣的話，信息的傳遞就是及時且透明的，但可能涉及到信息安全問題。
4 保證盡量合規(guī)
盡量合規(guī)的“盡量”可能會讓大家有疑問，這里主要是強調(diào)針對強制性要求和衍生性要求應有不同的遵守尺度。
- 強制性要求是指高等級功能安全、數(shù)據(jù)安全、網(wǎng)絡安全、車規(guī)標準或其他一些強標以及內(nèi)部特定政策之類的不必爭論合理性的要求，既涉及產(chǎn)品，也涉及過程。通常產(chǎn)品基本功能也可以理解為強制性要求。
- 衍生性要求是指“最好有”或者“根據(jù)實際情況而定”，比如，軟件詳細設計就屬于此類，寫了更好，但模塊簡單，人員不分層，不寫也行。
在這里，值得注意的是，合規(guī)不能僅僅局限在狹義QA里的流程不規(guī)范的檢查，需要有宏觀的視角，尤其是新的小的企業(yè)。
5 擁有高層級和系統(tǒng)級視角
接著上一段，引出這個要求。
汽車行業(yè)擁有十分龐大的體系，身處大產(chǎn)業(yè)鏈上的一環(huán)，會遇到很多看似無聊和不合理的現(xiàn)象，而它們背后多數(shù)有一個曲折的故事，是不同立場相關(guān)方利益較量的結(jié)果。
軟件質(zhì)量作為一個體系性的管理角色需要有這個意識、視角與經(jīng)驗。
- 系統(tǒng)架構(gòu)、軟件架構(gòu)、軟件項目管理、功能安全背景的人通常是軟件質(zhì)量比較好的選擇，因為他們的知識結(jié)構(gòu)比較系統(tǒng)和均衡。
- 監(jiān)控、審核與評價過程中，需要向上看代碼，向下找整車，這有助于給出更合理的判斷。
- 著力為項目經(jīng)理或管理層提供信息的整體視圖，比如，多維度缺陷動態(tài)看板、按里程碑的feature實現(xiàn)及驗證狀態(tài)、上下追溯矩陣等，也可以擔當起項目級配置管理員的角色。
6 擔當客戶質(zhì)量接口
這是很多企業(yè)比較務實的需求，除了常規(guī)應對審核的工作外，還可以有其他的擴展。
- 在項目定點期間，就開始介入，協(xié)同整車節(jié)奏制定質(zhì)量管理計劃。當下，協(xié)作開發(fā)的模式越來越多，也越來越復雜，僅局限在內(nèi)部開發(fā)模式，不太夠。
- 支持項目經(jīng)理進行外部跨模塊、跨部門的信息整理、數(shù)據(jù)分析與匯報。
- 如客戶要求和內(nèi)部要求有矛盾，需要帶到內(nèi)部進行適配與裁剪。
- 針對新OEM，尤其是歐美系，深入對標客戶的質(zhì)量體系與指標的要求。
7 保持獨立匯報線
軟件質(zhì)量設置在工程或項目管理部門，還是有獨立匯報線，不同的公司有不同的模式，通常也取決于高管的背景。
一般建議保持獨立的匯報線，至少要給一個與工程及項目管理相對獨立的匯報平臺，最好是處于獨立且層級扁平的質(zhì)量部門。人員不多的，可以職級不高，但匯報線高一點。
決策權(quán)衡往往是基于立場，不獨立，立場則相同，質(zhì)量必然和工程或項目達成某種“默契”。
很少有公司能做到讓軟件質(zhì)量或工程質(zhì)量去block項目釋放，對于小企業(yè)更不現(xiàn)實。
所以，話語權(quán)與推動力更多來自于匯報。當然，讓質(zhì)量說了算不是公司目的，而是更好地將前述的產(chǎn)品成熟度、過程透明度、項目big picture展現(xiàn)出來。
- 郵件發(fā)送的日報、周報、月報會提供第一個工作層平臺。
- 定期的高級別管理層專題會議是第二個有權(quán)威的平臺。
- 形式規(guī)范的質(zhì)量閥是第三個成機制的平臺，注意形式一定要規(guī)范。禮儀之邦，不僅僅是禮貌，還有約束。
9 關(guān)注發(fā)布
向車廠發(fā)布軟件或樣件之前，企業(yè)內(nèi)部要有管控與釋放機制，而不是個人化行為。軟件質(zhì)量在該環(huán)節(jié)要負責提供證據(jù)。
- 要關(guān)注產(chǎn)品的預期用途，比如，臺架測試還是整車路試，對軟件的要求自然不同。
- 按照預期用途，可以設置releasenotes評審、相關(guān)方簽批及正式質(zhì)量閥等不同程度的釋放機制。
- 至少要保證自身的基本功能可測、可用，以及通訊、診斷部分不影響整車。手段通?？梢允窍嚓P(guān)必測項通過。
10 寫在最后
小企業(yè)的軟件質(zhì)量需要用70%的精力想人，30%的精力做事。
轉(zhuǎn)自水輕言
