程式設計師如何預估自己的專案開發時間？

霍夫斯塔特定律：實際時間總是比預期要長，即便你考慮到了霍夫斯塔特定律。

( Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law. — Douglas Hofstadter )

經常會有 PM 抱怨說，為什麼公司的開發永遠不能估計自己的專案時間？！然而機智的程式設計師早就對此司空見慣了。我甚至見過一個預計 2 天完成的專案最後花了 4 個月的時間，即使按照「時間翻倍」的經驗法則來看也是挺誇張的。從高階層面來看，問題在於 —— 工程師和 PM 或者其他人員對時間估算的方法和思維方式不同。

大多數工程師的第一反應是，如果一切按照計劃正常進行的話，寫出一個原型所需要的最短時間。而 PM 或者其他下游人員的想知道的是，專案什麼時候可以準備完畢，從此時到釋出的這段時間是多長？因此這完全是兩個不同的故事了。

所以對於工程師來說，掌握時間估算是一項必備技能，這意味著你是專業、穩定而高效的開發者。

為什麼需要進行時間估算？

外部依賴

任何有效的事情都不會憑空發生。專案通常存在外部依賴性，比如跟職能團隊的溝通（財務、PR、客戶支援）以及客戶的交流等。而跟這些外部依賴協調的往往是 PM 或者 CEO 的工作，這意味著最有資格做時間估算的人（工程師）並不是最需要做這些測算的人。這種不對稱導致了根本性的緊張。

優先順序

時間測算對確定優先順序也很關鍵。工程領域中價效比是一項重要指標，哪怕你在做的功能是全世界最厲害的，經過時間測算發現需要很長時間才能實現的話，那這個功能的優先順序也不會太高。

比方說你正在做一個專案，做成之後可以讓網站快 50%，但用同樣的時間你本來可以完成 2 個專案，而且每個專案都可以讓網站快 40%。如果你不花點時間進行初步測算的話，你永遠都不知道還可以做一個更快的網站！

初級時間估算

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

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

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

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

Step 1：制定技術方案

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

顆粒度在這裡是很重要的。如果有哪一部分讓人覺得不清楚，要麼是你應該瞭解更多相關知識，要麼得把它分解為更細緻的步驟。與此同時，如果一個步驟太細的話，又可能會太脆弱導致整個計劃無效，所以要把握好這個度。

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

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

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

Step 3：追加容錯時間

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

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

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

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

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

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

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

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

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

原文連結：https://mp.weixin.qq.com/s/nf9vAU9gNdkBZvTGuHZLvA