軟體估算很困難，但你還是得做

軟體專案估時很困難，這已是業界共識。《哈佛商業評論》的一項研究發現，六分之一的 IT 專案成本超支 200% 以上，而且時程延誤近 70%。

麥肯錫的另一項研究指出，IT 專案平均超支 45%，時程延誤 7%。研究發現大型軟體專案問題尤其嚴重：預算超過 1,500 萬美元的軟體專案，平均超支 66%，時程延誤平均達 33%。

有經驗的軟體開發者對此一定心有戚戚焉。你可能曾經說過：「喔，這個功能幾天就能搞定」，結果一個月後還沒做完。

軟體專案估時似乎總是應驗了霍夫史塔特定律：「即使考慮到霍夫史塔特定律，專案所需時間還是會比你預期的更長。」

很多人看到軟體專案時程估算這麼困難，就乾脆放棄了。業界甚至出現了「無需估算」的論點，主張完全停止估算軟體專案時程。

許多敏捷開發方法採用了 story points、T-shirt sizing 等相對評分系統，刻意避免使用時間單位來估算。

這些想法的確有其價值，我並不是要批評 story points。尤其是「無需估算」的專案管理方式，可以引導出更有效的時程討論：這類系統鼓勵大家問「接下來兩週我們可以完成什麼？」，而不是問「功能 X 需要多久？」。對於長期專案來說，這樣的思考方式通常更好。

然而，遲早會有人問「功能 X 什麼時候可以上線？」。有些時候，你必須給出一個準確的答案。例如，業務團隊如果能承諾新功能的時程，或許就能談成一筆大生意。

又例如，這個功能可能是其他團隊的重要依賴，他們需要知道時程才能安排工作。或者你的功能是新產品眾多組成部分之一，整個產品上市流程需要啟動並進行宣傳，這都需要時程規劃。

在技術職涯發展中，一個重要的秘訣就是學會如何準確估時。對我來說確實如此：我不怕給出時程，而且我已經學會如何做出夠準確的估算，讓大家信任我的判斷。

如果你總是迴避估時，在需要的時候無法給出時程，那麼你的職涯發展可能會受限。能夠告訴主管和同事預計何時完成哪些工作，並確實達成目標，是建立信任的關鍵。

不論你是個人貢獻者還是工程主管，這都適用：即使不擅長估時，你或許也能晉升為資深工程師或工程經理，但若想更上一層樓，你可能需要學習這項技能。

估時的確是一項可以學習的技能。你可以學習各種技巧，但某種程度上，技巧不是最重要的：無論你使用什麼技巧，練習才是關鍵。

如果你養成拆解專案並估算時程的習慣，你就可以將估算結果與實際情況比較，並據此調整。不斷重複這個過程，你就會越來越進步：你會了解團隊容易卡關的地方，以及工作進展快速的地方。

你會發現程式碼庫中哪些部分容易修改，哪些部分需要更多時間。你會了解自己的偏見，以及你最容易高估或低估的地方。

本系列的下一篇文章將介紹我使用的估算技巧，這個技巧對我來說很有效。但技巧本身不如一個更重要的觀點：軟體估算很困難，但你還是得做。