經常可以聽到為開發專案確定預算是一門藝術。考慮到所有的商業風險這看起來近似真實。專案的花費很容易就會成為完全不具實際意義的“模糊數學”的一個課題。以小時計算的開發時間，為了加快開發速度而增長預算，工具和其他資源的開銷都應該在基於顧客所能支付的範圍內上下波動。

要確保能夠精確的制定專案預算並保證方案順利交付，以下的方針會幫助你建立合理一致的預算並很有實際意義。

預算基礎

公司內的許多部門都會涉及到預算的問題。對於開發人員來說，它代表在應用程式的特定部分需要花費多少時間。對於專案經理，它是確保專案正常運作的基線。對於銷售人員或者客戶來說，它直接關係到努力的成果。所以對於建立預算的最大的問題就是把它解釋清楚這件事情不必太驚訝。不考慮客觀情況，一些基本的理論可以幫助你做無限預算，這樣可以避免主觀角度對你的影響。透過已經理解的概念以及保證那些相關的人理解這些概念，作出一個正確的規劃是理所當然的:

專案的開銷和專案預算是兩碼事。永遠是從確定專案的開銷開始
專案的開銷不僅僅指花多少錢。包括了實際的花費，運費和稅費，也包括軟體和硬體的採購費用。如果採用已經購買的軟硬體裝置，把他們計算為時間量（使用的小時數）。同樣的，開發人員花費也計算為時間而不是金錢。
一旦列出開銷，確定會遭遇的風險，並量化每一個風險會對整個專案造成多大的影響，或者對部分專案造成影響的百分比。每一個開發團隊都會被賦予一個風險值，用來處理有理由的開銷，比如僱用一個臨時工來保證不會超期，或者應付無法預料的超時工作。
這時候預算就是花銷的總和，它被轉化為現金錶，加上總體風險花費。為裝置和開發時間定義轉換值。
預算並不是一張發票。一旦確定了你的報表，要呈報給公司的決策人員做調整。確保他們理解你的報表中反映的花銷。
預算可能永遠被標為評估，直到它結束或被認可。
不能由一個人來建立預算，至少需要：開發領導人，專案經理和商業決策人。

確定專案花費

當確定了開發過程的花銷，要儘可能的貼近實際。透過觀察團隊內的成員在以往專案中的表現，感覺一下程式的編寫工作需要多少時間。諮詢開發負責人，有必要重複這句話，諮詢開發負責人。提防過度自信的評估，把可能的超時記入風險。

別忘記把整合和釋出的開銷包括進去。會議、安全認證、許可證費用、質量檢測耗時、除錯、文件編寫時間和資料費用，以及為經常遺漏的地方預留時間。儘管公司可能也可能不會要求客戶為這些付費，這些都是合理的確切的專案開銷。計算這些費用會幫助你精確的計算專案最終的收益率。

接下來，逐條的記錄那些不包括的，但是在以後可能會涉及的特性，甚至可能是對最終產品有益的特性，把這些列為可選項。另外一件事是可以在產品釋出後將開發人員支援時間延長到60天，通常當計劃完成時，支援團隊還沒有就位或者會有大批的問題延遲交給開發人員。

一旦得到了開銷的大概程度，就是時候來看看什麼會導致開銷的變化了。

風險費用

風險費用和分配對一個專案的成功至關緊要。沒有它，當每個專案固有的風險週期性的發生時，就會影響專案基線。評估的價值中應該包括這部分的開銷，但是可以不考慮銷售的影響。風險的描述實際是對開發過程的評估。

可以考慮的風險會包括開發團隊的經驗，技術應用不熟練（可容忍的程度），計劃時間不足，開發隊伍的數量和地區，標準元件的數量，專案依賴的資料庫或者第三方軟體以及所有未知的因素。

確定可以導致風險的專案後，為每一個專案分配範圍和百分比。舉例說，如果應用程式由C和Java組成，而開發團隊由C程式設計師組成，那麼Java元件就是潛在的高風險，它會被記錄到“開發經驗”的專案中。

所有專案都不可避免的存在人為的風險，比如生病或者休假。通常也會分配一個百分比給它，對於一個擁有10個開發人員，6個月的專案，合適的百分比是佔整個專案風險的5%。對於擁有較少開發人員而相對長期的專案該值會高一些，反之則會低些。

通常情況下，風險費用大體相當於總費用的20%-30%。是高還是低呢？實際的風險費用依賴於評估團隊的經驗和未來的努力。如果在經過計算評估後，數目過高，可以參考公司的其他計劃。他們是不是實際上符合預算呢？如果不是，說明你可能是對的。如果是，那麼可能是對你的團隊不太信任。應當重新評估你的風險預算。

總結

不管離現實有多近，客戶總是會對低於預算的專案感到高興。不管怎樣，過高的風險值都會使堅強的人動搖，表現的沒有自信並導致對管理能力的憂慮。透過本篇方針，我們建議你使用一些常用的原則，你能讓你的團隊，專案管理人和客戶都感到滿意。 [@more@]

怎樣建立專案預算（轉）

相關文章