變化原則
也許有人問過你，在項目管理中唯一不變的東西是什么？我可以告訴你，項目中唯一不變的就是“變化”。在項目中不考慮可能發生的變化是不可思議的。不過在面對項目可能發生變化而帶來的項目風險時，我們的項目管理人員往往會懷有逃避的態度。經濟學里大名鼎鼎的風險規避原則便是項目管理人員心理的有效描述。作為項目管理人員來說，應該及早預測可能出現的風險，做好風險儲備。雖然風險儲備不能解決所有的問題，但是“預防勝于治療”�？上У氖俏覀兘^大多數人沒有這方面的意識，否則醫院的生意未必如此紅火，項目開發之途未必如此坎坷。
作業標準原則
一個團隊要完成項目的開發需要有一定的章法。很可惜，在國內目前仍然以“作坊式”為主，高舉“我們符合國際CMM X規范（ISO某某規范）”的環境下，未必有多少項目團隊注意到這一點。我們曾經驚嘆印度的高中生都能編程序，而國內卻非本科、碩士不收眼簾。究其原因，在于沒有開發章法或是章法粗糙，猶如牛皮圣旨一般。一個好的代碼模板和代碼規范能夠解決大多數人編寫程序隨心所欲的問題，很可惜，沒有多少項目管理人員有此意識，也沒有多少人愿意去做這項基礎任務。業務軟件開發需要高超的開發技巧嗎？不需要，那是故弄玄虛的開發人員的伎倆。軟件開發的美在于其簡潔性和規范性，不在于奇技淫巧。因為缺乏作業標準，我們付出的代價是客戶的抱怨和無休止的返工。此外，對于那些以形式主意蒙人的項目團隊來說，如果你實質如同你口頭所說那樣，也許你就不會是今天的這副狼狽相。
復用和組織變革原則－解決項目問題的未來之路
如何解決日益突出的項目工期、成本、質量等問題，這是大多數項目管理者最為關心的問題。從實踐來看加強復用的力度，建立項目復用體系和實施組織變革是效果較好的途徑之一。復用能夠提高項目的生產率，降低項目風險。通過復用，項目管理者能夠快速完成項目。
驗收標準原則
我們在進行某項任務，往往會為以何種結果為宜而感到困惑。不求質量的開發人員往往憑據經驗草草了事，追求完美的開發人員則在該項任務上耗費太多的精力，但此番耗費未必針對該項任務，因而常常吃力不討好。這是由于沒有驗收標準而導致的情景。因為沒有驗收標準，你無法知道你要進行的任務需要一個什么樣的結果，需要達到什么樣的質量標準。在很多情況下，你的活動會與期望結果背道而馳，而此時的你還在沉醉于自己的辛勤耕耘之中。作為項目經理來說，只有制定好每個任務的驗收標準，才能夠嚴格把好每一個質量關、同時了解項目的進度情況。
默認無效原則
你的項目成員理解和贊成項目的范圍、目標和你所制定的項目策略嗎？不少項目管理人員認為“沉默意味著同意”。實際上我們或多或少都會陷入這樣的一個思維誤區。試想一下，你作為職員或項目開發人員時的沉默完全代表你贊成你的領導的意見嗎？不見得，這就是答案。這一點在項目溝通中極為重要，項目管理者切不可為沉默認為是同意，沉默在很大的程度上說明項目開發人員還尚未弄清楚項目的范圍、任務和目標。為此項目管理者還需要同開發人員進行充分溝通，了解開發人員的想法。在對項目沒有一個共同的一致的理解的前提下，一個團隊是不可能成功的。
80-20原則
80-20原則在軟件開發和項目管理方面有許多“實例”。其一便是我們在20％的項目要求上耗費了80％的時間。仔細分析一下，這些項目要求分為必須的非必須的，因此我們建議是壓縮非必須的部分或是暫時將其放在一邊不必太重視。軟件項目開發事實告訴我們，開發人員在非必須的項目要求上耗費了太多的精力，用戶的需求變更的大部分出現在“最好有”這一部分，實際上用戶并不看重這些需求（即使去除這些需求），而我們所做的，往往是舍本求末。
80-20原則的另外一個實例是我們項目中的20％的人員擔當了80％的項目任務（這樣講在實際實施中一點都不過分）�？紤]到開發人員能力的多樣性，聰明的項目管理人員決不會采取任務均分的愚蠢做法，因為就系統論的觀點來看，互補結構比對等結構要更穩定一些。此外作為項目管理人員來說，了解屬下員工的能力特點，將其放在合適的位置上，會更有利于項目的順利進行。很多管理人員常常抱怨屬下能力問題，究其實質，往往是這些項目管理人員未能發現開發人員潛能所在之處。她們看待問題往往以“經驗”這樣的思維定勢來做決定。導致的結果如系統論所言：由于“抱怨”的作用和反作用循環，結果是大家都不歡而散。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
