專案時間的估算對專案的成敗至關重要。專案時間管理包括了專案按時完成所需的各個過程。但是，在實際專案中，經常出現專案延期，估算嚴重不準確的現象。
預估時間本身就很難。每個程式設計師的估計都會跟真正需要的時間有些差距。估計時間短了說明有些事情被忽略了(編譯，測試，提交**)。估計時間超了說明任務太大，難以理解。
對於資歷較淺的程式設計師，這種估計誤差是混亂的，他們經常會輕視一些任務，同時又對一些稍微有難度的任務過分高估。我認為，對乙個有經驗的程式設計師，乙個任務的時間應該在半小時到24小時之間，超出24小時的任務都需要拆分。程式設計師在腦中想一想可能會認為要60小時，但實際上即使是很有經驗的程式設計師也需要將任務分成可控的模組再來分析做決定。
還有乙個很重要的需要認識到的一點是，程式設計上的經驗並不等同於時間估計上的經驗。乙個從沒有做過工期估計的程式設計師不會擅長估計時間。如果不去拿真正需要的時間和估計出的時間進行比較，你不可能從其它反饋資訊之得到正確估計時間的經驗。
每個程式設計師都會用到評估技巧。為了提高你的這項技能，你可以在你從事的每個任務上進行鍛鍊。在任務開始時先預估開發所需時間，拿它跟你最終真正用掉的時間進行對比。這樣，你不僅在對任務細節的理解上有提高，同時也提高了你對時間預估的技能。
霍夫斯塔特定律：實際時間總是比預期要長，即便你考慮到了霍夫斯塔特定律。
經常會有 pm 抱怨說，為什麼公司的開發永遠不能估計自己的專案時間？！然而機智的程式設計師早就對此司空見慣了。我甚至見過乙個預計 2 天完成的專案最後花了 4 個月的時間，即使按照「時間翻倍」的經驗法則來看也是挺誇張的。從高階層面來看，問題在於 —— 工程師和 pm 或者其他人員對時間估算的方法和思維方式不同。
大多數工程師的第一反應是，如果一切按照計畫正常進行的話，寫出乙個原型所需要的最短時間。而 pm 或者其他下游人員的想知道的是，專案什麼時候可以準備完畢，從此時到發布的這段時間是多長？因此這完全是兩個不同的故事了。
所以對於工程師來說，掌握時間估算是一項必備技能，這意味著你是專業、穩定而高效的開發者。
為什麼需要進行時間估算？
外部依賴
任何有效的事情都不會憑空發生。專案通常存在外部依賴性，比如跟職能團隊的溝通（財務、pr、客戶支援）以及客戶的交流等。而跟這些外部依賴協調的往往是 pm 或者ceo的工作，這意味著最有資格做時間估算的人（工程師）並不是最需要做這些測算的人。這種不對稱導致了根本性的緊張。
優先順序時間測算對確定優先順序也很關鍵。工程領域中價效比是一項重要指標，哪怕你在做的功能是全世界最厲害的，經過時間測算發現需要很長時間才能實現的話，那這個功能的優先順序也不會太高。
比方說你正在做乙個專案，做成之後可以讓**快 50%，但用同樣的時間你本來可以完成 2 個專案，而且每個專案都可以讓**快 40%。如果你不花點時間進行初步測算的話，你永遠都不知道還可以做乙個更快的**！
初級時間估算
假設我們達成了時間估算非常重要這個共識，那麼我們繼續看一下如何估算。通常情況下，我們低估所需時間是因為我們想的是「寫出乙個原型需要多長時間？」。
但是，交付的東西往往要比原型大多了，你還需要考慮測試、除錯、優化所花費的時間。還有開會、訪談、**評審，甚至發郵件都是需要花費時間的。
低估所需時間的另乙個原因是意外的問題，這些問題往往不能被充分考慮到，比如 ide 更新而讓你多花了一天去配置環境等等。
基於此，我們最好不要太相信所謂的經驗和直覺。
step 1：制定技術方案
在開始任何乙個重要專案之前，你都應該有乙份技術計畫或者設計文件。這個文件的目的在於讓別人知道你在做的事情，並能獲得反饋。當你注意到其中的技術細節時，你就會更清晰知道具體所耗費的時間，比如把某個庫更新到新版本，可能會多花一天的時間。你甚至還得自己寫乙個庫。
想要知道你的文件裡應該考慮哪些東西，可以看看aliciachen 的 這篇文章。關鍵在於跟 pm 溝通清楚，消除有歧義的地方，這樣才不會導致最後要推翻重來。
step 2：為每一步新增時間估算
文件裡的每一步實現需要多少時間，這往往牽涉到對細節的研究（這個是不是已經有庫了？）。因此視專案性質而言，先做乙個簡單的原型可以幫助揭示許多潛在的痛點。
step 3：追加容錯時間
現在你已經有了初步的時間估算，不過還有許多其他需要考慮的因素。
隨時除錯：bug 難以避免，這取決於開發者對特定**庫的經驗以及**庫的成熟度。會議和假期：開會或者放假時一般來說是不會敲**的，所以真正敲**有多長時間？因此時間估算時要好好看看日程表。最終測試：通常應該一邊編碼一邊測試，但很多團隊在發布前還需要做整合測試，因此在你的估算中留出這部分的時間。**評審：在這個**庫中你一般需要進行幾輪？每輪需要多少時間？要經過多少評審人？留意評審人的日程安排確保**評審的時間。
當你把交付時間的開銷也考慮進去，你就能看到自己的時間估算和專案的實際發布時間要匹配得多。儘管實際情況可能還會更長，你也可能會因壓力而需要縮短工期。但當大家明白你的估算更準確時，也會更信任你。
step 4：發布後評審上期時間估算
覆盤還挺痛苦的，但是回顧能讓你在下一次做得更好。每乙個實際與預期時間不匹配的專案都發生了什麼，找到原因並改進它。
總而言之一切在於溝通。提前溝通、經常溝通，了解彼此的日程和需求變更。
跟 pm 等相關參與者的溝通也能讓對方提供可能會影響你估算的重要資訊。一位設計師可能會說這個動畫需要一周工期，乾脆砍掉不要了。另一位 pm 也可能補充說這個原型只是對使用者進行研究的而已，這次迭代不用處理太多 bug。
對於工程師來說，不要做不切實際的更短工期的妥協，開誠布公更顯專業。對於 pm 和其他人來說，尊重這一估算可能需要乙個過程，但要知道光靠嘮叨是不可能縮短工期的。
專案時間估算不容易，唯有善於溝通、有同理心以及確定功能優先順序才可以。
閱讀更多
到外企？為什麼別的程式設計師那麼容易
一招教你打造乙個滑動置頂的視覺特效
ndk專案實戰—高仿360手機助手之解除安裝監聽
（android）面試題***（精選版）
相信自己，沒有做不到的，只有想不到的
程式設計師如何預估自己的專案開發時間？
作者丨愛編碼的coder 專案時間的估算對專案的成敗至關重要。專案時間管理包括了專案按時完成所需的各個過程。但是，在實際專案中，經常出現專案延期，估算嚴重不準確的現象。預估時間本身就很難。每個程式設計師的估計都會跟真正需要的時間有些差距。估計時間短了說明有些事情被忽略了 編譯，測試，提交 估計時間超...
程式設計師軟體專案預估的寶貴經驗
我最近參加了乙個關於軟體預估的課程。對於這種本質上就是非精確的科學，我一向都非常謹慎，因為我深信預估可以創造價值。在這個歷時兩個小時的課程中，我發現了如何提醒大家進入預算而不必過度分析和思考的方法。我們經常能聽到專案經理和開發人員之間類似於這樣的對話 pm 你能不能給我乙個開發某某功能所需要的預估時...
程式設計師如何鍛鍊自己
說到鍛鍊，運動這個問題，實際上我們都知道他很重要，但是少有人會真正的堅持運動下去，由於我們的工種問題，職業病也非常的多，長期處於乙個亞健康的狀態，所以鍛鍊是必不可少的，我們應該關注自己的身體健康，不要等到真正出現什麼病了才後悔莫及。鍛鍊能提高你的免疫力，健壯你的體格，能長高，能 能美白，能 整容 e...