霍夫斯塔特定律：實際花費的時間總是比預期的要長，即便你考慮到了本條定律。——Douglas Hofstadter

有位 PM 最近告訴我她面臨的一個難題：“軟體工程師永遠不能估算出他們的專案需要多長時間。我該怎麼辦？”還有兩位 CEO 最近也告訴我同樣的事情。

《為什麼程式設計師總是不能準確估測專案時間？》，我們都深有體會。我曾經遇到過一個專案，預計需要兩天完成，結果做了四個月。在這種情況下，即使用“時間翻倍”的經驗估算，也依然差出了一個數量級之多。這樣真的非常影響業務。我曾見過整個公司為了舉辦一個釋出活動費盡心力，結果卻不得不推遲數月。

從高階層面上講，這個問題在於在時間估算的時候，工程師、PM、經理、公關以及其他所有人的看法存在不同。大多數工程師本能考慮的是，如果一切都按照計劃進行，寫出一個可用的原型需要的最短時間。但下游的人想知道的是專案何時準備釋出——這完全是另外一回事了。

對於工程師而言，把握估算專案所需時間是一段終身的旅程。忽視這個問題，會給你以及與你直接或間接接觸的每個人帶來困擾。精準把握估算專案所需時間會讓你脫穎而出，同事們將會把這些和你的專業精神，穩定性和工作質量相關聯。

為什麼我們要時間估算

首先我來回答一下工程師經常問到的問題：“為什麼要估算時間？”許多工程師抱怨（有一定道理）這是一份間接成本。“如果我開足馬力去做，會更快地完成專案！”

主要有兩個原因：外部依賴和優先次序。

外部依賴

沒有任何有效活動會在真空中運作。專案通常有外部依賴，例如與非工程團隊（通訊，金融，公關，客服）、其他工程團隊甚至終端使用者本身的協作。協調這些外部依賴關係通常是經理、PM或CEO的職責。這意味著最有資格做時間估算的人（工程師）不是最需要估算時間資訊的人。這種不對稱導致了根本的矛盾。

優先次序

時間估算也是確定工作優先順序的關鍵。“錢花的值不值”是專案中的重要指標，沒有真正的估算，也就無法確定錢花的值不值。即使你正在做的功能是世界上最棒的，如果花時間做一個全面的估計，你可能會意識到這將需要花費很長時間才能完成。

假設你正在做一個專案，這將使網站的速度提升50％，但在相同的時間內，可以完成兩個專案，每個專案將使網站快40％。如果沒有花時間做一個初步的估計，你永遠不會知道你可以做出一個訪問速度更快的網站！

時間估算入門

現在大家都同意絕大多數時候都需要時間估算，我們來談談技巧。

我們低估時間是因為我們考慮的是“我需要多長時間才能寫出這個基本版本？”

但交付的東西不僅僅是基礎版。還需要考慮到編寫，測試，除錯和潤色所需的時間。不要忘了開會、訪談、做程式碼審查以及傳送電子郵件等事情也需要時間。

低估時間的另一個原因是我們幾乎總是在編碼過程中遇到“未知數”，這些未知數是不可能完全預測和考慮周全的。也許IDE會更新，中斷了專案，你花費一天的時間去修復它。在時間估算中無法考慮到這一點。

但是，我們仍然可以比最初的直覺做的更好。以下是我的做法：

第一步：制定技術計劃

在著手開始工作前，你應該已經有了一份技術規劃或設計檔案，可以為任何重要的專案提供幫助。可以用這個讓別人知道你在做什麼，並獲得反饋。制定技術計劃是啟動時間估算的理想階段。當完成技術細節設計時，會發現未知問題，你將會神奇地修改估算時間。也許你會意識到，可能需要把一個正在使用的庫升級到新版本，這可能會增加一天的時間。甚至可能意識到計劃使用的庫實際上並不存在，需要自己寫。

顆粒度在這裡很重要。如果任何一步感到模糊或者不清楚，或許你會跳過這個步驟（應該學習更多），或者需要將其分解成更小的步驟。同時如果某個步驟粒度太細，那麼在實踐中可能會不堪一擊使整個計劃無效。

有關技術計劃裡應該考慮哪些方面，請參閱 Alicia Chen 的這篇文章《What do you mean ‘we need more time’?》。其中一個關鍵點是消除與 PM 或其他利益相關方之間的任何潛在歧義，這樣最終你就不會因做錯了某些事而不得不重新開始。

第二步：為每個步驟增加時間預算

估算一下技術方案中的每一步將執行多長時間。這通常會涉及對細節的研究（“有沒有已經有人實現了這個庫的功能？”）。根據專案的性質，羅列一個簡單原型，可能會有助於暴露出許多未來潛在的痛點。

第三步：新增大量的額外時間

現在你已經有一個初步的估計，但是我們之前提到的所有的點還需要考慮。

• 隨時除錯：總是會有Bug。除錯很大程度上取決於你對特定程式碼庫的經驗和程式碼庫的成熟度。

• 會議、訪談、假期等：可能你不會在工位一直編碼。你真正會有多少個小時進行編碼？估算時應該至少看看你的日曆。

• 最終測試和bug清理：通常你在編碼的同時應該也在寫測試，但是很多團隊在釋出前，需要進行一輪潤色工作或整合測試。在估算中要給予這些工作足夠的預算。如果分階段進行推出，最初推出的1％內容，可能會暴露需要修復的bug，需要考慮到這一點。

• 程式碼審查：專案需要做幾輪程式碼審查？通常需要多長時間？一定要確保有充足的評審人員（也可以確認一下他們的日程安排）。如果這是隻有一個評審人員的專案，應該提前徵求他們同意，要求他們安排一名候補人員，以防評審人員會休假或者在關鍵節點太忙。

一旦開始將所有這些時間開銷新增到專案中，就會開始看到自己的時間估算值與專案實際啟動時匹配地多了。是的，實際情況可能會比估計的更長，你可能會倍感壓力去縮短工期。但是當大家知道他們可以依靠你時，他們會欣賞你的估算。

第四步：專案釋出後，對時間估算做回顧總結

在專案完成之後回顧一下所做的工作，這聽起來很痛苦。但是這種審查回顧會讓你從中學到很多，下次做的更好。

哪個過程結果與預期的時間不同？如果整合測試花費了比預期兩倍的時間，記下來，下次給測試留下更多的時間。或者嘗試改進整合測試系統。

你一定會看到自己的估算隨著時間的推移而不斷改善。甚至可以在這個過程中提出一些很好的見解，來幫助整個團隊。

最後，一切都與溝通有關

你的時間表和其他變動事宜，應該提前告知其他人。如果在釋出前一個月讓經理知道你正在使用的庫中存在新的安全漏洞，不得不從頭開始，他們會有時間相應的通知公關，財務或使用者，需要推遲釋出。

和其他協作方溝通得來的重要反饋，有助於調整時間估算。設計師可能會說：“哦，如果這個花哨的動畫將要花一整週的時間，我們可以完全剪掉它。”PM可能會補充說：“這只是使用者研究中的一個原型實驗。我們不需要為這個迭代做太多的bug清理。”經理可能會說，“你把一半的時間用在了開會？我來解決這個事情！”

對於工程師來說，不要為了取悅上級，向不切實際的時間表妥協。坦誠地說出你的估算時間和變更方式，這樣更專業。

對於其他所有人來說，尊重估算的時間是很難的，而且這需要一個過程。你只能坐下來砍掉實際上不需要釋出的功能或階段，來縮短預計的時間，而不是通過嘮叨把時間縮短。

我們永遠無法完美估算專案所需的時間。唯一的辦法就是保持開放、多溝通、有同理心，並果斷地確定優先次序。