項目中成本評估中，最大的比例是進度評估，經常遇到我們的評估不準確，做了根本原因分析後如下圖：
由上圖我們得出，
佔有大比例及優先級的原因如下：
1、 需求範圍管理
2、 評估技能—而實際中這點並不是主要原因，評估者的多半經驗都可滿足評估標準
3、 風險儲備
4、 管理儲備
但並不是滿足以上就讓我們有個漂亮準確度高的成本評估指標，IT公司中，除了軟件外包，很多公司忽略甲方，認爲只有第三方纔是甲方，如果一個運營類的公司，那麼他的甲方實際上是這個公司的管理層，boss。
那麼我們在每個項目中其實都遵循着軟件外包的一個思路，就是我們需要兩套“賬本”，一套給“甲方”，一套給自己。也可以理解爲一套爲實際成本估算，另一套爲預算（跟甲方報的價格）。
預算的組成流程：
實際的預算制定過程中，也會根據企業類型、客戶類型、項目類型的不同，以上節點未必需要全部具備。
我們自己的實際成本評估往往不可能非常準確，當我們把這套“賬本”報給“甲方”時，必然出現延誤，需求範圍擴展等問題。
總結對內對外的必要估算組成部分，應按一定百分比進行評估。
|
|
調研 |
設計 |
開發 |
測試 |
管理 |
風險 |
配置 |
實施 |
其他 |
|
對外 |
√ |
√ |
√ |
√ |
√ |
√ |
√ |
√ |
忽略 |
|
對內 |
√ |
√ |
√ |
√ |
-- |
-- |
-- |
-- |
忽略 |
對日對國內的項目也不一樣，但整體看都會是兩套賬本，並且根據企業級別（如能力成熟模型的級別）不同，對外部進行估算的標準也不同，即甲方能接受的評估依據不同，主要分爲功能點估算和代碼行估算。功能點估算用的方法多爲類比，找具有資深開發經驗和管理經驗的人進行歷史項目類比的方式進行估算，代碼行估算的方式很多，多數採用自下而上的估算方式。
軟件項目評估分兩種類型，7鍾場景。總結一下，國內項目基本都用的是功能點估算，按公司規模項目類型不同，選擇不同的估算場景，能力成熟度比較高的公司，尤其在做對日項目的時候，用代碼行估算的情況比較多，第一是因爲甲方有需求，並且甲方有能力評估你估算的代碼行對方是否接受，第二是這種估算需要在組織過程資產沉澱到一定基礎上，有很多切合公司實際情況的參數時，纔可以估算的準確。比如沉澱了公司的個人生產率，成本基準，功能點權重係數等等。
隨着項目進展，評估會越來越準確，所以合同前的估算很粗，故要考慮的問題很多。
有些公司還會規定，將間接成本（需要進行項目和部門分攤的成本）納入到項目成本中來。
下面我們開始說實際場景，之前看到篇文章總結的非常好，也符合實際，故這裏不在贅述，做如下分享：
場景一：合同前的工作量估算
場景描述：
（1）沒有實施過CMMI2級
（2）合同未籤，需要給客戶報價
（3）有客戶的概要需求，有類似的項目數據可供參考
（4）需要估計整個項目的總工作量，以便於估算總成本，給客戶報價
估算步驟：
（1）尋找類似的歷史項目，進行項目的類比分析，根據歷史項目的工作量憑經驗估計本項目的總工作量；
（2）進行WBS分解，力所能及地將整個項目的任務進行分解；
（3）參考類似項目的數據，採用經驗法估計WBS中每類活動的工作量；
（4）彙總得到項目的總工作量；
（5）與第（1）步的結果進行印證分析，根據分析結果，確定估計結果。
場景二：基於詳細需求的經驗估計
場景描述：
（1）只有詳細需求，沒有歷史數據
估算步驟：
（1）WBS分解，將任務分解到一個人或者一個小團隊可以執行的顆粒度；WBS分解時要識別出所有的交付物、項目管理活動、工程活動等。
（2）採用經驗法估計每個活動的工作量；
（3）彙總得到：每個階段的工作量、項目的總工作量。
其他說明：
在該場景下，只使用了經驗法，無法對結果進行印證，難以判斷結果的合理性。
、
場景三：由編碼估算整體
場景描述：
（1）有類似項目的歷史數據
（2）有編碼活動的生產率數據
（3）有詳細需求
（4）實施了CMMI2級，但是沒有積累歷史項目的工作量分佈數據
估算步驟：
（1）產品分解，將系統分爲子系統，子系統分解爲模塊；
（2）WBS分解，將任務分解到一個人或者一個小團隊可以執行的顆粒度；WBS分解時要識別出所有的交付物、項目管理活動、工程活動等。
（3）建立WBS分解中的活動與產品元素的映射關係，識別出WBS中哪些活動可以採用模型法估算；
（4）估計產品元素的規模，可以採用代碼行法或功能點法，並估計每個產品元素的複雜度、複用率等；
（5）根據歷史的編碼階段的生產率數據和產品元素的規模估計、複雜度、複用率等採用模型法計算每個產品元素的編碼工作量；
（6）根據歷史的類似項目的數據及估算人的經驗估計其他活動的工作量，可以採用經驗法。
（7）彙總得到：每個階段的工作量、項目的總工作量。
其他說明：
在該場景下，混合使用了經驗法與模型法，這2種方法互相補充，而不是互相印證。
場景四：由總體印證基於WBS的估計
場景描述：
（1）有類似項目的歷史數據
(2) 有類似項目的全生命週期的生產率數據（含管理工作量）
（3）有詳細需求
（4）實施了CMMI2級，但是沒有積累歷史項目的工作量分佈數據
估算步驟：
（1）產品分解，將系統分爲子系統，子系統分解爲模塊；
（2）估計產品元素的規模，可以採用代碼行法或功能點法；
（3）累計出整個產品的總規模，並估計產品總體的複雜度、複用率等；
（4）根據類似項目的全生命週期的生產率數據和產品的總規模、複雜度、複用率等採用模型法計算總的開發工作量；
（5）WBS分解，將任務分解到一個人或者一個小團隊可以執行的顆粒度；WBS分解時要識別出所有的交付物、項目管理活動、工程活動等。
（6）根據歷史的類似項目的數據及估算人的經驗估計所有活動的工作量，可以採用經驗法。
（7）彙總得到：每個階段的工作量、項目的總工作量。
（8）與第（4）步得出的工作量進行比較印證，如果偏差不大，則以第（7）步的結果爲準，如果偏差比較大，要仔細分析原
場景五：三維印證基於WBS的估計
場景描述：
（1）有類似項目的歷史數據
(2) 有類似項目的全生命週期的生產率數據（含管理工作量）
（3）有詳細需求
（4）實施了CMMI3級，有歷史項目的工作量分佈數據（階段分佈、工種分佈）
估算步驟：
（1）產品分解，將系統分爲子系統，子系統分解爲模塊；
（2）估計產品元素的規模，可以採用代碼行法或功能點法；
（3）累計出整個產品的總規模，並估計產品總體的複雜度、複用率等；
（4）根據類似項目的全生命週期的生產率數據和產品的總規模、複雜度、複用率等採用模型法計算總的開發工作量；
（5）根據歷史項目的工作量分佈數據及第（4）步估算的項目總工作量
（6）WBS分解，將任務分解到一個人或者一個小團隊可以執行的顆粒度；WBS分解時要識別出所有的交付物、項目管理活動、工程活動等。
（7）根據歷史的類似項目的數據及估算人的經驗估計所有活動的工作量，可以採用經驗法。
（8）彙總得到：每個階段的工作量、每個工種的工作量、項目的總工作量。
（9）與第（4）、（5）步得出的工作量進行比較印證，如果偏差不大，則以第（7）步的結果爲準，如果偏差比較大，要仔細分析原因，可能的原因舉例如下：
類似項目的生產率數據不適合本項目；
WBS分解的顆粒度不夠詳細；
估算專家的經驗不適合本項目；
具體任務的估計不合理；
場景六：四維印證基於WBS的估計
場景描述：
（1）有類似項目的歷史數據
(2) 有類似項目的編碼活動的生產率數據（不含管理工作量）
（3）有詳細需求
（4）實施了CMMI3級，有歷史項目的工作量分佈數據（階段分佈、工種分佈、階段工種分佈）
（5）項目採用了瀑布模型
估算步驟：
（1）產品分解，將系統分爲子系統，子系統分解爲模塊；
（2）估計產品元素的規模，可以採用代碼行法或功能點法，並估計每個產品元素的複雜度、複用率等；
（3）根據類似項目的編碼活動的生產率數據和產品元素的規模、複雜度、複用率等採用模型法計算每個產品元素的編碼工作量；
（4）根據歷史項目的按工種的工作量分佈數據及第（3）步的估算的編碼工作量依次計算：
i)根據歷史項目的編碼的工作量佔編碼階段的工作量的百分比與第（3）部計算出的編碼工作量計算編碼階段的總工作量；
ii)根據歷史項目的編碼階段各工種的工作量分佈百分比計算編碼階段每個工種的工作量；
iii)根據歷史項目的其他階段的工作量與編碼階段的工作量比例計算其他階段的總工作量；
iv)根據歷史項目的其他階段的每個工種的工作量分佈百分比及第iii)步的結果計算其他階段的每個工種的工作量；
（5）WBS分解，將任務分解到一個人或者一個小團隊可以執行的顆粒度；WBS分解時要識別出所有的交付物、項目管理活動、工程活動等。
（6）根據歷史的類似項目的數據及估算人的經驗估計所有活動的工作量，可以採用經驗法。
（7）彙總得到：每個階段每個工種的工作量、每個階段的工作量、每個工種的工作量、項目的總工作量。
（8）與第（4）步得出的工作量進行比較印證，如果偏差不大，則以第（6）步的結果爲準，如果偏差比較大，要仔細分析原因，可能的原因舉例如下：
類似項目的生產率數據不適合本項目；
WBS分解的顆粒度不夠詳細；
估算專家的經驗不適合本項目；
具體任務的估計不合理；
場景七：需求變更的工作量估計
場景描述：
（1）有變更的需求描述
（2）項目進行到了編碼階段
（3）有本項目的編碼的生產率
估算步驟：
（1）進行需求變更的波及範圍分析
（2）進行本次變更的的WBS分解
（3）對於變更引起的代碼變化進行規模、複雜度等其他屬性的估計
（4）根據本項目的編碼的生產率及估計的規模採用模型法估計工作量
（5）對於WBS分解中其他活動進行經驗估計
（6）彙總所有的工作量得到本次變更的工作量估計
以上的七種場景，在進行代碼行估算的時候，一定要注意幾點：
1、 組織過程資產是否有管理層認可的數據；比如功能點技術權重係數，比如模塊代碼複用率百分比，這些都歸屬於沉澱的參數估算。所以一般我們會將類比和參數估算結合。進行代碼行估算時以上尤爲重要，但功能點估算時也可進行統計，但多半更依賴於經驗。
2、 對估算者的能力要求比較高；
3、 客戶方認可代碼行估算的能力；
4、 做好客戶詢問：XXX打印界面爲什麼估算了350行代碼的回答。
尤其在生產製造業，行業規則固定，業務需求明確，一個做解決方案提供和實施顧問的企業，可以根據自身產品的沉澱，技術框架的沉澱，準確估算出一個功能點的代碼行數
比如我們有統一的工具類程序包，統一的基本邏輯處理程序包。一個提交按鈕的假設代碼行產生是10行，一個文本框產生的代碼量是10行，那麼每調用一次check，衍生代碼是可能也是10行，而這10行有複用率的標準。比如整個系統中凡是涉及到編號的文本框都複用。
我們可以發現，多半估算準確度高的都是瀑布式模型，而敏捷開發方法不利於項目估算，因爲有很多工作流交疊，捨棄的雛形模塊的刪減，無法正確的計算出損失，並且過多的依賴於團隊能力，個人素質，資產沒有沉澱在數據、文本上，這恐怕也是多數互聯網公司做敏捷宣傳時很少提及到底節約了多少成本的原因。