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

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

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

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

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