軟件項目之預算評估三把刀

一、使用完善的評估方法的重要性。

一般情況下，軟件項目會受到四種因素的控制，它們分別是時間、需求、資源（包括人員、硬件條件以及資金）和風險。這些因素的任何意料之外的變化都會對我們的項目產生影響。因此，做好時間和項目資源需求的評估是非常必要的。如果過低估計項目預算，會由于缺乏項目實施時間、資金、硬件條件或是沒有足夠的人來完成等原因導致非常嚴重的后果。但如果過高地估計項目需求預算，也會因為成本太高使企業付出很大的代價，最后這個項目可能會被擱淺，就算項目被批準實施，也會由于此項目占用大量的資源而使其它的項目由于得不到足夠的資源來呈現“饑餓”狀態。

從我的經驗來看，對一個項目做時間和所需資源的預算評估通常對于大多數團隊和項目經理是一個非常大的挑戰。形成挑戰的原因有很多，如它們對預算評估沒有足夠的經驗、對評估技術或所涉及的商業領域缺乏了解，需求不清楚等。盡管負責項目預算評估的經理已經嘗試了使用最好的方法來處理需求及各方的關系問題，但由于以上的原因，不可避免地導至整個團隊由于評估失誤而超過預算，或是項目失敗。還有另外一種評估預算的方法，就是使用高度樂觀的方法進行評估，而忽略我們需要處理的具體項目。那么我們到底該怎么做呢？

二、實用的預算評估技術。

在我們開始研究預算評估之前，需要對我們能提供的預算評估類型有一個初步的認識。預算評估可以被簡單地分為下面三種類型：

1、宏觀預算評估：這種評估方式將根據項目的宏觀輪廓進行一個總體的估計。這種估計是非常粗略的。在理想狀態下，所評估出來的值應該是實際值的兩倍至三倍。

2、粗略預算評估：用這種評估方式評估出來的數據已經非常接近實際值了。在理想狀態下，評估出來的值應該是實際值的50%至100%。

3、精確預算評估：這是一種非常好的預算評估主要。在理想狀態下，所評估出來的值應該是實際值的25%至50%。

決定使用這三種不同預算評估類型中的哪一種是十分重要的。當我們對需要做的項目背景和業務非常熟悉，并且類似的項目已經做過很多次的情況下，使用精確評估是可行的。當我們正在做系統維護工作時，所能遇到的問題是已知的，或是增加一個我們曾經做過的功能時，這種預算評估是允許的。粗略評估是在我們對需求比較熟悉的，以及對相關領域和技術熟悉的情況下采用的。而在所有其他的情況下，最好的預算評估方法就是宏觀預算評估。也許有很多人固執地認為宏觀預算評估的結果幾乎等于沒做任何評估！但這種評估的結果實際上是非常價值的，因為這些評估結果可以給企業和項目街頭團隊一些關于正在進行的項目需要些什么，其中包括時間、資源和資金。使用這種方法我們至少知道某個項目需要兩到六個月的時間來完成。如果不進行評估，也許我們根據就不知道項目需要多少時間來完成。根據評估結果，我們可以根據需要對某些重要的項目進行更細致的預算評估。例如，我們可以為我們需要的基礎構架提供一個精略評估，而不僅僅是一個關于人員和時間的宏觀預算評估結果。

三、如何進行宏觀預算評估。

當我們開始個全新的項目時，所面對最多的就是這種預算評估方式。新的技術、對領域知識和技術不熟悉的團隊，或是對需求不清楚。而對付這些情況最好的預算評估方式就是宏觀預算評估。

1、打破項目是由許多不同需要的任務組成的束縛。嘗試著為項目盡可能地增加任務。典型的做法是按著設計和實現軟件的一般方法來提取出新任務，如分析、設計、實現、演示、測試、bug核對、文檔、發布以及技術支持等，看看如果這些步驟在每個任務中都要求去做，那么就可以考慮將它們提出來做為一個新的任務。

2、使用兩個指標來評估每一個任務：復雜度（分為高、中、低三個檔次）和工作量（分為大、中、小三個檔次）。一個并不復雜的任務仍然可能是一個工作量很大的任務。例如，將paper form上的信息保存在數據庫中可能需要數周的時間。一個非常復雜的的任務的工作量也可能不大，但仍然需要花很多時間來完成，例如對一個數據庫的性能優化。對于復雜的任務，一般當其非常大時，拆分成小的任務后分配到許多人或團隊時是非常困難的。而簡單的任務就很容易地被分拆和分配。

3、有效地評估任務所需的時間。對于最后形成的任務，需要定義它們所需的時間和資源。例如，我們可以設置低復雜度和工作量少的任務需要最多需要一周的時間，而中等復雜度和小工作時的任務需要三周的時間等等。這些量化后的指標和基于團隊和項目的指標不同，這此指標和數據將在下一次評估時幫助我們獲得更好的效果。因此，應該將所有的任務的宏觀評估值都加到一個表中，如下表所示：

表1 進行宏觀評估的任務表

四、如何進行粗略預算評估。

當我們對項目的任務有了一個好的想法，并知道如何去做的情況下，可以使用這種預算評估。

1、最好讓實際參與項目的人來進行這種評估工作。最后可以將這些參與評估的人的評估結果累加，從而得到最終的預算評估。

2、確保評估函數的自變量為：時間、人員和資源需求。

3、對分拆后的任務盡可能地考慮到它們的細節部分。在上面曾經提到過。按著典型的軟件設計和實現軌跡，如分析、設計、實現、演示、測試、bug核對、文檔、發布以及技術支持，并考慮這些任務是否為每個任務都需要的，對做這項工作是非常必要的。我們應保證每個時間單位為八十小時或更少的時間。

五、小結。

本文所討論的技術可以幫助我們更出色地完成預算評估工作。將評估所得出的數據和項目實際需求數據進行對比。鑒別什么是正確的，什么是錯誤的。將幫助我們改善下次評估的結果。隨著我們從事更多的預算評估工作，我們的經驗將會有更顯著的增加！