相信在不少與軟件開發相關的企業內，質量管理部門與軟件開發部門在日常運作中形成了如下圖所示的“啞鈴形”組織結構。
開發部門執行質量管理部門所制定的流程，通過提供證據的形式將各種流程執行後的數據反饋給質量管理部門（包括缺陷率和各種流程記錄），質量管理部門根據這些數據監督流程的執行效果，並適時修訂流程。聯繫兩大獨立部門的，是單薄的兩條線和一些部門間的會議。理想情況下，在質量管理部門與軟件開發部門間形成的是一個逆時針的良性質量管理環，理應獲得良好的效果。但在我看來，事實卻並非如此！
啞鈴形組織結構所存在的前提假設有兩個。其一，度量數據能真實地反映軟件質量。顯然，在軟件危機仍四伏的今天，業內並沒有找到完全能用於度量軟件質量的指標，這一假設對於現實多少顯得很是渺茫。其二，軟件開發部門能誠實地提供度量數據。對於目前國內職業化程度不高的狀態，這一假設也很難成立。
因此，啞鈴形組織結構所帶來的第一個困境是：將兩個部門分別變成了“看數據的”和“造數據的”兩大陣營。軟件開發部門爲了達到質量管理部門所制定的“質量目標”，不時需要考慮如何將數據“造”好，哪怕“造”的手法有點低劣；而質量管理部門由於只是通過數據去了解軟件產品的質量狀況，除了不能理解有些指標爲何忽上忽下外，更無法督促開發部門就質量問題的根源進行根治。
克服這一困境的對策我認爲需要從打破組織結構開始。真正掌握軟件真實質量狀況的並不是來自質量管理部門的人，因爲他們根本沒有觸及軟件源代碼，而是來自開發部門的軟件工程師。爲此，兩部門的人員應當存在交集才更有可能做好質量管理工作，或許下圖的組織結構更有助於達到這一目的。
在新的組織結構中，兩部門交集中的人應來自開發部門的、對軟件質量管理有很好認識的技術專家，這些人來自下圖“能力金字塔”（參見《軟件開發：個人與團隊是永遠的核心》）的上面兩層。他們除了幫助質量管理部門瞭解軟件質量的真實狀況外，還應幫助開發部門理解質量問題的根源和尋求技術解決方案。交集中的人可以考慮採用虛擬團隊的形式進行組織與管理。
質量管理容易出現的另一大困境是：太強調流程與數據，而忽視質量管理很重要的內容是幫助工程師改善工作習慣（比如編程習慣）和提高開發環境的工作效率（比如項目的編譯效率、單元測試的實施效率）。在這種困境之中，質量管理活動更多地表現爲“鋼性”—— 達到設定指標或沒有達到，而缺乏應有的“柔性”理解。雖然“產品質量源於過程控制”這一思想被業界廣泛認同，但卻仍容易忽視將工程師的工作習慣和開發環境的效率納入到質量管理的範疇之中，這也是造成不少質量困境的關鍵因素。對於這兩方面內容的重要性，無論如何強調也不爲過。
最後，我認爲質量管理應更多關注於實踐，而非度量。由於軟件開發的特殊性本質，我們難以尋找到有效的度量手段，於其在這方面毫無建樹，不如花更多的時間去建立適合自己的實踐方法，並將這些實踐融入到工程師的工作習慣和開發環境中去。
《致IT同仁 — IT人士常犯的17個職場錯誤》
《軟件工程師所需掌握的“終極技術”是什麼？》
《技術敏感度 — 基層技術管理者必備》