假設有1000塊磚頭，它們的大小和重量一樣，每名工人每天能搬100塊磚頭，于是我們可以估算到需要10人日來搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天就搞定了。
這個1000塊代表了工作的規模，而生產率就是100塊/日，這樣就可以推算出工作量為10人日。建筑工程可以得到土石方量、混凝土量、鋼筋量等代表工作規模的數據，這樣就比較容易推算出完成這些工作需要的工作量。
功能點法和代碼行法有比較長的歷史，也有很多詳細資料，大家可以去查閱一下。這方法理論上很理想，但實踐效果很差，我還沒有見到一家能成熟應用并且取得比較好效果的公司。功能點法和代碼行法有這樣的一些難以解決的問題：
2、我們絕大部分項目是需求不明確、設計不明確，并且工期很趕的，這兩個方法都無法適應這樣的現實條件。需求不明確基本上無法得到軟件規模，建筑工程為什么能做到，是因為需求和設計都十分明確了。
普遍認為各專家的經驗與知識水平會嚴重影響結果的準確性，而我的實踐經驗是：應該讓項目組每個人自己來估算，也就是讓大家來當專家，在這個基礎上可以再增加一兩名來自項目組外部的專家。
有時候覺得估算這個問題搞得太復雜了，各式各樣的方法是不是太夸張了？其實最簡單的方法就是讓負責該項工作的人自己來估計工作量，微軟的由底而上的估算方法就是這樣做的，可謂返璞歸真啊！
微軟由底而上的估算方法大致是這樣的：對項目各項工作進行分解后（即俗稱的wbs：work breakdown structure，工作分解結構），每個任務落實負責人，由負責人對自己的任務進行估計。這個辦法有以下好處：
1、最終該任務是由這個人來完成的，他估計多少時間才能做完，這個時間才是最接近實際的。
2、負責該任務的人進行估算的時候，肯定需要認真思考這個任務的風險，需要做哪些具體的工作，這樣更容易在未開始工作之前就發現更多的潛在問題。相反如果由項目經理來分配時間，這個人就可能不會去思考這個任務了。
3、做這個任務的人會有被重視和尊重的感覺，他會很重視自己承諾的完成時間，并且想法設法按時間完成。這樣會減少很多項目管理時間，因為每個任務負責人都會主動地跟蹤好自己的工作。
其實微軟這個方法根本就沒有什么特別，所有正常人都可以想到這個方法，但仍然有很多人去追求那些不太靠譜的估算方法。
這個方法還是有這樣的一些問題的：
1、有人會估算偏小，比方他說需要5天，但往往10天還完不成。
2、有人估算過于保守。
3、項目的進度要求就是很緊，基本上你必須在指定時間內完成，估算顯得毫無價值。
第一個問題是比較常見的，但我們要這樣想：估不準也比不估算好，估算偏差哪怕超過100%，也比不估算好，至少有個譜。
大家是會進步的，估不準往往是對任務和自己能力認識不到位，要讓大家不害怕估算，只要敢于估算，問題才會暴露出來，才能持續進步。
第二個問題分兩種情況，有些人是確實是過分保守的對自己信心不太足，項目經理可以多多來指導他的工作，看看他具體的進展，讓他更加充分地了解任務，更加充分了解自己的能力，增強他的信心，這樣他就能持續進步了。而另外一種情況就比較惡劣，少數人會故意增大時間，這樣他平時工作不必全力以赴，可以比較悠閑，甚至可以利用工作時間干私事。如果發現這樣的情況，就應該嚴肅處理了，不要做爛好人，這樣的人在團隊中存在是對團隊的極大傷害。
第三個問題往往是各項目經理心中的痛楚，他們會覺得：實在無奈啊！做項目就是在有限時間有限資源內做不可能完成的任務，在這樣的情況下，你就不要跟我扯估算了！
我們的項目大部分情況都是非常大壓力的，應對這樣大的壓力越需要冷靜。實際上大部分項目盡管是有壓力，但只要發揮團隊的聰明才智，還是可以高效地做好工作的，不需要加班或者少加班。本文稍后會介紹這個問題的應對辦法。
介紹了這么多種估算方法，每種都有很多問題，那到底怎樣才能做好項目估算呢？
軟件項目的特點就是項目簽訂時，價錢是死的，工期是死的，而需求和設計是不明確的。
我的經驗告訴我，功能點法、代碼行法這些方法基本上是不靠譜的，我在實際項目中會綜合使用Dephi法和由底而上的估算方法，并予以改良，下面介紹一下我的一些心得體會。
1、項目估算與其說是估出來，還不如說是做出來的。
假設某項目是這樣的情況：
1）合同簽署的金額是100萬，工期是3個月。
2）需求只是大致寫了，并不明確。
3）老板要賺50萬，給你的預算只有50萬。
我們很多項目都是這樣的情況，不是等你估算出比較靠譜的數字，然后才去報價簽合同的，我們經常要在老板指定的預算下完成項目。
你現在要負責這個項目，你會如何做估算呢？
你需要做好兩個事情，才能保證項目實際成本控制在預算內。
第一個事情，控制好需求。需求不明確，這既是不利因素也是有利因素，應盡量往有利的方向控制。不明確的好處就是你有控制需求的空間，抓住客戶的關鍵需求，簡化不必要的花銷的需求，能極大地降低項目工作量。
第二個事情：想盡辦法降低開發工作量。不要因為進度緊就不認真思考軟件的設計，應盡量采用簡單的成熟的設計方案，簡化工作。
2、估算應該持續進行，持續細化。
項目初期很難對項目做完整估算，但能估計的部分應先估計出來，并且針對不明確的部分安排計劃去搞清楚。
3、估算是項目各種工作估算的總和。
估算并不是只是得到一個項目估算的總體數字，項目的估算總數其實是由項目各種工作的估算組成的。
前文介紹了項目的各種工作，每一種工作都需要認真估算。如果估算發生偏差，要能定位到具體是哪部分的估算出問題了，否則估算沒有指導項目工作的價值。功能點法、代碼行法的估算辦法，只能得到一個項目估算的總數，而不能定位到具體的哪一部分工作，這樣得到的估算結果難以用來指導項目工作。
4、估算依賴項目組的整體實力。
如果你沒有軟件開發相關經驗，只懂理論上的估算，你是不可能做好估算工作的。
項目組由項目管理、軟件設計、編碼、測試、實施等各類專業人才組成，每個人在自己方面都是專家，每個人都是整個項目組中最有資格對自己專業方面的工作進行估算。前文列出了的項目各方面的工作，應該由相應的項目成員為主進行估算。
5、項目組應該不斷學習、總結、進步，提高整體水平。
需求不明確、設計不確定這是項目的特點，我們需要不斷地學習來提高水平，將這些不明確的因素逐步明確。
沒有什么妙方能解決這些不明確的因素，靠的還是我們的知識和能力。項目組每個人都應該通過持續估算來發現自己的不足并提高水平。
6、公司應該定期組織項目資深人士制定估算指南并持續更新。
我們公司有一份估算模板，里面匯集了以前的估算經驗，列出了所有需要考慮的估算內容以及詳細的說明。
我們以前沒有估算模板時，估算偏差會達到50%以上，總結經驗發現偏差的主要原因是估漏！使用估算模板會幫助我們發現遺漏，后來我們的估算偏差基本可以控制在20%以內。
前文的“估算要估啥”小節，我列出了項目通常要考慮的各種工作，也列出了容易估漏和估計不足的地方，大家可在此基礎上根據自己公司實際情況，修改和擴充這些內容，寫出自己公司的估算模板或估算指南。
先得到項目規模，再由規模導出工作量，這是一個很美好的想法，問題就是和我們的實際情況相去甚遠了。
將工作分解，直到分解到可以估計工作量的程度，這個可能是最土最有效的方法了。但你可能會問，這樣的估算方法，項目之間就無法橫向比較了？
項目估算第一目標是用來指導項目工作，如果這個目標都達不到，那么就不需要考慮項目之間的橫向比較了。
另外我要反問：為什么非要用這樣的方式來作項目之間的橫向比較？有什么好處？國外優秀的軟件開發工作室就不會做這樣無聊的事情，軟件開發可能是人類最厲害的智力活動，你覺得一定能量化度量嗎？
要從本質上提升估算水平，你不太可能用幾天時間去突擊學習某種估算辦法就能勝任項目實際的估算工作。
提高估算能力靠你長期的積累，你的實力、你的項目團隊的綜合實力，還有你們公司的綜合實力，決定了估算的水平！
估算是為項目服務的，后文你會看到如何利用估算來管理項目，又如何因應項目實際情況來更新估算。
下面開始，我們將講述估算與計劃的關系、計劃及計劃跟蹤。 計劃有什么內容？