軟件項目管理的成功原則

1 平衡原則

在咱們討論軟件項目爲何會失敗時能夠列出了不少的緣由，答案有不少，如管理問題、技術問題、人員問題等等，可是有一個根本的思想問題是最容易忽視的，也是軟件系統的用戶、軟件開發商、銷售代理商最不想正視的，那就是：需求、資源、工期、質量四個要素之間的平衡關係問題。

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

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

多：需求越多越好嗎？

軟件系統實施的基本原則是"全局規劃，分步實施，步步見效"，需求能夠多，可是需求必定要分優先級，要分清企業內的主要矛盾與次要矛盾，根據PARETO的80-20原則，企業中的80%的問題能夠用20%的投資來解決，若是你要大而全，對不起，你那20%的次要問題是須要你花費80%的投資的！而這一點偏偏是不少軟件用戶所不能忍受的。

快：真能快起來嗎？

"快"是用戶、軟件開發商都但願的。傳統企業裏強調資金的週轉狀況，軟件企業裏強調的是人員的週轉狀況，開發人員應儘快作完一個項目再作另一個項目，經過快速的啓動項目、結束項目來承擔更多的項目，來獲利。可是"快"不是主觀的拍腦殼定工期就能夠完成的，工期的定義必定要基於資源的情況、需求的多少與質量的需求來進行推算的。軟件畢竟須要一行代碼一行代碼的寫出來，他的工做量是客觀的，並不是"人有多大膽，地有多大產"式的精神鼓動就能夠短時間完成的。

好：什麼是好軟件？

軟件系統的"好"字是最難定義、最難度量的。"讓用戶滿意"是最高目標，你能夠作到，可是資金的投入與時間的投入用戶可否承擔的起呢？在硬件生產企業中，產品的需求是明確的，是有形的，質量目標是明確的，是能夠分解到各個做業環節中去的，而軟件生產不具有此特徵。在硬件生產中，生產能力是基本穩定的，對人員的依賴性較小，質量的要求對進度的影響並非差異很大，而在軟件生產中質量的一點提升或下降可能會對工期、投入產生巨大的影響，儘管用戶沒有明肯定義出質量要求，因此軟件生產是質量敏感型的生產。

省：省到什麼程度？

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

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

企業實施IT系統的首要目標是要成功，而不是失敗，企業能夠容忍小的成功，但不必定容忍小的失敗，因此須要真正理解上述四個要素的平衡關係，確保項目的成功。

2 高效原則

在需求、資源、工期、質量四個要素中，不少的項目決策者是將進度放在首位的，如今市場的競爭愈來愈激烈， "產品早上市一天，就早掙一天錢，掙的就比花的多，因此必定要多掙" ，基於這樣一個理念，軟件開發愈來愈追求開發效率，你們從技術、工具、管理上尋求更多更好的解決之道。

基於高效的原則，對項目的管理須要從幾個方面來考慮：

要選擇精英成員

目標要明確，範圍要清楚

溝通要及時、充分

要在激勵成員上下工夫

3 分解原則

"化繁爲簡，各個擊破"是自古以來解決複雜問題的不二法門，對於軟件項目來說，能夠將將大的項目劃分紅幾個小項目來作，將週期長的項目化分紅幾個明確的階段。

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

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

4 實時控制原則

在一家大型的軟件公司中，有一位頗有個性的項目經理，該項目經理不多談起什麼管理理論，也未見其有什麼明顯的管理措施，可是他連續作成多個規模很大的軟件項目，並且應用效果很好。做者一直很奇怪他爲何能作的如此成功，通過仔細觀察，終於發現他的管理能夠用"緊盯"2字來歸納，即天天他都要仔細檢查項目組每一個成員的工做，從軟件演示到內部的處理邏輯、數據結構等，一絲不苟，若是有問題，改不完是不能去休息的。正是在他這種簡單的措施下，支撐他完成了不少大的項目，固然他也是至關的辛苦，一般都是在凌晨纔去休息。咱們並不是要推崇這種作法，這種措施也有他的問題，可是，這種實踐卻說明了一個很樸實的道理：若是你沒有更好的辦法，就要辛苦一點，實時控制項目的進展，要將項目的進展狀況徹底的實時的置於你的控制之下。

上述的方法中對項目經理的我的能力、犧牲精神要求是很高，咱們須要有一種進行實時控制項目進度的機制，依靠一套規範的過程來保證明時監控項目的進度。如在微軟的管理策略中強每日構建"，這確實是是一種不錯的方法，即天天要進行一次系統的編譯連接，經過編譯連接來檢查進度、檢查接口、發現進展中的問題、你們互相鼓勵互相監督。

實時控制確保項目經理可以及時發現問題、解決問題，保證項目具備很高的可見度，保證項目的正常進展。

5 分類管理原則

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

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

6 簡單有效原則

項目經理在進行項目管理的過程當中，每每會獲得開發人員這樣的抱怨"太麻煩了，浪費時間，沒有用處"，這是很廣泛的一種現象。固然這樣的抱怨要從2個方面來分析，一方面從開發人員自己可能存在不理解，或者逆反心理的狀況，另外一方面，項目經理也要反思：我所採起的管理措施是否簡單有效？搞管理不是搞學術研究，沒有完美的管理，只有有效的管理，而項目經理每每試圖堵住全部的漏洞，解決全部的問題，偏偏是這種理想，會使項目的管理陷入一個誤區，做繭自縛，最後沒法實施有效的管理，致使項目的失敗。

7 規模控制原則

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