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