1 平衡原則

在我們討論軟體專案為什麼會失敗時可以列出了很多的原因，答案有很多，如管理問題、技術問題、人員問題等等，但是有一個根本的思想問題是最容易忽視的，也是軟體系統的使用者、軟體開發商、銷售代理商最不想正視的，那就是：需求、資源、工期、質量四個要素之間的平衡關係問題。

需求定義了"做什麼"，定義了系統的範圍與規模，資源決定了專案的投入（人、財、物），工期定義了專案的交付日期，質量定義了做出的系統好到什麼程度，這四個要素之間是有制約平衡關係的。如果需求範圍很大，要在較少的資源投入下，很短的工期內，很高的質量要求來完成某個專案，那是不現實的，要麼需要增加投資，要麼工程延期；如果需求界定清楚了，資源固定了，對系統的質量要求很高，則可能需求延長工期。

對於上述四個要素之間的平衡關係最容易犯的一個錯誤，就是鼓吹"多快好省"四個字，"多快好省"，多麼理想的境界啊？需求越多越好，工期越短越好，質量越高越好，投入越少越好，這是使用者最常用的口號。

多：需求越多越好嗎？

軟體系統實施的基本原則是"全域性規劃，分步實施，步步見效"，需求可以多，但是需求一定要分優先順序，要分清企業內的主要矛盾與次要矛盾，根據PARETO的80-20原則，企業中的80%的問題可以用20%的投資來解決，如果你要大而全，對不起，你那20%的次要問題是需要你花費80%的投資的！而這一點恰恰是很多軟體使用者所不能忍受的。

快：真能快起來嗎？

"快"是使用者、軟體開發商都希望的。傳統企業裡強調資金的週轉情況，軟體企業裡強調的是人員的週轉情況，開發人員應儘快做完一個專案再做另外一個專案，透過快速的啟動專案、結束專案來承擔更多的專案，來獲利。但是"快"不是主觀的拍腦袋定工期就可以完成的，工期的定義一定要基於資源的狀況、需求的多少與質量的需求來進行推算的。軟體畢竟需要一行程式碼一行程式碼的寫出來，他的工作量是客觀的，並非?quot;人有多大膽，地有多大產"式的精神鼓動就可以短期完成的。

省：省到什麼程度？

"一分錢一分貨"，這是中國的俗話，他是符合價值規律的。甲方希望少投入，乙方希望降低自己的生產成本，省到乙方僅能保本的時候，再省，乙方就虧損了。

正視這四個要素之間的平衡關係是軟體使用者、開發商、代理商成熟理智的表現，否則系統的成功就失去了一塊最堅實的理念基礎。

企業實施IT系統的首要目標是要成功，而不是失敗，企業可以容忍小的成功，但不一定容忍小的失敗，所以需要真正理解上述四個要素的平衡關係，確保專案的成功。

2 高效原則

在需求、資源、工期、質量四個要素中，很多的專案決策者是將進度放在首位的，現在市場的競爭越來越激烈， "產品早上市一天，就早掙一天錢，掙的就比花的多，所以一定要多掙" ，基於這樣一個理念，軟體開發越來越追求開發效率，大家從技術、工具、管理上尋求更多更好的解決之道。

基於高效的原則，對專案的管理需要從幾個方面來考慮：

要選擇精英成員

目標要明確，範圍要清楚

溝通要及時、充分

要在激勵成員上下工夫

3 分解原則

"化繁為簡，各個擊破"是自古以來解決複雜問題的不二法門，對於軟體專案來講，可以將將大的專案劃分成幾個小專案來做，將週期長的專案化分成幾個明確的階段。

專案越大對專案組的管理人員、開發人員的要求越高，參與的人員越多，需要協調溝通的渠道越多，週期越長，開發人員也容易疲勞，將大專案拆分成幾個小專案，可以降低對專案管理人員的要求，減少專案的管理風險，而且能夠充分地將專案管理的權力下放，充分調動人員的積極性，目標會比較具體明確，易於取得階段性的成果，使開發人員有成就感。

作者主管過的一個產品開發專案代號為SB，該專案前期投入了5人做需求，時間達3個多月，進入開發階段後，投入了15人，時間達10個月之久，陸續進行了3次封閉開發，在此過程中經歷了需求的裁剪、開發人員的變更、技術路線的調整，專案組成員的壓力極大，大家疲憊不堪，產品上市時間拖期達4個月。專案完工後總結下來的很致命的一個教訓就是應該將該專案拆成3個小的專案來做，進行階段性版本化釋出，以緩解市場上的壓力，減少專案組成員的挫折感，提高大家計程車氣。

4 實時控制原則

在一家大型的軟體公司中，有一位很有個性的專案經理，該專案經理很少談起什麼管理理論，也未見其有什麼明顯的管理措施，但是他連續做成多個規模很大的軟體專案，而且應用效果很好。作者一直很奇怪他為什麼能做的如此成功，經過仔細觀察，終於發現他的管理可以用"緊盯"2字來概括，即每天他都要仔細檢查專案組每個成員的工作，從軟體演示到內部的處理邏輯、資料結構等，一絲不苟，如果有問題，改不完是不能去休息的。正是在他這種簡單的措施下，支撐他完成了很多大的專案，當然他也是相當的辛苦，通常都是在凌晨才去休息。我們並非要推崇這種做法，這種措施也有他的問題，但是，這種實踐卻說明了一個很樸實的道理：如果你沒有更好的辦法，就要辛苦一點，實時控制專案的進展，要將專案的進展情況完全的實時的置於你的控制之下。

上述的方法中對專案經理的個人能力、犧牲精神要求是很高，我們需要有一種進行實時控制專案進度的機制，依靠一套規範的過程來保證實時監控專案的進度。如在微軟的管理策略中強?quot;每日構建"，這確實是是一種不錯的方法，即每天要進行一次系統的編譯連結，透過編譯連結來檢查進度、檢查介面、發現進展中的問題、大家互相鼓勵互相監督。

實時控制確保專案經理能夠及時發現問題、解決問題，保證專案具有很高的可見度，保證專案的正常進展。

5 分類管理原則

對於不同的軟體專案其專案目標差別很大，專案規模也是不同的，應用領域是不同的，採用的技術路線差別也很大，因而，針對每個專案的不同特點，其管理的方法、管理的側重點應該是不同的。就像古人講的，"因材施教"，"對症下藥"。對於小專案你肯定不能象管理大專案那樣去做，對於產品開發類的專案，你也不可能象管理系統整合類的專案那樣去做，專案經理需要根據專案的特點，制訂不同的專案管理的方針政策。如，下表是作者為一家應用軟體公司制訂的專案管理的方針：

在該案例中，將專案分成了訂單類專案與非訂單類專案，非訂單類專案是指由公司根據市場的需求開發一個標準產品的專案，而訂單類是指標對某個具體的客戶定製軟體的專案，訂單類的專案根據需要協調的資源的範圍有劃分成了公司級、部門級、個人級三類，非訂單類根據估算的工作量的大小也分成了A、B、C三類，估算的工作量超過720人天的為A類，超過360人天的為B類，360人天以下的為C類。不同類的專案管理的側重點是不同的，從立項手續的完備性、計劃的嚴格層度、週報的完備層度、規範的嚴格層度、跟蹤的實時性、是否進行階段總結、是否核算專案成本、是否嚴格進行階段評審等多個方面來考慮，以確保管理的可行性。

6 簡單有效原則

專案經理在進行專案管理的過程中，往往會得到開發人員這樣的抱怨"太麻煩了，浪費時間，沒有用處"，這是很普遍的一種現象。當然這樣的抱怨要從2個方面來分析，一方面從開發人員本身可能存在不理解，或者逆反心理的情況，另一方面，專案經理也要反思：我所採取的管理措施是否簡單有效？搞管理不是搞學術研究，沒有完美的管理，只有有效的管理，而專案經理往往試圖堵住所有的漏洞，解決所有的問題，恰恰是這種理想，會使專案的管理陷入一個誤區，作繭自縛，最後無法實施有效的管理，導致專案的失敗。

7 規模控制原則

該原則是和上面提到的其他原則相配合使用的，即要控制專案組的規模，不要人數太多，人數多了，進行溝通的渠道就多了，管理的複雜度就高了，對專案經理的要求也就高了。在微軟的MSF中，有一個很明確的原則就是要控制專案組的人數不要超過10人，當然這不是絕對的，也和專案經理的水平有很大關係。但是人員"貴精而不貴多"，這是一個基本的原則，這和我們上面提到的高效原則、分解原則是相輔相成的。
[@more@]

軟體專案管理的成功七法則（轉）

相關文章