我的一個產(chǎn)品經(jīng)理朋友，最近和我說她遇到的一個問題：『軟件工程師們總是，無法準(zhǔn)確的估算項目所需的時間，我該怎么辦？』，還有兩個CEO最近也和我說過同樣的問題。

我們的工程師都見證了這一點(diǎn)。我曾經(jīng)看到過一個項目，估算時間是兩天，到最后用了四個月的時間做完。在這種情況下，即使花雙倍的估算數(shù)據(jù)，依然和實際的時間不在一個數(shù)量級上，這可是會對公司業(yè)務(wù)產(chǎn)生很大影響的。

在一個較高的層面上講，問題其實工程師和，產(chǎn)品經(jīng)理、項目經(jīng)理對應(yīng)項目時間估算的理解是不同的。大部分工程師本能的去設(shè)想是，如果按照計劃最好的情況下做出原型的最小工作時間，而產(chǎn)品經(jīng)理們想要的估算時間是項目能夠發(fā)布的時間點(diǎn)，這是兩個完全不一樣的概念。

對應(yīng)工程師來說，掌握項目時間估算是一項長期的，貫穿你整個這樣生涯的旅程，忽略項目時間估算，將會給你自己和與你一起工作的人帶來很大意想不到的麻煩。掌握時間估計會讓你脫穎而出，你的同事會將你作為專家看待。

我們?yōu)槭裁葱枰浪銜r間

讓我來先回答這個問題，我經(jīng)常聽到工程師們說『有什么好擔(dān)心的』很大工程師抱怨說，如果我一開始就全力投入開發(fā)，就可以很快的完成工作，何必要花時間在這在估算時間上面呢。

這里有兩個主要的原因：外部依賴和優(yōu)先級

外部依賴

『沒有項目是在真空中運(yùn)作的』，意思就是項目總會設(shè)計到與其他非開發(fā)部門或者其他的開發(fā)部門進(jìn)行協(xié)調(diào)工作的。這也是項目經(jīng)理和產(chǎn)品經(jīng)理的主要工作。這意味著，最應(yīng)該估算時間的人，不是最需要估算時間的人。這種不對稱性導(dǎo)致了兩者之間，先天就有所沖突。

優(yōu)先級

時間估算同樣是工作優(yōu)先級的關(guān)鍵，功能開發(fā)的收益如果沒有時間估算的話是很難保證的。即使你在開發(fā)的功能是非常酷炫的任務(wù)，如果你花時間做完整的估算的話，你也許會意識到這個功能需要花費(fèi)很長的時間才能完成。

譬如說你在做功能，它可以讓網(wǎng)站的速度快上50%，但是同樣的時間下，你也可以做兩個其他的功能，它們分別可以讓網(wǎng)站快40%，如果你不在開工前對工作進(jìn)行時間估算你就不知道，可以在相同的時間內(nèi)讓網(wǎng)站變得更快。

時間估算101

現(xiàn)在我們都知道了時間估算是非常有必要的，那么我們就來看一下幾個技巧。

我們總是低估時間，這是因為，我們想的是：多久可以做出一個基本可用的版本。但是你的工作可不僅僅是寫出一個可用的版本，你還需要估算你在，編寫測試、調(diào)試、還有改進(jìn)，這還沒有包括你需要參加會議討論，做code review、郵件溝通這些時間。

另外一個原因就是我們總是在開發(fā)期間遇到一些意想不到的情況，并且這些情況幾乎不可能被預(yù)先計算在時間計劃當(dāng)中，就比如你的開發(fā)環(huán)境或者是IDE需要更新，正好弄壞了你的項目，你還需要花上一天的時間去修復(fù)這些問題，這根本就不可能在預(yù)先包括在時間估算到中。

當(dāng)然了，盡管有很多的不確定性，我們依然可以盡最大的可能讓項目時間的估算盡可能的靠譜。

第一步：制定技術(shù)計劃

你應(yīng)該已經(jīng)在項目開始的時間，制定了技術(shù)計劃或者已經(jīng)通過繪圖工具設(shè)計的項目的系統(tǒng)結(jié)構(gòu)，這些可以讓此相關(guān)的同事，了解的你的工作并且可以獲得反饋，技術(shù)計劃是一個作為開始估算時間，非常理想的地方。在你計劃項目的具體實現(xiàn)使用哪些技術(shù)的時候，你就會看到有哪些是不可預(yù)知的情況，有哪些技術(shù)，是你還沒有掌握的需要花時間去學(xué)習(xí)，還有哪些第三方庫的輪子沒有人造，需要你自己去寫。這都是在是技術(shù)計劃的時候去考慮，加入到時間估算當(dāng)中去的。

步驟分解的粒度，是非常重要的，如果你覺得在某一步驟上的功能，實現(xiàn)起來有些困難的話，要么就將步驟再次分解，或者跳過這個部分。同時你還有注意不要將步驟分解的太細(xì)了，不然的話整個計劃執(zhí)行起來就沒有可操作性了。

第二步：在每一步驟中添加時間估算

在技術(shù)計劃中的每一項實現(xiàn)起來，需要花費(fèi)的時間都是需要進(jìn)行估算的，通常包括一些技術(shù)實現(xiàn)上的細(xì)節(jié)問題（是否存在第三方庫可以用），可以通過制作一個原型去發(fā)現(xiàn)未來潛在可能出現(xiàn)的技術(shù)難度。

第三步：加入一些額外的時間

現(xiàn)在你已經(jīng)對時間估算有了初步的了解。下面是我們在之前提到的關(guān)于估算時間需要注意的地方。

調(diào)試：bug 總是有的，至于會有多少，這就取決于你對項目的了解和項目本身的成熟度了。

會議、面試、假期等：你不可能無時無刻都在編程，所以估算時間的時候也要考慮上你自己個人的時間計劃。

測試：通常情況向項目的開發(fā)都是需要伴隨著測試進(jìn)行的，為項目的最后階段的測試預(yù)留一下時間，當(dāng)然同時也需要為你在最后階段被測試出來的bug預(yù)估時間。

Code Review：通常需要花多長的時間再code review上？，項目會有多少人參與code review，這些時間你都要去添加到估算當(dāng)中去。

一旦你開始，使用上面的跪著到你的估算當(dāng)中，就會發(fā)現(xiàn)你估算的時間和項目最后的交付日期越來越接近了。當(dāng)然這些是需要長時間積累的，你可能在執(zhí)行期間感到有壓力，不過只要過了瓶頸期，你就會發(fā)現(xiàn)你的團(tuán)體會非常依賴你對項目的時間把控的能力。

第四步：在發(fā)布后回顧你的估計

是的，這個計劃是在你的項目完成開發(fā)的時候，回顧整個項目的時間估算，看看在這次項目開發(fā)的估算當(dāng)中有什么可以在下一次中做的更好的。

你一定會看到你時間估算會隨著時間的推移越來越準(zhǔn)確。你甚至可能會產(chǎn)生一些對時間估算的自己的見解。

溝通

盡早的暴露問題和積極的溝通反饋，是非常重要的，如果你在項目上線前一個月就告訴項目經(jīng)理，『我們使用的第三方庫（或者服務(wù)）出現(xiàn)了安全問題，現(xiàn)在需要重新實現(xiàn)部分的功能』而不是到最后項目要發(fā)布了才說，那么他就有時間去讓相關(guān)的同事進(jìn)行準(zhǔn)備。

積極的與有關(guān)同事進(jìn)行溝通，還能從他們那得到可能影響你項目時間估算的重要信息。比如設(shè)計師可能說『如果動畫效果的實現(xiàn)，需要一個星期的話，那我們就砍掉它算了』，或者產(chǎn)品經(jīng)理會說『我們現(xiàn)在做的只是一個產(chǎn)品的原型，用于實驗，沒有必要在這次迭代中，做到完美』。對于工程師來說，不要迫于上級的壓力，去縮短你估算的時間，坦誠的說出你真實估算的時間，并且讓他們有準(zhǔn)備，這才是更專業(yè)的做法。

我們永遠(yuǎn)也不可能完美無誤的項目時間估算，我們唯一能做到的就是，開誠布公的交流，并且嚴(yán)格按照優(yōu)先級計劃開展工作。