大多數軟體問題歸根結底都是組織結構問題
在《軟體工程最佳實踐》一書中給出了這樣一條結論：
很多問題都可以追溯到組織的結構問題上。
初聞之下，如醍醐灌頂；細細思索，深以為然。
比如有這樣一個案例。
小吳是某軟體的負責人，他的軟體在生產環節出現了問題。由於生產進度安排得非常緊，幾乎沒有多少軟體驗證的時間，所以小吳在匆匆修復了問題之後，自己除錯軟體功能正常，就提交給車間繼續生產流程。結果這件事兒被質量管理部門發現了，打了不合格項。
在這個案例中，雖然尚未出現新的軟體故障，但小吳的做法也違反了組織的軟體工程規範的要求，包括：
-
軟體更改之後會進行迴歸測試。
-
提交到生產環節的軟體是非受控版本。
小吳，所以這樣做是因為沒有軟體驗證的時間。沒有軟體驗證的時間是因為車間的生產週期很短。車間的生產週期很短是因為制定生產計劃時沒有考慮軟體更改的流程可能需要更多的時間。沒有考慮軟體更改驗證的時間是因為制定生產計劃時並沒有軟體專業人員參與。這就是組織的結構出現了問題。
小吳這樣做只被質量管理部門發現，軟體部門事先都不知情。這說明專案監控出了問題，專案負責人不瞭解情況，QA不瞭解情況，軟體專案組名存實亡，這也說明組織結構出現的問題。
除此之外組織結構如何更好的適配軟體專案，還有很多要研究的內容。比如：
-
傳統的層級式的組織結構和扁平化的組織結構，哪種更適應那些短平快的軟體專案？
-
對於一個複雜的系統，需要一個龐大的團隊，那麼是否應該把系統拆分成小的系統或部件，把龐大的團隊拆分成小的團隊(6~8人)，這樣會更有利於專案開發活動的進行？
-
一個團隊如何組成才會更加高效？比如應該有幾名開發人員，幾名測試人員，是否需要有文件專員？是否需要有某個領域專家，是否需要有軟體專家？
下表列出了30種軟體專家及其在團隊的分佈情況。
表1 總數1000名軟體人員中軟體專家的分佈情況
| 專家種類 | 數量 | 百分比 |
|---|---|---|
| 軟體維護專家 | 315 | 31.5% |
| 軟體開發工程師 | 275 | 27.5% |
| 軟體測試專家 | 125 | 12.5% |
| 一線經理 | 120 | 12% |
| 質量保證專家 | 25 | 2.5% |
| 技術文件專家 | 23 | 2.3% |
| 客戶支援專家 | 20 | 2% |
| 配置控制專家 | 15 | 1.5% |
| 二線經理 | 9 | 0.9% |
| 業務分析師 | 8 | 0.8% |
| 範圍經理 | 7 | 0.7% |
| 行政支援 | 7 | 0.7% |
| 專案庫管理員 | 5 | 0.5% |
| 專案規劃專家 | 5 | 0.5% |
| 軟體架構師 | 4 | 0.4% |
| 使用者介面專家 | 4 | 0.4% |
| 成本估算專家 | 3 | 0.3% |
| 度量/指標專家 | 3 | 0.3% |
| 資料庫管理專家 | 3 | 0.3% |
| 本地化專家 | 3 | 0.3% |
| 圖形藝術家 | 3 | 0.3% |
| 軟體效能專家 | 3 | 0.3% |
| 軟體安全專家 | 3 | 0.3% |
| 軟體整合專家 | 3 | 0.3% |
| 軟體加密專家 | 2 | 0.2% |
| 可重用性專家 | 2 | 0.2% |
| 測試庫控制專家 | 2 | 0.2% |
| 專案風險專家 | 1 | 0.1% |
| 標準專家 | 1 | 0.1% |
| 價值分析專家 | 1 | 0.1% |
如果團隊當中有專家的存在必定會降低軟體出問題的概率。比如有測試專家的存在，就可能會降低出現“驗證不充分”的問題的出現；有效能專家的存在，就可能會降低“效能無法驗證”的問題的出現。
總之，如果你的軟體出現了問題，除了找到問題的出處，解決問題之外，還請思考一下相應的組織結構是否存在問題。因為組織結構的問題是根本原因所在，解決了組織結構的問題，就會避免批量問題的出現。
一勞而永逸，何樂而不為？