有位 PM 最近告訴我她面臨的一個難題：“軟件工程師永遠不能估算出他們的項目需要多長時間。我該怎麼辦？”還有兩位 CEO 最近也告訴我同樣的事情。從高級層面上講，這個問題在於在時間估算的時候，工程師、PM、經理、公關以及其他所有人的看法存在不同。大多數工程師本能考慮的是，如果一切都按照計劃進行，寫出一個可用的原型需要的最短時間。但下游的人想知道的是項目何時準備發佈——這完全是另外一回事了。
有位 PM 最近告訴我她面臨的一個難題：“軟件工程師永遠不能估算出他們的項目需要多長時間。我該怎麼辦？”還有兩位 CEO 最近也告訴我同樣的事情。
《為什麼程序員總是不能準確估測項目時間？》（http://blog.jobbole.com/24924/），我們都深有體會。我曾經遇到過一個項目，預計需要兩天完成，結果做了四個月。在這種情況下，即使用“時間翻倍”的經驗估算，也依然差出了一個數量級之多。這樣真的非常影響業務。我曾見過整個公司為了舉辦一個發佈活動費盡心力，結果卻不得不推遲數月。
從高級層面上講，這個問題在於在時間估算的時候，工程師、PM、經理、公關以及其他所有人的看法存在不同。大多數工程師本能考慮的是，如果一切都按照計劃進行，寫出一個可用的原型需要的最短時間。但下游的人想知道的是項目何時準備發佈——這完全是另外一回事了。
對於工程師而言，把握估算項目所需時間是一段終身的旅程。忽視這個問題，會給你以及與你直接或間接接觸的每個人帶來困擾。精準把握估算項目所需時間會讓你脫穎而出，同事們將會把這些和你的專業精神，穩定性和工作質量相關聯。
為什麼我們要時間估算
首先我來回答一下工程師經常問到的問題：“為什麼要估算時間？”許多工程師抱怨（有一定道理）這是一份間接成本。“如果我開足馬力去做，會更快地完成項目！”
主要有兩個原因：外部依賴和優先次序。
外部依賴
沒有任何有效活動會在真空中運作。項目通常有外部依賴，例如與非工程團隊（通訊，金融，公關，客服）、其他工程團隊甚至最終用戶本身的協作。協調這些外部依賴關係通常是經理、PM或CEO的職責。這意味著最有資格做時間估算的人（工程師）不是最需要估算時間信息的人。這種不對稱導致了根本的矛盾。
優先次序
時間估算也是確定工作優先級的關鍵。“錢花的值不值”是項目中的重要指標，沒有真正的估算，也就無法確定錢花的值不值。即使你正在做的功能是世界上最棒的，如果花時間做一個全面的估計，你可能會意識到這將需要花費很長時間才能完成。
假設你正在做一個項目，這將使網站的速度提升50％，但在相同的時間內，可以完成兩個項目，每個項目將使網站快40％。如果沒有花時間做一個初步的估計，你永遠不會知道你可以做出一個訪問速度更快的網站！
時間估算入門
現在大家都同意絕大多數時候都需要時間估算，我們來談談技巧。
我們低估時間是因為我們考慮的是“我需要多長時間才能寫出這個基本版本？”
但交付的東西不僅僅是基礎版。還需要考慮到編寫，測試，調試和潤色所需的時間。不要忘了開會、訪談、做代碼審查以及發送電子郵件等事情也需要時間。
低估時間的另一個原因是我們幾乎總是在編碼過程中遇到“未知數”，這些未知數是不可能完全預測和考慮周全的。也許IDE會更新，中斷了項目，你花費一天的時間去修復它。在時間估算中無法考慮到這一點。
但是，我們仍然可以比最初的直覺做的更好。以下是我的做法：
第一步：制定技術計劃
在著手開始工作前，你應該已經有了一份技術規劃或設計文件，可以為任何重要的項目提供幫助。可以用這個讓別人知道你在做什麼，並獲得反饋。制定技術計劃是啟動時間估算的理想階段。當完成技術細節設計時，會發現未知問題，你將會神奇地修改估算時間。也許你會意識到，可能需要把一個正在使用的庫升級到新版本，這可能會增加一天的時間。甚至可能意識到計劃使用的庫實際上並不存在，需要自己寫。
顆粒度在這裡很重要。如果任何一步感到模糊或者不清楚，或許你會跳過這個步驟（應該學習更多），或者需要將其分解成更小的步驟。同時如果某個步驟粒度太細，那麼在實踐中可能會不堪一擊使整個計劃無效。
有關技術計劃裡應該考慮哪些方面，請參閱 Alicia Chen 的這篇文章《What do you mean ‘we need more time’?》。其中一個關鍵點是消除與 PM 或其他利益相關方之間的任何潛在歧義，這樣最終你就不會因做錯了某些事而不得不重新開始。
第二步：為每個步驟增加時間預算
估算一下技術方案中的每一步將執行多長時間。這通常會涉及對細節的研究（“有沒有已經有人實現了這個庫的功能？”）。根據項目的性質，羅列一個簡單原型，可能會有助於暴露出許多未來潛在的痛點。
第三步：添加大量的額外時間
現在你已經有一個初步的估計，但是我們之前提到的所有的點還需要考慮。
- 隨時調試：總是會有Bug。調試很大程度上取決於你對特定代碼庫的經驗和代碼庫的成熟度。
- 會議、訪談、假期等：可能你不會在工位一直編碼。你真正會有多少個小時進行編碼？估算時應該至少看看你的日曆。
- 最終測試和bug清理：通常你在編碼的同時應該也在寫測試，但是很多團隊在發佈前，需要進行一輪潤色工作或集成測試。在估算中要給予這些工作足夠的預算。如果分階段進行推出，最初推出的1％內容，可能會暴露需要修復的bug，需要考慮到這一點。
- 代碼審查：項目需要做幾輪代碼審查？通常需要多長時間？一定要確保有充足的評審人員（也可以確認一下他們的日程安排）。如果這是隻有一個評審人員的項目，應該提前徵求他們同意，要求他們安排一名候補人員，以防評審人員會休假或者在關鍵節點太忙。
一旦開始將所有這些時間開銷添加到項目中，就會開始看到自己的時間估算值與項目實際啟動時匹配地多了。是的，實際情況可能會比估計的更長，你可能會倍感壓力去縮短工期。但是當大家知道他們可以依靠你時，他們會欣賞你的估算。
第四步：項目發佈後，對時間估算做回顧總結
在項目完成之後回顧一下所做的工作，這聽起來很痛苦。但是這種審查回顧會讓你從中學到很多，下次做的更好。
哪個過程結果與預期的時間不同？如果集成測試花費了比預期兩倍的時間，記下來，下次給測試留下更多的時間。或者嘗試改進集成測試系統。
你一定會看到自己的估算隨著時間的推移而不斷改善。甚至可以在這個過程中提出一些很好的見解，來幫助整個團隊。
最後，一切都與溝通有關
你的時間表和其他變動事宜，應該提前告知其他人。如果在發佈前一個月讓經理知道你正在使用的庫中存在新的安全漏洞，不得不從頭開始，他們會有時間相應的通知公關，財務或用戶，需要推遲發佈。
和其他協作方溝通得來的重要反饋，有助於調整時間估算。設計師可能會說：“哦，如果這個花哨的動畫將要花一整週的時間，我們可以完全剪掉它。”PM可能會補充說：“這只是用戶研究中的一個原型實驗。我們不需要為這個迭代做太多的bug清理。”經理可能會說，“你把一半的時間用在了開會？我來解決這個事情！”
對於工程師來說，不要為了取悅上級，向不切實際的時間表妥協。坦誠地說出你的估算時間和變更方式，這樣更專業。
對於其他所有人來說，尊重估算的時間是很難的，而且這需要一個過程。你只能坐下來砍掉實際上不需要發佈的功能或階段，來縮短預計的時間，而不是通過嘮叨把時間縮短。
我們永遠無法完美估算項目所需的時間。唯一的辦法就是保持開放、多溝通、有同理心，並果斷地確定優先次序。
閱讀更多 IT小白進階之路 的文章
