本篇文章更新時間：2026/03/18
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
真正的工程效能，與速度無關：讀《If you thought the speed of writing code was your problem》有感
編輯前言：這篇文章來自 Andrew Murphy 的深度長文 If you thought the speed of writing code was your problem。作者用極具畫面感的方式提醒我們：工程團隊真正的問題從來不是「寫程式太慢」，而是整個組織流程充滿等待、混亂與錯誤的方向感。這篇筆記整理出我覺得最核心、最值得工程主管反思的幾個關鍵點。
核心觀點 (Key Takeaways)
- 瓶頸從來不在「寫程式」，而在整個交付流程中那些被忽略的等待與決策空窗。
- 盲目提升程式碼產出（例如 AI 助手帶來的 40% 增加）只會讓非瓶頸環節更擁塞，導致生產線整體變慢。
- 真正的效能提升來自：看懂價值流、找出等待、降低 WIP、並解決「不知道要做什麼」與「不敢部署」的文化問題。
深入解析
Andrew 的文章以一個超生動的畫面開場：VP 工程帶著 AI Coding Assistant 的 40% 產能提升消息滿場飛。但作者一句話戳破泡泡：「Velocity toward what, exactly?」——速度向哪裡加？沒人問。
他引用 Goldratt 的《The Goal》：
每個系統只有一個瓶頸，整體產出由該瓶頸決定。優化非瓶頸步驟，只會讓系統更壞。
以軟體開發來看，這意味著：當你把程式碼產出加速 3 倍，PR review、CI、deploy 等後段流程完全沒有擴容時，你不是更快交付，而是製造巨型擁塞。
開發變快，交付反而變慢：三倍 PR，零倍 Reviewer
原文描述的情況我非常熟悉：
- PR 堆積
- 開發者忘記自己寫過什麼
- Reviewer 來不及看只好蓋章
- CI flaky 重跑
- Staging 卡三天
- Deploy 需要手動批准但負責人正在開會
結果就是：「寫的比以往多，卻上線比以往少。」
更可怕的是：大家都不理解新程式碼
AI 生成的程式碼經常缺乏人類理解。文章直接點破那個場景：半夜 2 點 on-call 面對不是自己寫也沒人懂的程式碼。
More code, less understanding.
這根本是技術債爆炸的完美配方。
真正的瓶頸往往在這些地方
作者列出五個常見瓶頸，幾乎所有工程團隊都會中至少兩項：
- 不知道要做什麼：需求模糊、來自 Slack 傳話、沒人問用戶。
- Code "done" 後的等待地獄：PR、CI、QA、sign-off 等流程都在排隊。
- 組織害怕部署：測試爛、觀測差、部署不可信，因此越拖越久。
- 沒人在乎上線後是否有效：無測量、無回饋、無學習。
- 決策被會議綁架：日程是負載牆，一個人不在就卡整條流程。
每個都非常真實、非常痛。
筆者心得與啟發
讀完這篇，我最大的感想是：台灣與世界許多團隊都犯了一樣的錯，就是把「工程生產力」誤解成「程式碼產出量」。
但軟體價值從來不是靠程式碼堆出來的，而是靠「最快讓真正的用戶拿到能解決問題的功能」。
這篇文章提醒我幾件事情：
- 效能來自減少等待，而非增加輸出。 很多時候，我們的 PR、review、QA、部署才是瓶頸，而不是開發速度。
- 越快寫錯的東西，只會越快浪費資源。 如果需求本身錯誤或模糊，加速產能只是加速撞牆。
- 組織的協作成本、信任問題，比技術問題更可怕。 害怕部署、害怕決策、依賴會議等文化，完全無法靠工具改善。
- 真正的競爭力是 cycle time，而不是 output。 Andrew 說得好：有些團隊在 AI 助攻後，只是更快地淹沒在 review queue 中。
最後，文末的建議其實很樸實：去走一次 value stream、測 cycle time、找等待、限 WIP、問做事的人瓶頸在哪——這些都不華麗，但非常有效。
總結一句：寫得快永遠比不上「對的事情」被「順利地」送到用戶前。