微軟由底而上的估算方法大致是這樣的：對項目各項工作進行分解后（即俗稱的wbs：work breakdown structure，工作分解結(jié)構(gòu)），每個任務落實負責人，由負責人對自己的任務進行估計。這個辦法有以下好處：

1.  終該任務是由這個人來完成的，他估計多少時間才能做完，這個時間才是接近實際的。

2.  負責該任務的人進行估算的時候，肯定需要認真思考這個任務的風險，需要做哪些具體的工作，這樣更容易在未開始工作之前發(fā)現(xiàn)更多的潛在問題。相反如果由項目經(jīng)理來分配時間，這個人可能不會去思考這個任務了。

3.  做這個任務的人會有被重視和尊重的感覺，他會很重視自己承諾的完成時間，并且想法設法按時間完成。這樣會減少很多項目管理時間，因為每個任務負責人都會主動地跟蹤好自己的工作。

其實微軟這個方法根本沒有什么特別，所有正常人都可以想到這個方法，但仍然有很多人去追求那些不太靠譜的估算方法。

這個方法還是有這樣的一些問題的：

1.有人會估算偏小，比方他說需要5天，但往往10天還完不成。

2.有人估算過于保守。

3.項目的進度要求是很緊，基本上你必須在指定時間內(nèi)完成，估算顯得毫無價值。

第一個問題是比較常見的，但我們要這樣想：估不準也比不估算好，估算偏差哪怕超過，也比不估算好，至少有個譜。

大家是會進步的，估不準往往是對任務和自己能力認識不到位，要讓大家不害怕估算，只要敢于估算，問題才會暴露出來，才能持續(xù)進步。

第二個問題分兩種情況，有些人是確實是過分保守的對自己信心不太足，項目經(jīng)理可以多多來指導他的工作，看看他具體的進展，讓他更加充分地了解任務，更加充分了解自己的能力，增強他的信心，這樣他能持續(xù)進步了。而另外一種情況比較惡劣，少數(shù)人會故意增大時間，這樣他平時工作不必全力以赴，可以比較悠閑，甚至可以利用工作時間干私事。如果發(fā)現(xiàn)這樣的情況，應該嚴肅處理了，不要做爛好人，這樣的人在團隊中存在是對團隊的極大傷害。

第三個問題往往是各項目經(jīng)理心中的痛楚，他們會覺得：實在無奈��！做項目是在有間有限資源內(nèi)做不可能完成的任務，在這樣的情況下，你不要跟我扯估算了！

我們的項目大部分情況都是非常大壓力的，應對這樣大的壓力越需要冷靜。實際上大部分項目盡管是有壓力，但只要發(fā)揮團隊的聰明才智，還是可以高效地做好工作的，不需要加班或者少加班。本文稍后會介紹這個問題的應對辦法。

介紹了這么多種估算方法，每種都有很多問題，那到底怎樣才能做好項目估算呢？

軟件項目的特點是項目簽訂時，價錢是死的，工期是死的，而需求和設計是不明確的。

我的經(jīng)驗告訴我，功能點法、代碼行法這些方法基本上是不靠譜的，我在實際項目中會綜合使用Dephi法和由底而上的估算方法，并予以改良，下面介紹一下我的一些心得體會。

1.項目估算與其說是估出來，還不如說是做出來的。

假設某項目是這樣的情況：

1）合同簽署的金額是100萬，工期是3個月。

2）需求只是大致寫了，并不明確。

3）老板要賺50萬，給你的預算只有50萬。

我們很多項目都是這樣的情況，不是等你估算出比較靠譜的數(shù)字，然后才去報價簽合同的，我們經(jīng)常要在老板指定的預算下完成項目。

你現(xiàn)在要負責這個項目，你會如何做估算呢？

你需要做好兩個事情，才能保證項目實際成本控制在預算內(nèi)。

第一個事情，控制好需求。需求不明確，這既是不利因素也是有利因素，應盡量往有利的方向控制。不明確的好處是你有控制需求的空間，抓住客戶的關鍵需求，簡化不必要的花銷的需求，能極大地降低項目工作量。

第二個事情：想盡辦法降低開發(fā)工作量。不要因為進度緊不認真思考軟件的設計，應盡量采用簡單的成熟的設計方案，簡化工作。

2.估算應該持續(xù)進行，持續(xù)細化。

項目初期很難對項目做完整估算，但能估計的部分應先估計出來，并且針對不明確的部分安排計劃去搞清楚。

3.估算是項目各種工作估算的總和。

估算并不是只是得到一個項目估算的總體數(shù)字，項目的估算總數(shù)其實是由項目各種工作的估算組成的。

前文介紹了項目的各種工作，每一種工作都需要認真估算。如果估算發(fā)生偏差，要能定位到具體是哪部分的估算出問題了，否則估算沒有指導項目工作的價值。功能點法、代碼行法的估算辦法，只能得到一個項目估算的總數(shù)，而不能定位到具體的哪一部分工作，這樣得到的估算結(jié)果難以用來指導項目工作。

4.估算依賴項目組的整體實力。

如果你沒有軟件開發(fā)相關經(jīng)驗，只懂理論上的估算，你是不可能做好估算工作的。

項目組由項目管理、軟件設計、編碼、測試、實施等各類專業(yè)人才組成，每個人在自己方面都是專家，每個人都是整個項目組中有資格對自己專業(yè)方面的工作進行估算。前文列出了的項目各方面的工作，應該由相應的項目成員為主進行估算。

5.項目組應該不斷學習、總結(jié)、進步，提高整體水平。

需求不明確、設計不確定這是項目的特點，我們需要不斷地學習來提高水平，將這些不明確的因素逐步明確。

沒有什么妙方能解決這些不明確的因素，靠的還是我們的知識和能力。項目組每個人都應該通過持續(xù)估算來發(fā)現(xiàn)自己的不足并提高水平。

6.公司應該定期組織項目人士制定估算指南并持續(xù)更新。

我們公司有一份估算模板，里面匯集了以前的估算經(jīng)驗，列出了所有需要考慮的估算內(nèi)容以及詳細的說明。

我們以前沒有估算模板時，估算偏差會達到50%以上，總結(jié)經(jīng)驗發(fā)現(xiàn)偏差的主要原因是估漏！使用估算模板會幫助我們發(fā)現(xiàn)遺漏，后來我們的估算偏差基本可以控制在20%以內(nèi)。

前文的“估算要估啥”小節(jié)，我列出了項目通常要考慮的各種工作，也列出了容易估漏和估計不足的地方，大家可在此基礎上根據(jù)自己公司實際情況，修改和擴充這些內(nèi)容，寫出自己公司的估算模板或估算指南。

先得到項目規(guī)模，再由規(guī)模導出工作量，這是一個很美好的想法，問題是和我們的實際情況相去甚遠了。

將工作分解，直到分解到可以估計工作量的程度，這個可能是土有效的方法了。但你可能會問，這樣的估算方法，項目之間無法橫向比較了？

項目估算第一目標是用來指導項目工作，如果這個目標都達不到，那么不需要考慮項目之間的橫向比較了。

另外我要反問：為什么非要用這樣的方式來作項目之間的橫向比較？有什么好處？國外的軟件開發(fā)工作室不會做這樣無聊的事情，軟件開發(fā)可能是人類厲害的智力活動，你覺得一定能量化度量嗎？