軟件開發的殘酷的現實告訴我們：沒有規則的軟件開發過程帶來的只可能是無法預料的結果。我們中的大多數項目管理人員在其個人簡歷中紛紛寫到："擁有多年的豐富的項目管理經驗"，但在實際開發中，"豐富的"管理經驗變成了軟件開發人員可怕的夢魘。一次次的失敗、一次次的返工，她所謂的項目管理經驗只不過是再一次的游戲于"無間"(十八層地獄)。
一次，在與不少項目管理者的交流中，大家紛紛提到的軟件變更帶來的可怕影響。但是正如完整的法律體制不能制止犯罪，但沒有完整的法律體制犯罪會更加猖獗一樣，頻繁的軟件變更固然可怕，但是沒有一個完整的項目管理對應機制，我們無法相像項目終會是一個什么樣子。此外還有一次，筆者在求職時，招聘公司的技術主管(40-50歲左右)，向我吹噓公司按CMM4的過程規則來進行軟件的開發和管理。殊不知，我一問下面開發人員，她們在經歷無數的加班后正在給已經完成的軟件項目添加軟件概要設計書，這讓我大吃一驚。
如此這樣形式主義的公司，不呆也罷。記得一個格言曾經說過"人類愚蠢的行為在于忘記常識"。另外一句較為相仿的格言則是"不知道歷史的人必然會重蹈覆。作為項目管理來說亦為同樣的道理。很可惜，我們中的大多數管理者口口聲聲"軟件工程"，工作時"用程序代替用戶需求"，極具政客的嘴臉。其結果必然如目前媒體"程序員生存狀況"所言，以開發人員在時間的犧牲為代價來換取項目的結束，這是再為普遍不過的現象，在此不再妄加評論。
如何改善我們的軟件開發管理，一條便捷之道便是"尊重常識，尊重歷史經驗教訓"。在軟件項目管理中，有許多的原則和經驗可以供我們借鑒。
一、 計劃原則
沒有計劃，你無從知道什么時候控制和變更。制定一個詳盡的計劃，以詳細到開發人員可以理解的程度為宜。計劃能夠告訴你什么時候應該做什么。沒有計劃，你無從知道自己需要做什么。不少項目經理告訴組員需要做什么東西后揚長而去，絲毫沒有一個相關任務(活動)之間的說明。由于沒有計劃或是計劃太粗糙、不切實 際，很多項目1/3甚至1/2的時間花在返工上面。因為計劃中遺漏了某一項關鍵任務，項目有可能宣告失敗。試想一下，制定一個周密合理的計劃需要耗費這么多的時間嗎?需要付出項目失敗的代價嗎?還有很多項目管理人員常常錯誤認為"變化比計劃快"，但實際的情況是，由于沒有計劃，你無法預測和估量變化給你的項目所帶來影響，你所面臨的將會是比面條還難以理清?混沌"狀態。此外，對于開發人員來說，"目標導向(Objective Oriented)"是充分調動其工作積極性的佳方法，每一個任務階段的成果能夠將員工的工作效率維持在一個較高的水平。因為近期目標總是比遠期目標來說更容易看到和達到。為此，制定一個計劃吧，讓它符合目標導向(通過各個具體任務計劃促使項目總計劃的達成)。項目管理者聯盟
二、 Brooks原則
向一個已經滯后的項目添加人員，可能會使項目更加滯后。因為作為新加入的員工來說，相關培訓、環境熟悉和人員之間的溝通通路的增加，迫使項目的工作效率急劇下跌。工作效率下降需要加班來進行彌補，但加班造成的疲勞會再次使工作效率降低。同時工作成本卻不斷的向上攀升。不過目前來說，項目管理人員絲毫不會 理會這一點，"人多力量大"也許更能引人入勝。不少項目管理人員抱怨到時間的急迫性，須知很多項目內時間的急迫性來自于項目管理人員不假思索和不基于常理的邀功表現，沒有充分考慮的開發人員能力的多樣性
所致。為此，正規的企業不得不耗費大量的加班費用于加班人員的津貼，同時亦要承擔違反《勞動法》的潛在法律危險。現在一種萬不得已的做法是，假設項目開發人員之間的任務的關聯性不是太大的情況下，采取兩班倒或是三班倒的方法來保證時間的延續性和相關開發人員的工作高效性。
三、 驗收標準原則blog.mypm.net
我們在進行某項任務，往往會為以何種結果為宜而感到困惑。不求質量的開發人員往往憑據經驗草草了事，追求完美的開發人員則在該項任務上耗費太多的精力，但此番耗費未必針對該項任務，因而常常吃力不討好。這是由于沒有驗收標準而導致的情景。因為沒有驗收標準，你無法知道你要進行的任務需要一個什么樣的結果， 需要達到什么樣的質量標準。在很多情況下，你的活動會與期望結果背道而馳，而此時的你還在沉醉于自己的辛勤耕耘之中。作為項目經理來說，只有制定好每個任務的驗收標準，才能夠嚴格把好每一個質量關、同時了解項目的進度情況。
四、 默認無效原則
你的項目成員理解和贊成項目的范圍、目標和你所制定的項目策略嗎?不少項目管理人員認為"沉默意味著同意"。實際上我們或多或少都會陷入這樣的一個思維誤區。試想一下，你作為職員或項目開發人員時的沉默完全代表你贊成你的領導的意見嗎?不見得，這是答案。這一點在項目溝通中極為重要，項目管理者切不可為 沉默認為是同意，沉默在很大的程度上說明項目開發人員還尚未弄清楚項目的范圍、任務和目標。為此項目管理者還需要同開發人員進行充分溝通，了解開發人員的想法。在對項目沒有一個共同的一致的理解的前提下，一個團隊是不可能成功的。
五、 80-20原則轉自項目管理者聯盟
80-20原則在軟件開發和項目管理方面有許多"實例"。其一便是我們在20%的項目要求上耗費了80%的時間。仔細分析一下，這些項目要求分為必須的非必須的，因此我們建議是壓縮非必須的部分或是暫時將其放在一邊不必太重視。軟件項目開發事實告訴我們，開發人員在非必須的項目要求上耗費了太多的精力，用 戶的需求變更的大部分出現在"好有"這一部分，實際上用戶并不看重這些需求(即使去除這些需求)，而我們所做的，往往是舍本求末。
80-20原則的另外一個實例是我們項目中的20%的人員擔當了80%的項目任務(這樣講在實際實施中一點都不過分)。考慮到開發人員能力的多樣性，聰明的項目管理人員決不會采取任務均分的愚蠢做法，因為系統論的觀點來看，互補結構比對等結構要更穩定一些。此外作為項目管理人員來說，了解屬下員工的能力 特點，將其放在合適的位置上，會更有利于項目的順利進行。很多管理人員常常抱怨屬下能力問題，究其實質，往往是這些項目管理人員未能發現開發人員潛能所在之處。她們看待問題往往以"經驗"這樣的思維定勢來做決定。導致的結果如系統論所言：由于"抱怨"的作用和反作用循環，結果是大家都不歡而散。
