來源：https://twitter.com/svpino/status/1696187613739208878?s=20
自古至今，軟體開發預估一直都是我們用來欺騙自己的謊言之一。
我們都知道這些預估一定不準，但都假裝這些數字多少有些參考價值。等到情況真的爆炸、一發不可收拾的時候，我們才會因此覺得很生氣。
我在大學生的時候，花了很長的時間專注於研究軟體開發預估的方法。
畢業之後，我寫了很多關於這個主題的文章。
接著，我開始在一家公司上班，花了數年的時間研究如何才能讓軟體開發預估更加準確。公司利用我建立的工具產出的軟體，創造了數百萬美元的營業額。
關於這個主題的必讀書目，我沒有漏讀任何一本。Steve McConnel 的著作《軟體預估 (Software Estimation)》我簡直倒背如流。
而我學到最重要的教訓就是：
我們無法預估軟體開發所需的時間或成本。不管是評估者是誰、或是評估者有沒有經驗，都一樣。
要能預估出值得參考的數字，基本上就是一部科幻小說。
而最精采的就是：
他們會要求你給出預估的數字。他們會說：「我們知道這只是預估，難免和現實有出入啦！」，然後保證到時候不會要你負責。
但他們就是會。沒有例外。
這樣的情況有兩種解決方案。第一個方案，我推薦給那些沒有選擇的人：
-
把「快速 (quick)」、「單純 (simple)」、「直覺 (straightforward)」、「簡單 (easy)」，以及所有類似的單字從你的字彙中移除。絕對不要用。不能讓別人用這些字眼形容你的工作內容。
-
絕對不要主動提供預估的數字。你所說的一切都會變成用來質疑你的證據。
-
如果被逼要預估，只預估你知道今天能完成的工作。數字一定要是一個範圍，例如：「這件事要我需要 2 到 4 小時。」
-
如果事情你今天做不完，就要用「天」或「週」當成評估的單位。例如：「我應該可以在本週結束之前完成這個功能。」不要用「小時」當單位去評估未來的工作。
但我們都知道，老闆一定會強迫你給出預估的時程。此時應該這麼做：
-
先在心裡預估你覺得完成這個任務要花多少時間。
-
把這個數字乘以 3。這就是你的預估範圍的下限。
-
把下限乘以 2。這就是預估範圍的上限。
舉例來說：如果你覺得某件事情大約一個工作天可以完成，你就要說「大約需要 3 到 6 天」。
然後有趣的是：
你還是沒有辦法準確地在 3 到 6 天中完成。用這個方法估出來的數字，跟其他方法一樣，都是個屁。
所以，這個問題的真正解決方案就是：
去一家完全不管什麼軟體開發預估的公司上班。