溫伯格的軟體管理學

「系統中每當遇到人為決定的時點時，能夠決定下一事件會如何發展的不是事件本身，而是某人對該事件所做的反應。」 ——溫伯格的軟體管理學

「溫伯格的軟體管理學」這套書共有 4 冊，出版於 2012 年，裡面談到不少軟體開發管理所遇到的現象，即使到現在仍然存活在這個世界，恐怕我們在軟體開發管理的進步，並不如我們想像的多。

此處的「軟體開發管理」指的不是專案層級的管理，而是組織層面的管理，畢竟管理一個專案或團隊的複雜度總是比起整個組織要小許多，這也是為什麼明明在同一間公司，卻總是有好部門與壞部門的區別，真正的軟體開發管理應該落實到組織層面，才能帶來全面性的變革。

「軟體開發管理」的目標則是如何產出有品質的軟體以提高組織獲得成功的機率，這個過程需要系統化思考。

何謂系統化思考？軟體開發管理的過程，就是管理 1 個動態的系統，這個系統裡的元件可能會受到各種因素擾動，進而產生不同的反應，最終導致各種結果。

舉個常見的例子，某公司高層下達要將 bug 的數量列為考績評量之一，工程師為了不影響自己的考績，因此開始運用人情壓力，讓工程師可以在測試人員找到 bug 的當下能夠迅速修正，如此一來 bug 數量雖然少了，但工程師礙於考績壓力，也會開始挑簡單不容易出錯的功能做，較複雜功能則越來越難找到人員負責。最終，一線人員感到士氣低落，工作窒礙難行，而高層則因為 bug 數量減少，以為管理奏效而沾沾自喜。

回到開頭的書摘，「將 bug 的數量列為考績評量」就是人為決定，而一線人員對於此決定的「反應」，最終決定這個故事的發展，這整個過程就是一個系統的互動，譬如在這個系統中， Bug 的數量可能受到測試案例、測試時間與開發能量的影響，此 3 者的資源越多， Bug 的數量則會下降，如果在這個系統中加入一個決定，也就是考績，那麼可能降低員工的積極度，進而影響開發能量與公司推出新功能的速度⋯⋯。（本文的圖未經任何研究驗證，僅用於表達與這故事相關的系統樣貌）

找出系統中相互影響的因素就是系統化思考的開端，開始系統化思考之後，我們就可以開始進行有條有據的管理，譬如在剛剛的故事中， bug 數量的問題，我們也許應該優先思考是否是測試案例與測試時間不足所導致，而非透過強加一個新的因素（考績）試圖修正問題，進而導致整個系統更複雜，反而帶來新的問題⋯⋯。

（好像絕大多數管理人員都會看似解決舊的問題，但實際帶來更多新問題⋯⋯）

「管理階層的行動之所以會助長失控的情況其原因在於，對於異常現象所做的反應通常都嫌太慢，這會迫使管理階層不得不做出大動作，這樣的動作本身就會造成非線性的結果。這正是為什麼我們必須動作要早、動作要小。」 ——溫伯格的軟體管理學

看到這段文字，我直覺想到「破窗效應」心理學理論以及「原子習慣」這本書。

破窗效應指的是假設我們不管某些輕微犯罪的發生，形同默許犯罪的發生，將會有更多犯罪發生，最後導致秩序失控。如果套用到軟體管理，其實就是指我們每一次對於軟體品質的縱容或妥協，可能就是導致軟體品質下降的主因之一，最終這會迫使管理階層做出大動作，於是進一步造成組織層面的破壞。

不知道大家有沒有類似的經驗？公司內部總是有些難以維護卻又十分重要的產品，這些產品通常不是沒有測試案例就是沒有規格文件，被指派要接手的團隊或者同事，基本上等於被寫入死亡筆記本一樣，遲早都會離職⋯⋯。

如果仔細思考，其實就是管理階層不重視規格文件、測試，或者開發時期為了追求速度因而犧牲相關應有的文件與紀錄，而產品的重要性又迫使管理階層對開發團隊做出不合理的要求，例如時程、品質等等，對團隊造成進一步的傷害，這種傷害通常都是非線性的，也就是拖越久越難處理，這通常暴露管理階層以線性思考嘗試解決問題，而忽略現實是以非線性的情況發展（如圖，可以看到在線性與非線性之間的落差在後期其實相當大）。

溫伯格認為軟體管理的行為必須趁早行動，也是因為軟體開發通常伴隨著規模增長造成非線性的複雜度增長，以前述的故事為例，管理階層應該在產品某個階段就趁早導入規格撰寫以及建立測試文化，而人又屬於抗拒改變的一種生物，因此每次的行動應該要夠小，避免人產生抗拒心理，進而影響行動的成功率，例如可以先從重要的功能開始逐一建立制度，而非要求要全面性一次到位，恰好也是呼應「原子習慣」所提倡的從微小的調整做起，畢竟大規模的改變，不僅會打壞原本的工作方式，讓人無所適從之外，也會讓團隊感到十分不滿⋯⋯（怎麼覺得自己好像在哪裡遇過類似的事😂）。

(未完待續)