軟件工程項目管理原則

一.平衡原則
在我們討論軟件項目為什么會失敗時可以列出很多的原因，如 管理問題、技術問題、人員問題等，但是有一個根本的思想問題是 更容易忽視的，也是軟件系統的用戶、軟件開發商、銷售代理商更 不想正視的，那就是：需求、資源、工期、質量這四個要素之間的 平衡關系問題。結合實際，我們可以通俗地理解這四者之間彼此的聯系，需求的增多，必然會帶來資源消耗的增多和工期的延長；而用戶的需求又與工期密切關聯，用戶不希望工程交付過晚；相對而言，追求更高的質量，需要我們投入更多的人力物力資源，甚至更長的工期；同樣，一個高質量的產品，也不是盲目得趕工期，多投入就可以完成的。這就要求我們在實際中考慮平衡需求，資源，工期，質量并得到各方面均衡的一個更優解。在軟件項目中我們不僅僅是關注項目的進度，質量，范圍和成本四要素的平衡。還需要關注人員角色分工的平衡，冒險和保守的平衡，外部和內部的平衡，紀律和靈活性間的平衡等等。任何一個方面失去平衡，項目都可能處于危險中。

二.卓效原則
記得看過一篇facebook創始人扎克伯格回憶自己創業之初的故事，有一句話讓我印象深刻，“真實決定人生高度的，是你做事的速度”。當初，心血來潮的扎克伯格從產生想法，到實現一款簡單的應用--大頭照對比評分應用FaceMash，僅用了6個小時。在短短的時間內，他獨自一人完成了產品的設計，開發，上線....這在當時可能是一個小型企業兩天的日常工作量。而他的對頭，在哈弗就讀的Winklevoss兄弟，總說扎克伯格抄襲了他們的創意，才有了后來的facebook，而事實呢？在Winklevoss兄弟在猶豫是否要投入做社交網站時，扎克伯格的facebook已經覆蓋了29所學校，7.5萬注冊用戶。促成他們以后差距的，正是二者執行力的差距。也只有像這樣在短時間內完成高質量的任務才能稱之為卓效。

三.優先原則
在軟件工程中存在這樣的PARETO定律：在實際中企業80%的問題可以用20%的投資解決，而20%的次要問題則需要花費80%的投資的。在軟件項目中，如果出現了過多的需求，通常會導致項目超出預算和預定進度，更終導致軟件項目的失敗，此時需求的優先級可能比需求本身更為重要。仔細分析一下，這些項目要求分為需要的非需要的，因此我們建議是壓縮非需要的部分或是暫時將其放在一邊不必太重視。軟件項目開發事實告訴我們，開發人員在非需要的項目要求上耗費了太多的精力，用戶的需求變更的大部分出現在"更好有"這一部分，實際上用戶并不看重這些需求（即使去除這些需求），而我們所做的，往往是舍本求末。
在實際情況中，軟件開發負責人員往往會面臨需求方提出的一系列繁復的需求，在實施過程中一定要將需求劃分為不同的優先級，建立項目開發的需求優先級隊列，對于一個管理良好的軟件工程必不可少。反之，盲目追求對細枝末節的全覆蓋，反而會很大拖慢工期進度，甚至影響產品質量。

四.分解原則
“分而治之”是計算機領域的一個重要思想，對于軟件項目來講，可以將大的項目劃分成幾個小項目來做，將周期長的項目化分成幾個明確的階段。在需求管理中首先要進行分類管理，將軟件需求分出層次，不同層次需求的側要點、描述方式和管理方式是不同的。對于管理層而言，提出的需求可能會更加偏向于全局性的目標需求，對于底層實現和分工并不關心；而中層需要將具體的操作，代碼分配給不同部分，人員進行實現，同時需要考慮各部分之間的相互銜接。項目越大對項目組的管理人員、開發人員的要求越高，參與的人員越多，需要協調溝通的渠道越多，周期越長，開發人員也容易疲勞，將大項目拆分成幾個小項目，可以降低對項目管理人員的要求，減少項目的管理風險，而且能夠充分地將項目管理的權力下放，充分調動人員的積極性，目標會比較具體明確，易于取得階段性的成果，使開發人員有成就感。

五.風險原則
某家知名軟件公司曾總結出排行前幾的為軟件管理埋下風險的罪魁禍首，分別是：
1.人為缺陷；2.不切實際的時間表和預算；3.開發錯誤的功能和屬性；4.開發錯誤的用戶交互；5.畫蛇添足；6.持續的需求更改.....
軟件項目管理的過程中，唯一不變的就是"變化"。風險管理也是始終貫穿于軟件項目管理之中的重要元素，在項目中不考慮可能發生的變化是不可思議的。不過在面對項目可能發生變化而帶來的項目風險時，項目管理人員往往會懷有逃避的態度。經濟學里大名鼎鼎的風險規避原則便是項目管理人員心理的有效描述。作為項目管理人員來說，應該及早預測可能出現的風險，做好風險儲備。雖然風險儲備不能解決所有的問題，但預防勝于治療"。通過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法，掌握項目風險管理所必備的知識。通過加強對項目規劃中風險管理計劃的審核提高項目組的風險管理意識。