估算如何做出來？

　　這裏開始所説的估算，全部都是指項目組對項目的估算，這個估算的目的是用來指導項目的具體工作。

　　有很多種估算辦法，大致可以分為兩類：

　　1、先得到軟件規模，然後根據公司實際的生產率由軟件規模導出工作量。

　　2、直接得到工作量。

　　第一類的常見方法有：功能點法、代碼行法，第二類的常見方法有Delphi估算法、微軟的由底而上估算法。

　　什麼是軟件規模？我們先看看一個搬磚頭的估算。

　　假設有1000塊磚頭，它們的大小和重量一樣，每名工人每天能搬100塊磚頭，於是我們可以估算到需要10人日來搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天就搞定了。

　　這個1000塊代表了工作的規模，而生產率就是100塊/日，這樣就可以推算出工作量為10人日。建築工程可以得到土石方量、混凝土量、鋼筋量等代表工作規模的數據，這樣就比較容易推算出完成這些工作需要的工作量。

　　而軟件工程估算也希望能做到類似的效果，但用什麼來代表軟件項目的工作規模呢？功能點和代碼行是常見的兩種軟件規模表示方式。

　　軟件規模是與軟件具體生產技術、項目管理辦法、項目組人員水平等無關的東西，軟件規模只和軟件項目本身的性質相關，如果我們能找到合適的統一的標準來度量每個項目的規模，這樣每個軟件項目之間就可以進行橫向比較了。功能點法和代碼行法都希望能達致這樣的效果。

　　功能點法的基本思路是將複雜的軟件分解為一個一個獨立的粒度一致的功能點，附加一些調整係數，得到軟件規模。

　　我們的項目大部分是數據庫四輪馬車的操作（查詢、增加、修改、刪除），功能點法從比較高的層次對這些工作進行抽象，有一套嚴密的規則可以讓你將需求分解成一個一個的功能點。代碼行法思路也類似，不過分解的結果是代碼行而已。但一般來説代碼行與軟件的實現技術相關度太大，大家會更加偏愛功能點法。

　　功能點法和代碼行法有比較長的歷史，也有很多詳細資料，大家可以去查閲一下。這方法理論上很理想，但實踐效果很差，我還沒有見到一家能成熟應用並且取得比較好效果的公司。功能點法和代碼行法有這樣的一些難以解決的問題：

　　1、只適用於數據庫四輪馬車的操作的項目，高技術含量、創造性高的軟件不適用，如遊戲軟件、計算機負責計算與決策軟件等。

　　2、我們絕大部分項目是需求不明確、設計不明確，並且工期很趕的，這兩個方法都無法適應這樣的現實條件。需求不明確基本上無法得到軟件規模，建築工程為什麼能做到，是因為需求和設計都十分明確了。

　　3、兩個方法的規則都很詳細，要花大量時間學習和實戰才能掌握。

　　4、由工作規模導出工作量這樣的思考方式，難以適用於軟件項目。項目組還是習慣列出具體的任務，逐條任務估計時間，而且只有這樣的工作方式才能讓項目組感覺更加踏實。

　　Dephi估算法是比較符合大家實際工作習慣，也是比較容易掌握的估算辦法。

　　Delphi法的大致方法如下：

　　1、找幾名資深專家，一起對項目進行WBS，把項目的工作分解為十幾條最多二三十條的工作項。

　　2、全部專家各自估計每條工作項的工作量，並向其他專家闡述自己的理由。

　　3、第一次各專家估出來的結果可能差異比較大，每位專家聽取別人的意見後，重新估算。

　　4、按照上述辦法，各專家反覆估算幾次，一般次數就是2-4次，各專家估計的工作量會越來越趨近，這個時候取全部專家的平均值。

　　普遍認為各專家的經驗與知識水平會嚴重影響結果的準確性，而我的實踐經驗是：應該讓項目組每個人自己來估算，也就是讓大家來當專家，在這個基礎上可以再增加一兩名來自項目組外部的專家。

　　有時候覺得估算這個問題搞得太複雜了，各式各樣的方法是不是太誇張了？其實最簡單的方法就是讓負責該項工作的人自己來估計工作量，微軟的由底而上的估算方法就是這樣做的，可謂返璞歸真啊！

微軟由底而上的估算方法大致是這樣的：對項目各項工作進行分解後（即俗稱的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%以內。

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

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

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

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

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

　　要從本質上提升估算水平，你不太可能用幾天時間去突擊學習某種估算辦法就能勝任項目實際的估算工作。

　　提高估算能力靠你長期的積累，你的實力、你的項目團隊的綜合實力，還有你們公司的綜合實力，決定了估算的水平！

　　估算是為項目服務的，後文你會看到如何利用估算來管理項目，又如何因應項目實際情況來更新估算。

　　下面開始，我們將講述估算與計劃的關係、計劃及計劃跟蹤。　計劃有什麼內容？

　　關於項目計劃，我們要先討論什麼是正確的事情，然後再討論如何做正確的事情，我們先來看看項目計劃應該有什麼內容？

　　讓大家做項目計劃，很多人以為用Project做一份開發進度計劃就完事了。而項目的開發工作只是佔了項目工作的其中一部分而已，跟項目所有相關的工作，我們都需要計劃。諸如開發計劃、測試計劃、培訓計劃、溝通計劃、採購計劃等等，這些計劃的集合，我們稱之為項目計劃。

　　項目計劃應該包含以下內容：

　　1、項目背景、目標、概述等。

　　2、項目需要提交的工作產品，包括內部工作產品和最終工作產品。

　　3、風險分析及應對措施。

　　4、項目估算。

　　5、項目在成本、進度、質量方面的管理目標。

　　6、項目人員職責。

　　7、對項目各項工作的安排，包括但不限於前文介紹的11種工作，如下：

　　　　1）項目前期工作 2）商務方面的工作 3）需求調研方面的工作 4）軟件設計方面的工作 5）編碼方面的工作 6）測試方面的工作 7）實施方面的工作 8）維護方面的工作 9）項目管理方面的工作 10）配置管理方面的工作 11）質量保證方面的工作

　　8、需客户或第三方協調的工作計劃。

　　9、採購計劃。

　　10、項目所需的各種硬件資源，包括開發環境、運行環境、測試環境等。

　　一般來説項目計劃有一個主計劃，多個子計劃。主計劃總體描述項目的背景、管理目標、任務概述等總體信息，而子計劃則有測試計劃、實施計劃、培訓計劃、配置管理計劃等。

　　下圖是主計劃目錄示例：

下面是進度計劃示例：

　　該進度計劃按版本來組織任務，而每個版本則按照項目管理、需求、設計、開發、測試、發佈、實施來組織任務。

　　也會有些公司會將所有計劃集成一個大計劃，計劃的組織和表達方式並沒有固定方式，上述示例圖也只是僅供參考。

　　上面講了很多項目計劃的內容，其實我們只是需要想清楚為什麼要做計劃，你就會知道項目計劃應該有什麼內容。

　　項目計劃的幾個重要目的：

　　1、明確項目人員、各人職責。（當然這可能會在立項通知書中明確。）

　　2、明確完成項目所需要的各種資源。

　　3、確定項目在成本、進度、質量方面的管理目標。

　　4、明確項目的各種工作產品。

　　5、落實各項工作安排，保證項目成功。