提醒一下，我寫作時有時會爆粗口。如果需要分享給不喜歡髒話的地方，請注意。
現在是星期二早上。你的工程副總裁站在投影片前，興奮得像是2017年剛發現加密貨幣的人。他們剛從一場會議回來，或者是供應商晚宴。喝了三杯黑皮諾，還看了一場示範，現在他們帶來了消息。
會議室裡一半的人點頭同意，另一半的人突然對筆電產生興趣。你的資深工程師露出那種表情。你知道那是什麼表情——他們正在計算要不要發言，還是乾脆晚點更新LinkedIn。
沒有人問那個重要的問題：速度到底是朝向什麼？
因為事情是這樣的。你的工程副總裁看了整個軟體交付組織，找出一個已經相當快的環節，決定讓它更快。他們找到生產線上不是瓶頸的站點，然後砸錢加速它。
如果你懂系統運作，你知道這不只沒幫助，還會讓整體變得更糟。
1984年，Eli Goldratt寫了《目標》這本關於製造業的小說，對軟體領域的啟發意義出乎意料地大。這也是你會讀到最有用的商業書籍之一，雖然它是小說，幾乎與大多數KPI框架背道而馳。
核心概念是「限制理論」，內容如下：
每個系統只有一個限制點，也就是瓶頸。整個系統的產出量由這個瓶頸決定。在你解決瓶頸之前，其他事情都不重要。
這是大多數人懂的部分。接下來這部分他們不懂，卻應該讓你害怕：
從機械角度想。如果站點A生產零件更快，但瓶頸站點B仍只能以原速處理，那你只是製造了一堆未完成品堆積在A和B之間。庫存增加，交付時間拉長。B站的人忙不過來。堆積物讓下一步該做什麼變得混亂。品質下降，因為大家忙著處理緊急狀況，沒時間思考。
我敢打賭你們中有些人已經遇過這種情況。我也經歷過，真的很糟。
你的開發人員比以往更快產出PR（拉取請求）。很好，太棒了，給你一顆金星，快拿彩帶炮慶祝吧。可是這些PR進入審查隊列時，審查者數量並沒有增加三倍。沒有人想到要增加審查者，因為審查者不在供應商的投影片裡。
結果PR就卡著。一天，兩天，一週。作者已經切換到下一個AI輔助功能，當審查意見出現時，幾乎忘了第一個功能是做什麼的。「你能解釋這個函式做什麼嗎？」他們問，盯著八天前寫的程式碼，對開發者來說那大概是侏羅紀時代。
審查開始變成走過場，因為實在太多PR無法好好審查。有人批准了沒仔細看的PR。我們都做過（別那樣看我）。PR合併了。CI跑了45分鐘，因為不穩定測試失敗，重跑一次後通過（不穩定測試通常沒問題，直到某天凌晨兩點你穿著內褲在生產環境除錯時才發現問題。問我怎麼知道的……其實別問）。部署流程需要某個人在開會中批准。功能在預備環境擱置三天，因為沒有人急著推到生產環境。
同時，開發者已經提交了兩個新的PR。隊列越來越長，進行中的工作（WIP）爆表。每個人同時做六件事，卻沒完成任何一件。週期時間（衡量交付價值速度的指標）變差了。
你產出更多程式碼，卻交付更少軟體。你讓情況明顯變糟，卻有儀表板顯示生產力提升了40%。
我在三家公司都看過這齣戲。儀表板數字上升，交付量下降。沒人把兩者連結起來，因為儀表板是向董事會報告的東西，而董事會不懂週期時間，也沒人想當那個解釋的人。
真正讓我夜不能寐的是：很多AI生成的程式碼沒有人完全理解。所謂「寫」程式碼的人其實沒真的寫，是用提示生成，快速瀏覽，可能執行過一次。當凌晨兩點生產環境出問題時，值班的人沒寫過那段程式碼，提示的人也說不清楚。你增加了事故發生面，卻減少了能理解系統的人數。
如果問題不在寫程式碼（而且幾乎從來不是），那你該看哪裡？走訪價值流。追蹤一個功能從「有人有了點子」到「用戶獲得價值」。我保證瓶頸會跳出來向你招手——甚至可能翻白眼，因為你一直忽略它。
這是沒人想談的部分，因為很尷尬。你的產品經理兩個月沒跟真實用戶聊過。需求以Jira票的形式送來，只有三句話和一個由從未用過產品的人批准的Figma設計連結。工程師每天做五十個微決策，關於行為、邊緣案例和錯誤處理，沒人指定，因為沒人想過這些。
我曾看過一個團隊花六週時間做一個功能，根據銷售代表在Slack上轉述潛在客戶可能說過的話。六週。潛在客戶最後根本沒買。功能只有11人用，其中9人是內部QA。這不是交付問題，是「我們到底在幹嘛」的問題。
在這種環境下加快程式碼產出，就是加快做錯事的速度。你自動化了猜測。你會更快做錯功能、交付、看它失敗，然後開回顧會，有人說「我們需要多跟用戶聊聊」，大家嚴肅點頭，然後什麼都沒改變。
我把「完成」放引號，因為在大多數組織裡，寫程式碼可能只佔20%的旅程。其他80%是程式碼在各種隊列中慢慢老化，就像辦公室冰箱裡被遺忘的三明治。
我看過功能程式碼花一個下午寫完，卻花兩個月才推到生產環境。兩個月。程式碼沒變慢，是周圍的人拖慢了它。
PR審查、CI、預備環境、QA、安全審查、產品簽核、部署時段、金絲雀發布。從開發者分支到用戶螢幕的實際流程是一連串交接、等待和排隊。大部分時間，程式碼都在靜止。等人看，等流程跑，等有人批准。
如果你看過週五下午4:55的PR批准，心想「那應該星期一才會部署」，你就懂我在說什麼。
想要更快交付，就看哪裡在等待。計算實際工作時間與排隊時間的比例。我保證這比例會讓你想撞牆。
我數不清合作過多少團隊害怕部署。測試不穩定，監控混亂，沒人信任金絲雀流程，上次有人週四部署害大家周末都崩潰。結果呢？他們把改動合併成更大的版本。更大風險。部署更可怕。大家更愛合併更多改動。
現在把更快的程式碼產出加進這種環境。更多程式碼，恐懼的部署文化不變。版本更大，風險更高，發布更少。你讓本來就害怕交付的團隊更不敢交付。真是厲害。
這和「你不知道該做什麼」是同一種病，只是管線另一端。你做了東西，交付了東西，然後……沒事發生。沒有值得看的分析，沒有上線後的用戶訪談，沒人回頭檢查功能是否解決了問題。
所以你也只能猜下一個功能。再下一個。整個產品路線圖都是一連串沒有回饋的有根據猜測。
你常常得出「我們不知道這有沒有用」的結論，一次次學不到東西，卻還稱這是速度。
有時瓶頸根本不是技術問題。是你需要決策的會議。三個團隊需要同意API合約，但一個月沒講過話。架構師是每個重要設計決策的唯一批准點，排了兩週的待辦，因為我們竟然建了一個一個人行事曆就是承重牆的系統。或者我最喜歡的：規劃流程要六週，按季運行，意味著你得等五週才能開始做緊急事，因為「不在計畫裡」。
不是技術問題，不是程式碼問題，是行事曆問題。我們花更多時間討論功能，卻少時間做功能。有一次有人建議開會討論開會。我真希望我在開玩笑。現在我只想洗個澡，喝點威士忌。
這些是協調問題。人為問題。混亂、政治味重、沒人想負責的問題。
寫程式碼更快對這些問題毫無幫助。零。瓶頸是組織架構，無論多少Copilot都改不了。
你知道這段會來，無聊的部分。我不會假裝它有多酷，因為沒有。沒人會寫LinkedIn貼文談它，沒人會在供應商會議上當主題演講。沒有贈品。
繪製你的價值流。真的，從點子到生產追蹤一個功能。寫下每個步驟。寫下每個步驟花多久。寫下步驟間等待多久。週期時間就藏在步驟間的空檔。這會讓你沮喪，但還是做吧。帶點零食。
量測週期時間，不是產出。如果你量的是程式碼行數、合併的PR數或「完成的故事點」，卻沒量從提交到用戶使用的時間，你就是優化錯誤的東西。你在數站點A的零件，忽略地上的堆積。別這樣，我是認真的。
找出等待狀態並消除它們。如果PR審查等兩天，改善審查。結對編程、更小的PR、專門審查時間、非同步審查規範，找適合團隊的方法。如果部署等人工批准，自動化它，或至少改成Slack按鈕，不要用行事曆邀請。如果決策等會議，做更小的決策，不用開會。
停止一直開始，開始完成。WIP限制是有原因的。完成三件事比同時做十件好。每個進行中項目都是切換上下文的代價，而切換上下文是好工程師慢慢失去理智、開始寫沒人看的內部宣言的地方。
跟做事的人聊聊。你的開發者早就知道瓶頸在哪。他們在站立會抱怨，幾個月來在Slack做梗圖。他們只是以為沒人聽，說實話，他們大概是對的。
回到那個星期二早上。你的副總裁站在那裡，講著程式碼產出提升40%。他們應該說的、真正有用的是：「我們做了價值流分析，發現功能在步驟間平均等待九天。我們要把它減半。」
這不性感，不會出現在供應商投影片裡，賣不成產品，可能也沒會議主題（其實這讓我有點靈感……）。但這才是能真正讓你交付更快的事。
寫程式碼的速度從來不是你的問題。如果你以為是，信念與現實之間的差距就是你所有真正問題所在。競爭優勢不屬於寫程式碼最快的團隊，而是屬於那個知道該做什麼、做了它，並在其他人還在淹沒於滿是AI生成PR的審查隊列時，已經把產品交到用戶手上的團隊。