軟件質量管理之困境與對策思考

相信在很多與軟件開發相關的企業內，質量管理部門與軟件開發部門在平常運做中造成了以下圖所示的「啞鈴形」組織結構。

 

 

開發部門執行質量管理部門所制定的流程，經過提供證據的形式將各類流程執行後的數據反饋給質量管理部門（包括缺陷率和各類流程記錄），質量管理部門根據這些數據監督流程的執行效果，並適時修訂流程。聯繫兩大獨立部門的，是單薄的兩條線和一些部門間的會議。理想狀況下，在質量管理部門與軟件開發部門間造成的是一個逆時針的良性質量管理環，理應得到良好的效果。但在我看來，事實卻並不是如此！

啞鈴形組織結構所存在的前提假設有兩個。其一，度量數據能真實地反映軟件質量。顯然，在軟件危機仍四伏的今天，業內並無找到徹底能用於度量軟件質量的指標，這一假設對於現實多少顯得非常渺茫。其二，軟件開發部門能誠實地提供度量數據。對於目前國內職業化程度不高的狀態，這一假設也很難成立。

所以，啞鈴形組織結構所帶來的第一個困境是：將兩個部門分別變成了「看數據的」和「造數據的」兩大陣營。軟件開發部門爲了達到質量管理部門所制定的「質量目標」，不時須要考慮如何將數據「造」好，哪怕「造」的手法有點低劣；而質量管理部門因爲只是經過數據去了解軟件產品的質量情況，除了不能理解有些指標爲什麼忽上忽下外，更沒法督促開發部門就質量問題的根源進行根治。

克服這一困境的對策我認爲須要從打破組織結構開始。真正掌握軟件真實質量情況的並非來自質量管理部門的人，由於他們根本沒有觸及軟件源代碼，而是來自開發部門的軟件工程師。爲此，兩部門的人員應當存在交集才更有可能作好質量管理工做，或許下圖的組織結構更有助於達到這一目的。

 

在新的組織結構中，兩部門交集中的人應來自開發部門的、對軟件質量管理有很好認識的技術專家，這些人來自下圖「能力金字塔」（參見《軟件開發：我的與團隊是永遠的核心》）的上面兩層。他們除了幫助質量管理部門瞭解軟件質量的真實情況外，還應幫助開發部門理解質量問題的根源和尋求技術解決方案。交集中的人能夠考慮採用虛擬團隊的形式進行組織與管理。

質量管理容易出現的另外一大困境是：太強調流程與數據，而忽視質量管理很重要的內容是幫助工程師改善工做習慣（好比編程習慣）和提升開發環境的工做效率（好比項目的編譯效率、單元測試的實施效率）。在這種困境之中，質量管理活動更多地表現爲「鋼性」—— 達到設定指標或沒有達到，而缺少應有的「柔性」理解。雖然「產品質量源於過程控制」這一思想被業界普遍認同，但卻仍容易忽視將工程師的工做習慣和開發環境的效率歸入到質量管理的範疇之中，這也是形成很多質量困境的關鍵因素。對於這兩方面內容的重要性，不管如何強調也不爲過。

 

最後，我認爲質量管理應更多關注於實踐，而非度量。因爲軟件開發的特殊性本質，咱們難以尋找到有效的度量手段，於其在這方面毫無建樹，不如花更多的時間去創建適合本身的實踐方法，並將這些實踐融入到工程師的工做習慣和開發環境中去。

 

推薦閱讀

《駕馭你的“職場布朗運動”》

《致IT同仁 — IT人士常犯的17個職場錯誤》

《軟件工程師所需掌握的“終極技術”是什麼？》
《技術敏感度 — 基層技術管理者必備》