改善軟體開發的兩個方向
改善軟體開發的產出，除了增加平行度 (parallelism) 之外，另一個方向是減少開發工作中的瓶頸
以下是我平日的軟體開發工作：
我從 Gitlab Issues 上，找到產品經理指派的工作。大約有 6~7 成的機率，我無法立刻展開工作，必須先對該工作提出一兩個問題。
比方說，需求不明確。產品經理要我開發的功能，我可能有兩個實作方案，但是我不確定，哪一個選項是他要的，這種情況就會需要澄清需求。
又或是說，該工作是一個 bug 需要修，然而，該 bug 是在生產環境 (production environment) 之中被發現，而我卻沒有辦法在本地環境複製那個 bug ，於是，我發訊息給 SRE 工程師，請他設法拷貝一分生產環境中的資料庫備分，讓我可以在本地端複製那個 bug。
當真的開始實作之後，又有很多原因，可能會讓我必須暫時停下。
比方說，我需要在使用者介面 (user interface) 裡實作一個可讓使用者選擇日期來篩選資料的日期選擇器。該日期選擇器內部的邏輯，需要去比較日期的時間區間。由於使用者介面套用了 Ant UI component 函式庫，所以日期的時間，並不是單純的 JavaScript Date 的型態，而是 Moment.js 的 Date 資料型態。最初我沒有考慮到日期的資料型態，這就會造成一些 bugs 。
當我發現了需要考慮 Moment.js 之後，就順手下指令去搜索專案裡其它相似的日期選擇器的實作。搜索了之後，發現原來專案裡已經有前人實作了與日期選擇器相關的元件庫。換言之，該功能的最佳作法，是我延伸前人的元件庫去開發。可惜，該元件庫沒有任何的文件或是測試程式碼，所以之後我又花了一段不算短的時間，先看完了元件庫的源碼 (source code)，理解了元件庫的實作之後，才能再開始使用者介面的開發。
如果有人問我，如果可以投資更多人力的話，怎樣可以增加我的產出？考慮以上的例子，我會回答：
設計自動化的程式，讓開發工程師得到授權之後，可以一鍵完成生產環境之中資料庫的拷貝。
改善專案之中的 UI 元件庫，為其撰寫完整的文件與足夠的測試程式。
上述兩點，都是我在開發過程之中所遭遇的瓶頸。就是因為這些瓶頸的存在，讓我不得不等待，又或是多做了許多原先未規畫的工作 (unplanned work)。當這些瓶頸可以一一被改善之後，我的開發速度才有可能到達理論的極限。
然而，實務上，多數的管理階層通常會選擇了另一個方向來投資人力：『將專案切割成多個功能單元，並在不同的功能單元裡投入人力資源，平行進行開發。』換言之，常被選擇的方向，是投資人力於平行處理 (parallelism)。平行處理的作法，以系統的角度來看，回應時間 (response time) 不變，但吞吐量 (throughput) 可以增加。
以下是兩種改善方向的簡單對照表
減少瓶頸的困難
考慮過去 20 年的 CPU 發展史，我們可以發現，有很長的一段時間，CPU 發展的重點一直都是在設法提高單一核心的最高處理速度。一直到了量子效應愈來愈明顯，半導體的最高時脈已經有明顯的上限時，多核心的 CPU 解決方案才開始受到重視。
不考慮困難的話，提高單一核心速度的作法是很有吸引力的。這點，在軟體開發工作應該也是成立的。
要著手減少開發瓶頸的話，大致上有 3 個困難點：
如何定位瓶頸？
如何決定要改善哪些瓶頸？
如何確定一個專案已經到了必須著手改善的程度？
定位瓶頸
瓶頸大致上有兩種基本形式：
做了但沒有做好的工作
該做卻未做的工作
開發瓶頸最廣為人知的一種形式是技術債，技術債是做了但沒有做好的工作。技術債可能造成的影響通常是：理解困難、變更放大、增加 bug 產生的機率。正因為技術債是做了但沒有做好的工作，它可以透過對既有的程式碼做資料分析而加以定位。
該做卻未做的工作就抽象的多。比方說，在之前的例子裡：『設計自動化的程式，讓開發工程師得到授權之後，可以一鍵完成生產環境資料庫的拷貝。』、『改善專案之中的 UI 元件庫，為其撰寫完整的文件與足夠的測試程式。』這些都是該做卻未做的工作。
該做卻未做的工作還有許多其它的形式：
輔助除錯的記錄 (log)
除錯工具
各種測試
自動化工具
各式技術文件、文件的可發現性
要改善哪些瓶頸
一旦團隊的成員開始積極尋找瓶頸之後，往往很快地會發現，有眾多的開發工作瓶頸。這時，我們應該自問：「在有限的資源之下，應該優先改善哪些瓶頸，可能帶來最大的效益呢？」
有個簡單的捷思法 (Heuristics) 可以簡單地預測回報率：過去，一個瓶頸曾經造成影響的次數愈多，日後，同一瓶頸就有愈高的機率再次造成影響。
量測專案的開發瓶頸
儘管，改善開發瓶頸從理論上的分析有著種種的好處，我們很有可能還是難以下定決心，立刻開始著手進行。這時，我們可能需要更多客觀的數字來輔助決策。
我們可以量測『未計畫工作消耗的時間』佔『總工作時間』的百分比來評估專案的開發瓶頸
unplanned work time/total work time當這個百分比超過 15% 時，這就相當值得管理階層立刻投以更多關注了。
開發瓶頸與專案的慢性死亡
隨著一個專案日益複雜，軟體開發的瓶頸往往會愈來愈多。許多的軟體專案在開始不久之後，就已經走向慢性死亡，甚至即使已經成功地上線、帶來了商業上的實質效益，卻依然無法離開走向慢性死亡的道路。這是許多管理階層所不樂見的事。要有效阻止軟體專案慢性死亡，首先應該要理解開發瓶頸的概念。