本篇文章更新時間：2026/01/25
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
為什麼軟體工程師永遠估不準時間？從政治、未知數到真正該做的事
編輯前言：這篇文章來自 Sean Goedecke 的部落格文章 How I estimate work as a staff software engineer。我之所以想寫筆記，是因為它揭穿了一個我們在職涯中都默默知道、卻又不好意思承認的真相：估時不是技術問題，而是政治問題。
核心觀點 (Key Takeaways)
- 软件專案無法被準確估時，因為真正耗時的永遠是未知工作，而非已知工作。
- 估時不是工程師的技術輸出，而是管理階層用來協商、排序與爭取資源的政治工具。
- 聰明的工程師不是「如何精準拆解任務」，而是「理解管理層想要什麼估時，並給出符合政治現實的多方案、風險評估」。
深入解析
這篇文章一開始就點破業界普遍存在的「禮貌性假象」：
我們假裝工程師可以藉由努力學會如何準確估時，讓公司做出更好的商業規劃。
作者坦白說，這根本不是真的。除了非常微小且完全理解的工作，大部分實際的軟體工程任務都是探索、研究、拆解遺留系統、處理未預期的問題。換句話說：
- 真正花時間的永遠是未知數，而未知數無法事先估時。
估時不是來自工程師，而是管理者的「隱含需求」
作者的觀察很犀利：工程師給出的估時只是一個起點，接著它會在管理鏈中被放大、壓縮或調整，以符合各層管理者的需要。估時越長，可能被要求壓縮；估時太短，又會被要求加 buffer。
更重要的是：
估時其實是管理階層協商資源、說服彼此、決定專案存亡的工具。
工程師只是其中一小部分。
估時反過來定義工作內容，而不是工作內容決定估時
這段我非常喜歡，作者描述得很真實。
假設你被要求做「PDF 對話功能」。如果有六個月，你會打造完整的：
- 上傳系統
- 嵌字向量化、語義搜尋
- PDF 圖像解析
但如果你只有一天？你自然會找最簡單的路，例如：
- Client-side 直接把 PDF 轉純文字
- 全文塞進 LLM context
- 或做一個簡單的 grep 工具
估時不只是預測，也是限制、選擇、取捨。
筆者心得與啟發
讀完後，我最大的感想是：
估時不是技術能力，而是一種組織智慧。
強求精準的估時，就像強迫氣象專家告訴你哪一天一定下雨。不是做不到，而是預測本身就存在極大的不確定性。與其糾結準確度，不如學會作者提到的三件事：
- 先理解管理層真正的想法：他們要的是「什麼時候需要什麼結果」的選項與風險，而非一個「兩週」的空洞數字。
- 估已知不如估未知：已知的事不用擔心，真正拖垮進度的是未知的深坑。你的估時應該反映未知，而不是寫在 Jira 上的那幾個 ticket。
- 提供多方案，而非單一時間點：例如：
- 方案 A：正攻，需要 X、Y、Z 都順利，但風險大。
- 方案 B：繞路，犧牲部分品質，但可如期。
- 方案 C：請求外援，交換資源。
這不只是對工程團隊好，也讓管理層做出真正的策略決策。
這篇文章讓我重新思考工程師與管理層之間的關係。工程師很常理直氣壯地說「估時太困難」、「我沒辦法回答」，但事實上，只要你拒絕估，管理層就會找別人估；而那個人很可能沒有你技術背景，結果反而更糟。
最成熟的工程師不是逃避估時，而是懂得用估時影響組織。
這也是我最推薦這篇文章的原因。