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