知識工作的生產管理

提昇產出的第一步：找出知識工作的流程瓶頸

約十多年前，我讀到了高德拉特 (Eliyahu M. Goldratt) 的一本書 《目標：簡單有效的常識管理》。該書從工廠的生產來談生產管理，最核心的思想在於：「應該最佳化系統運作的流速 (flow efficiency)，而非確保系統的每個零組件都滿載地運轉 (resource efficiency)。」

整本書是用故事的形式寫成。故事的起頭是某間工廠總是難以達成上級期待的產出，而雪上加霜的事情是，不專業的上級還要求廠長必須確保一些昂貴機器的高使用率。不久，廠長受到管理顧問的啟發，於是開始動手分析整個工廠運作的關鍵活動。當廠長找出了關鍵的活動之後，赫然發現，原來上級幫他們購買的昂貴機器並不是整個生產流程的瓶頸，頩頸在其它地方！

書中剩下的故事則是改善瓶頸、然後發現系統的新瓶頸出現其它地方，再次設法找出頩頸，然後再設法改善，如此不斷地輪迴。

該書的管理思想又可稱之為限制理論 (Theory of Constraints) ，該思想具有泛用性：只要將工作化約成流程系統，找出流程瓶頸，並且迭代改進瓶頸，就可以有效地持續改進。

流程與瓶頸

最近我在兩本不同領域的著作裡，都看到了流程與瓶頸的應用。一本書是《買回你的時間》，主要談論經營事業的流程與瓶頸；另一本書則是《Team Topology》，談論以團隊來開發軟體的流程與瓶頸。以下是我用流程與瓶頸的觀點來重新詮釋上述兩本書的內容。

在《買回你的時間》一書中，「經營者的時間」是企業成長的最大瓶頸。作者提出了「替換階梯」（Replacement Ladder） 的思考架構，幫助經營者將工作流程拆解為四大類（行政、財務與營運、行銷與品牌、策略），並按照從容易替換到困難替換的順序逐步外包或委任。每當經營者成功替換掉一部分工作，瓶頸便相應減少，從而提高整體系統的產出，讓企業運作更加高效。

而在《Team Topology》一書裡，『開發人員的認知負荷』是最大的瓶頸。該書提出了一個『團隊拓撲』規畫方式，照這個規畫方式，軟體開發團隊最初可以先用 stream-aligned team 為核心，並且隨著時間的演進，逐步拆出 platform team, complicated-subsystem team, enabling team 。每次只要成功地從 stream-aligned team 拆出一部分工作，交給其它的輔助團隊， stream-aligned team 的認知負荷就減少了一部分，因而讓瓶頸得以縮減，系統的總體產出就可以提昇了。

後記

我從事軟體開發，一直以來，對於每日的軟體開發流程，總覺得還有很多自動化的可能性，這些自動化都有助於減少認知負荷。

這些自動化都有機會透過開發編輯器的插件 (plugin) 來處理，無奈的是，開發編輯器插件因為需要學習 VimScript ，也讓我卻步了許多年。

所幸，我的問題也不是我獨有的。後來，有人發展了 Fennel 語言，可以編譯成 Lua 在 Neovim 編輯器開發插件。於是，最近我終於開始動手修改編輯器插件了，距離開發流程的改善，又再更近了一步。