我把程式設計師的工作從某種難易程度上分為兩種情況，一種是重複以往的有經驗的工作，另外一種是需要深入研究的創新型工作，前者因為有過往研發及除錯經驗比較容易預估時間，後者相對複雜一點，會經常遇到所謂的‘’坑‘，為了填這些坑，時間往往很隨機，我個人經驗都是快速評估專案難點，透過預覽學習資料（通常都是網上獲取），評估技術可行性以及預估專案研發時間。因行業差異，實際方法可能有所差異，個人經驗，僅供參考。

這個要跟專案的目的和範圍有關，其次是專案在需求階段的規劃和分解，如果好的專案經理和主程基本就已經可以預估開發時間了，偶爾有延後，稍微加個班都能解決，永遠delay的原因是沒有分解到位，開發的點不明確，缺乏技術認知，缺乏對關鍵流程或者需求的明確說明，缺乏關鍵用例或者故事

初級時間估算

假設我們達成了時間估算非常重要這個共識，那麼我們繼續看一下如何估算。通常情況下，我們低估所需時間是因為我們想的是「寫出一個原型需要多長時間？」。

但是，交付的東西往往要比原型大多了，你還需要考慮測試、除錯、最佳化所花費的時間。還有開會、訪談、程式碼評審，甚至發郵件都是需要花費時間的。

低估所需時間的另一個原因是意外的問題，這些問題往往不能被充分考慮到，比如 IDE 更新而讓你多花了一天去配置環境等等。

基於此，我們最好不要太相信所謂的經驗和直覺。

Step 1：制定技術方案

在開始任何一個重要專案之前，你都應該有一份技術計劃或者設計文件。這個文件的目的在於讓別人知道你在做的事情，並能獲得反饋。當你注意到其中的技術細節時，你就會更清晰知道具體所耗費的時間，比如把某個庫更新到新版本，可能會多花一天的時間。你甚至還得自己寫一個庫。

想要知道你的文件裡應該考慮哪些東西，可以看看AliciaChen 的 這篇文章。關鍵在於跟 PM 溝通清楚，消除有歧義的地方，這樣才不會導致最後要推翻重來。

Step 2：為每一步新增時間估算

文件裡的每一步實現需要多少時間，這往往牽涉到對細節的研究（這個是不是已經有庫了？）。因此視專案性質而言，先做一個簡單的原型可以幫助揭示許多潛在的痛點。

Step 3：追加容錯時間

現在你已經有了初步的時間估算，不過還有許多其他需要考慮的因素。

隨時除錯：Bug 難以避免，這取決於開發者對特定程式碼庫的經驗以及程式碼庫的成熟度。會議和假期：開會或者放假時一般來說是不會敲程式碼的，所以真正敲程式碼有多長時間？因此時間估算時要好好看看日程表。最終測試：通常應該一邊編碼一邊測試，但很多團隊在釋出前還需要做整合測試，因此在你的估算中留出這部分的時間。程式碼評審：在這個程式碼庫中你一般需要進行幾輪？每輪需要多少時間？要經過多少評審人？留意評審人的日程安排確保程式碼評審的時間。

當你把交付時間的開銷也考慮進去，你就能看到自己的時間估算和專案的實際釋出時間要匹配得多。儘管實際情況可能還會更長，你也可能會因壓力而需要縮短工期。但當大家明白你的估算更準確時，也會更信任你。

Step 4：釋出後評審上期時間估算

覆盤還挺痛苦的，但是回顧能讓你在下一次做得更好。每一個實際與預期時間不匹配的專案都發生了什麼，找到原因並改進它。

總而言之一切在於溝通。提前溝通、經常溝通，瞭解彼此的日程和需求變更。

跟 PM 等相關參與者的溝通也能讓對方提供可能會影響你估算的重要資訊。一位設計師可能會說這個動畫需要一週工期，乾脆砍掉不要了。另一位 PM 也可能補充說這個原型只是對使用者進行研究的而已，這次迭代不用處理太多 bug。

對於工程師來說，不要做不切實際的更短工期的妥協，開誠佈公更顯專業。對於 PM 和其他人來說，尊重這一估算可能需要一個過程，但要知道光靠嘮叨是不可能縮短工期的。

專案時間估算不容易，唯有善於溝通、有同理心以及確定功能優先順序才可以。