摘要：預(yù)估時(shí)間本身就很難。每個(gè)程序員的估計(jì)都會(huì)跟真正需要的時(shí)間有些差距。當(dāng)你把交付時(shí)間的開銷也考慮進(jìn)去，你就能看到自己的時(shí)間估算和項(xiàng)目的實(shí)際發(fā)布時(shí)間要匹配得多。

項(xiàng)目時(shí)間的估算對(duì)項(xiàng)目的成敗至關(guān)重要。項(xiàng)目時(shí)間管理包括了項(xiàng)目按時(shí)完成所需的各個(gè)過(guò)程。但是，在實(shí)際項(xiàng)目中，經(jīng)常出現(xiàn)項(xiàng)目延期，估算嚴(yán)重不準(zhǔn)確的現(xiàn)象。

預(yù)估時(shí)間本身就很難。每個(gè)程序員的估計(jì)都會(huì)跟真正需要的時(shí)間有些差距。估計(jì)時(shí)間短了說(shuō)明有些事情被忽略了(編譯，測(cè)試，提交代碼)。估計(jì)時(shí)間超了說(shuō)明任務(wù)太大，難以理解。

對(duì)于資歷較淺的程序員，這種估計(jì)誤差是混亂的，他們經(jīng)常會(huì)輕視一些任務(wù)，同時(shí)又對(duì)一些稍微有難度的任務(wù)過(guò)分高估。我認(rèn)為，對(duì)一個(gè)有經(jīng)驗(yàn)的程序員，一個(gè)任務(wù)的時(shí)間應(yīng)該在半小時(shí)到24小時(shí)之間，超出24小時(shí)的任務(wù)都需要拆分。程序員在腦中想一想可能會(huì)認(rèn)為要60小時(shí)，但實(shí)際上即使是很有經(jīng)驗(yàn)的程序員也需要將任務(wù)分成可控的模塊再來(lái)分析做決定。

還有一個(gè)很重要的需要認(rèn)識(shí)到的一點(diǎn)是，編程上的經(jīng)驗(yàn)并不等同于時(shí)間估計(jì)上的經(jīng)驗(yàn)。一個(gè)從沒有做過(guò)工期估計(jì)的程序員不會(huì)擅長(zhǎng)估計(jì)時(shí)間。如果不去拿真正需要的時(shí)間和估計(jì)出的時(shí)間進(jìn)行比較，你不可能從其它反饋信息之得到正確估計(jì)時(shí)間的經(jīng)驗(yàn)。

每個(gè)程序員都會(huì)用到評(píng)估技巧。為了提高你的這項(xiàng)技能，你可以在你從事的每個(gè)任務(wù)上進(jìn)行鍛煉。在任務(wù)開始時(shí)先預(yù)估開發(fā)所需時(shí)間，拿它跟你最終真正用掉的時(shí)間進(jìn)行對(duì)比。這樣，你不僅在對(duì)任務(wù)細(xì)節(jié)的理解上有提高，同時(shí)也提高了你對(duì)時(shí)間預(yù)估的技能。

霍夫斯塔特定律：實(shí)際時(shí)間總是比預(yù)期要長(zhǎng)，即便你考慮到了霍夫斯塔特定律。

經(jīng)常會(huì)有 PM 抱怨說(shuō)，為什么公司的開發(fā)永遠(yuǎn)不能估計(jì)自己的項(xiàng)目時(shí)間？！然而機(jī)智的程序員早就對(duì)此司空見慣了。我甚至見過(guò)一個(gè)預(yù)計(jì) 2 天完成的項(xiàng)目最后花了 4 個(gè)月的時(shí)間，即使按照「時(shí)間翻倍」的經(jīng)驗(yàn)法則來(lái)看也是挺夸張的。從高級(jí)層面來(lái)看，問(wèn)題在于 —— 工程師和 PM 或者其他人員對(duì)時(shí)間估算的方法和思維方式不同。

大多數(shù)工程師的第一反應(yīng)是，如果一切按照計(jì)劃正常進(jìn)行的話，寫出一個(gè)原型所需要的最短時(shí)間。而 PM 或者其他下游人員的想知道的是，項(xiàng)目什么時(shí)候可以準(zhǔn)備完畢，從此時(shí)到發(fā)布的這段時(shí)間是多長(zhǎng)？因此這完全是兩個(gè)不同的故事了。

所以對(duì)于工程師來(lái)說(shuō)，掌握時(shí)間估算是一項(xiàng)必備技能，這意味著你是專業(yè)、穩(wěn)定而高效的開發(fā)者。

為什么需要進(jìn)行時(shí)間估算？

任何有效的事情都不會(huì)憑空發(fā)生。項(xiàng)目通常存在外部依賴性，比如跟職能團(tuán)隊(duì)的溝通（財(cái)務(wù)、PR、客戶支持）以及客戶的交流等。而跟這些外部依賴協(xié)調(diào)的往往是 PM 或者CEO的工作，這意味著最有資格做時(shí)間估算的人（工程師）并不是最需要做這些測(cè)算的人。這種不對(duì)稱導(dǎo)致了根本性的緊張。

時(shí)間測(cè)算對(duì)確定優(yōu)先級(jí)也很關(guān)鍵。工程領(lǐng)域中性價(jià)比是一項(xiàng)重要指標(biāo)，哪怕你在做的功能是全世界最厲害的，經(jīng)過(guò)時(shí)間測(cè)算發(fā)現(xiàn)需要很長(zhǎng)時(shí)間才能實(shí)現(xiàn)的話，那這個(gè)功能的優(yōu)先級(jí)也不會(huì)太高。

比方說(shuō)你正在做一個(gè)項(xiàng)目，做成之后可以讓網(wǎng)站快 50%，但用同樣的時(shí)間你本來(lái)可以完成 2 個(gè)項(xiàng)目，而且每個(gè)項(xiàng)目都可以讓網(wǎng)站快 40%。如果你不花點(diǎn)時(shí)間進(jìn)行初步測(cè)算的話，你永遠(yuǎn)都不知道還可以做一個(gè)更快的網(wǎng)站！

假設(shè)我們達(dá)成了時(shí)間估算非常重要這個(gè)共識(shí)，那么我們繼續(xù)看一下如何估算。通常情況下，我們低估所需時(shí)間是因?yàn)槲覀兿氲氖恰笇懗鲆粋€(gè)原型需要多長(zhǎng)時(shí)間？」。

但是，交付的東西往往要比原型大多了，你還需要考慮測(cè)試、調(diào)試、優(yōu)化所花費(fèi)的時(shí)間。還有開會(huì)、訪談、代碼評(píng)審，甚至發(fā)郵件都是需要花費(fèi)時(shí)間的。

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

基于此，我們最好不要太相信所謂的經(jīng)驗(yàn)和直覺。

在開始任何一個(gè)重要項(xiàng)目之前，你都應(yīng)該有一份技術(shù)計(jì)劃或者設(shè)計(jì)文檔。這個(gè)文檔的目的在于讓別人知道你在做的事情，并能獲得反饋。當(dāng)你注意到其中的技術(shù)細(xì)節(jié)時(shí)，你就會(huì)更清晰知道具體所耗費(fèi)的時(shí)間，比如把某個(gè)庫(kù)更新到新版本，可能會(huì)多花一天的時(shí)間。你甚至還得自己寫一個(gè)庫(kù)。

顆粒度在這里是很重要的。如果有哪一部分讓人覺得不清楚，要么是你應(yīng)該了解更多相關(guān)知識(shí)，要么得把它分解為更細(xì)致的步驟。與此同時(shí)，如果一個(gè)步驟太細(xì)的話，又可能會(huì)太脆弱導(dǎo)致整個(gè)計(jì)劃無(wú)效，所以要把握好這個(gè)度。

想要知道你的文檔里應(yīng)該考慮哪些東西，可以看看AliciaChen 的 這篇文章。關(guān)鍵在于跟 PM 溝通清楚，消除有歧義的地方，這樣才不會(huì)導(dǎo)致最后要推翻重來(lái)。

文檔里的每一步實(shí)現(xiàn)需要多少時(shí)間，這往往牽涉到對(duì)細(xì)節(jié)的研究（這個(gè)是不是已經(jīng)有庫(kù)了？）。因此視項(xiàng)目性質(zhì)而言，先做一個(gè)簡(jiǎn)單的原型可以幫助揭示許多潛在的痛點(diǎn)。

現(xiàn)在你已經(jīng)有了初步的時(shí)間估算，不過(guò)還有許多其他需要考慮的因素。

隨時(shí)調(diào)試：Bug 難以避免，這取決于開發(fā)者對(duì)特定代碼庫(kù)的經(jīng)驗(yàn)以及代碼庫(kù)的成熟度。會(huì)議和假期：開會(huì)或者放假時(shí)一般來(lái)說(shuō)是不會(huì)敲代碼的，所以真正敲代碼有多長(zhǎng)時(shí)間？因此時(shí)間估算時(shí)要好好看看日程表。最終測(cè)試：通常應(yīng)該一邊編碼一邊測(cè)試，但很多團(tuán)隊(duì)在發(fā)布前還需要做集成測(cè)試，因此在你的估算中留出這部分的時(shí)間。代碼評(píng)審：在這個(gè)代碼庫(kù)中你一般需要進(jìn)行幾輪？每輪需要多少時(shí)間？要經(jīng)過(guò)多少評(píng)審人？留意評(píng)審人的日程安排確保代碼評(píng)審的時(shí)間。

當(dāng)你把交付時(shí)間的開銷也考慮進(jìn)去，你就能看到自己的時(shí)間估算和項(xiàng)目的實(shí)際發(fā)布時(shí)間要匹配得多。盡管實(shí)際情況可能還會(huì)更長(zhǎng)，你也可能會(huì)因壓力而需要縮短工期。但當(dāng)大家明白你的估算更準(zhǔn)確時(shí)，也會(huì)更信任你。

復(fù)盤還挺痛苦的，但是回顧能讓你在下一次做得更好。每一個(gè)實(shí)際與預(yù)期時(shí)間不匹配的項(xiàng)目都發(fā)生了什么，找到原因并改進(jìn)它。

總而言之一切在于溝通。提前溝通、經(jīng)常溝通，了解彼此的日程和需求變更。

跟 PM 等相關(guān)參與者的溝通也能讓對(duì)方提供可能會(huì)影響你估算的重要信息。一位設(shè)計(jì)師可能會(huì)說(shuō)這個(gè)動(dòng)畫需要一周工期，干脆砍掉不要了。另一位 PM 也可能補(bǔ)充說(shuō)這個(gè)原型只是對(duì)用戶進(jìn)行研究的而已，這次迭代不用處理太多 bug。

對(duì)于工程師來(lái)說(shuō)，不要做不切實(shí)際的更短工期的妥協(xié)，開誠(chéng)布公更顯專業(yè)。對(duì)于 PM 和其他人來(lái)說(shuō)，尊重這一估算可能需要一個(gè)過(guò)程，但要知道光靠嘮叨是不可能縮短工期的。

項(xiàng)目時(shí)間估算不容易，唯有善于溝通、有同理心以及確定功能優(yōu)先級(jí)才可以。

到外企？為什么別的程序員那么容易

一招教你打造一個(gè)滑動(dòng)置頂?shù)囊曈X特效

NDK項(xiàng)目實(shí)戰(zhàn)—高仿360手機(jī)助手之卸載監(jiān)聽

（Android）面試題級(jí)答案（精選版）