軟件開發(fā)的殘酷的現(xiàn)實告訴我們：沒有規(guī)則的軟件開發(fā)過程帶來的只可能是無法預(yù)料的結(jié)果。我們中的大多數(shù)項目管理人員在其個人簡歷中紛紛寫到："擁有多年的豐富的項目管理經(jīng)驗"，但在實際開發(fā)中，"豐富的"管理經(jīng)驗變成了軟件開發(fā)人員可怕的夢魘。一次次的失敗、一次次的返工，她所謂的項目管理經(jīng)驗只不過是再一次的游戲于"無間"（十八層地獄）。一次，在與不少項目管理者的交流中，大家紛紛提到的軟件變更帶來的可怕影響。但是正如完整的法律體制不能制止犯罪，但沒有完整的法律體制犯罪會更加猖獗一樣，頻繁的軟件變更固然可怕，但是沒有一個完整的項目管理對應(yīng)機(jī)制，我們無法相像項目終會是一個什么樣子。此外還有一次，筆者在求職時，招聘公司的技術(shù)主管（40-50歲左右），向我吹噓公司按CMM4的過程規(guī)則來進(jìn)行軟件的開發(fā)和管理。殊不知，我一問下面開發(fā)人員，她們在經(jīng)歷無數(shù)的加班后正在給已經(jīng)完成的軟件項目添加軟件概要設(shè)計書，這讓我大吃一驚。如此這樣形式主義的公司，不呆也罷。

　　記得一個格言曾經(jīng)說過"人類愚蠢的行為在于忘記常識"。另外一句較為相仿的格言則是"不知道歷史的人必然會重蹈覆。作為項目管理來說亦為同樣的道理。很可惜，我們中的大多數(shù)管理者口口聲聲"軟件工程"，工作時"用程序代替用戶需求"，極具政客的嘴臉。其結(jié)果必然如目前媒體"程序員生存狀況"所言，以開發(fā)人員在時間的犧牲為代價來換取項目的結(jié)束，這是再為普遍不過的現(xiàn)象，在此不再妄加評論。

　　如何改善我們的軟件開發(fā)管理，一條便捷之道便是"尊重常識，尊重歷史經(jīng)驗教訓(xùn)"。在軟件項目管理中，有許多的原則和經(jīng)驗可以供我們借鑒。

　　一、 計劃原則

　　沒有計劃，你無從知道什么時候控制和變更。制定一個詳盡的計劃，以詳細(xì)到開發(fā)人員可以理解的程度為宜。計劃能夠告訴你什么時候應(yīng)該做什么。沒有計劃，你無從知道自己需要做什么。不少項目經(jīng)理告訴組員需要做什么東西后揚(yáng)長而去，絲毫沒有一個相關(guān)任務(wù)（活動）之間的說明。由于沒有計劃或是計劃太粗糙、不切實際，很多項目1/3甚至1/2的時間花在返工上面。因為計劃中遺漏了某一項關(guān)鍵任務(wù)，項目有可能宣告失敗。試想一下，制定一個周密合理的計劃需要耗費(fèi)這么多的時間嗎？需要付出項目失敗的代價嗎？還有很多項目管理人員常常錯誤認(rèn)為"變化比計劃快"，但實際的情況是，由于沒有計劃，你無法預(yù)測和估量變化給你的項目所帶來影響，你所面臨的將會是比面條還難以理清?混沌"狀態(tài)。此外，對于開發(fā)人員來說，"目標(biāo)導(dǎo)向（Objective Oriented）"是充分調(diào)動其工作積極性的佳方法，每一個任務(wù)階段的成果能夠?qū)�員工的工作效率維持在一個較高的水平。因為近期目標(biāo)總是比遠(yuǎn)期目標(biāo)來說更容易看到和達(dá)到。為此，制定一個計劃吧，讓它符合目標(biāo)導(dǎo)向（通過各個具體任務(wù)計劃促使項目總計劃的達(dá)成）。

　　二、 Brooks原則

　　向一個已經(jīng)滯后的項目添加人員，可能會使項目更加滯后。因為作為新加入的員工來說，相關(guān)培訓(xùn)、環(huán)境熟悉和人員之間的溝通通路的增加，迫使項目的工作效率急劇下跌。工作效率下降需要加班來進(jìn)行彌補(bǔ)，但加班造成的疲勞會再次使工作效率降低。同時工作成本卻不斷的向上攀升。不過目前來說，項目管理人員絲毫不會理會這一點，"人多力量大"也許更能引人入勝。不少項目管理人員抱怨到時間的急迫性，須知很多項目內(nèi)時間的急迫性來自于項目管理人員不假思索和不基于常理的邀功表現(xiàn)，沒有充分考慮的開發(fā)人員能力的多樣性
所致。為此，正規(guī)的企業(yè)不得不耗費(fèi)大量的加班費(fèi)用于加班人員的津貼，同時亦要承擔(dān)違反《勞動法》的潛在法律危險。現(xiàn)在一種萬不得已的做法是，假設(shè)項目開發(fā)人員之間的任務(wù)的關(guān)聯(lián)性不是太大的情況下，采取兩班倒或是三班倒的方法來保證時間的延續(xù)性和相關(guān)開發(fā)人員的工作高效性。

　　三、 驗收標(biāo)準(zhǔn)原則

　　我們在進(jìn)行某項任務(wù)，往往會為以何種結(jié)果為宜而感到困惑。不求質(zhì)量的開發(fā)人員往往憑據(jù)經(jīng)驗草草了事，追求完美的開發(fā)人員則在該項任務(wù)上耗費(fèi)太多的精力，但此番耗費(fèi)未必針對該項任務(wù)，因而常常吃力不討好。這是由于沒有驗收標(biāo)準(zhǔn)而導(dǎo)致的情景。因為沒有驗收標(biāo)準(zhǔn)，你無法知道你要進(jìn)行的任務(wù)需要一個什么樣的結(jié)果，需要達(dá)到什么樣的質(zhì)量標(biāo)準(zhǔn)。在很多情況下，你的活動會與期望結(jié)果背道而馳，而此時的你還在沉醉于自己的辛勤耕耘之中。作為項目經(jīng)理來說，只有制定好每個任務(wù)的驗收標(biāo)準(zhǔn)，才能夠嚴(yán)格把好每一個質(zhì)量關(guān)、同時了解項目的進(jìn)度情況。

　　四、 默認(rèn)無效原則

　　你的項目成員理解和贊成項目的范圍、目標(biāo)和你所制定的項目策略嗎？不少項目管理人員認(rèn)為"沉默意味著同意"。實際上我們或多或少都會陷入這樣的一個思維誤區(qū)。試想一下，你作為職員或項目開發(fā)人員時的沉默完全代表你贊成你的領(lǐng)導(dǎo)的意見嗎？不見得，這是答案。這一點在項目溝通中極為重要，項目管理者切不可為沉默認(rèn)為是同意，沉默在很大的程度上說明項目開發(fā)人員還尚未弄清楚項目的范圍、任務(wù)和目標(biāo)。為此項目管理者還需要同開發(fā)人員進(jìn)行充分溝通，了解開發(fā)人員的想法。在對項目沒有一個共同的一致的理解的前提下，一個團(tuán)隊是不可能成功的。

　　五、 80-20原則

　　80-20原則在軟件開發(fā)和項目管理方面有許多"實例"。其一便是我們在20％的項目要求上耗費(fèi)了80％的時間。仔細(xì)分析一下，這些項目要求分為必須的非必須的，因此我們建議是壓縮非必須的部分或是暫時將其放在一邊不必太重視。軟件項目開發(fā)事實告訴我們，開發(fā)人員在非必須的項目要求上耗費(fèi)了太多的精力，用戶的需求變更的大部分出現(xiàn)在"好有"這一部分，實際上用戶并不看重這些需求（即使去除這些需求），而我們所做的，往往是舍本求末。

　　80-20原則的另外一個實例是我們項目中的20％的人員擔(dān)當(dāng)了80％的項目任務(wù)（這樣講在實際實施中一點都不過分）。考慮到開發(fā)人員能力的多樣性，聰明的項目管理人員決不會采取任務(wù)均分的愚蠢做法，因為系統(tǒng)論的觀點來看，互補(bǔ)結(jié)構(gòu)比對等結(jié)構(gòu)要更穩(wěn)定一些。此外作為項目管理人員來說，了解屬下員工的能力特點，將其放在合適的位置上，會更有利于項目的順利進(jìn)行。很多管理人員常常抱怨屬下能力問題，究其實質(zhì)，往往是這些項目管理人員未能發(fā)現(xiàn)開發(fā)人員潛能所在之處。她們看待問題往往以"經(jīng)驗"這樣的思維定勢來做決定。導(dǎo)致的結(jié)果如系統(tǒng)論所言：由于"抱怨"的作用和反作用循環(huán)，結(jié)果是大家都不歡而散。

　　六、 帕金森原則

　　帕金森原則原是用于反映政府部門機(jī)構(gòu)臃腫，效率低下的代名詞。不過它在軟件開發(fā)中一樣適用。沒有時限限制的話，工作可能無限延期。在軟件開發(fā)中，如果沒有嚴(yán)格的時間限制，開發(fā)人員往往比較懈怠。這是人的天性所決定的。千萬不要指望奇跡的發(fā)生――"所有員工的思想覺悟異常崇高"。作為項目管理者而言，此時應(yīng)充分考慮到員工的工作效率和項目變更帶來的負(fù)面影響，制定合理的項目工期并鼓動開發(fā)人員盡快完成。

　　七、時間分配原則

　　在項目計劃編制過程中，我們常常將資源可用率（人、設(shè)備）等設(shè)置為100％，殊不知你曾想過，由于開發(fā)人員需要休息、吃飯、開會等，根本不可能把所有的時間放在項目開發(fā)工作上，而且這還不考慮到開發(fā)人員的工作效率是否保持在一恒定水平上。所謂8小時工時制實際上是徒有虛名。由于項目管理人員的"無知"，不少開發(fā)人員被迫拼命加班。結(jié)果依舊出現(xiàn)Brooks原則所出現(xiàn)問題。在實際開發(fā)中，開發(fā)員工的時間利用率能夠達(dá)到80％已經(jīng)時很不錯的了，我個人比較傾向于60％左右（黃金分割點）。一個常用的經(jīng)驗是如果項目人員不懂技術(shù)的話，項目時間可能是原計劃（該計劃沒有考慮到資源可用率）的4/3－5/3。如果項目人員不懂技術(shù)、管理人員不懂管理的話，這個數(shù)字可能是2倍到3倍�，F(xiàn)實是這么嚴(yán)酷。這很大范圍內(nèi)"歸功于項目管理人員。是的，我們的確沒有必要責(zé)備開發(fā)人員，因為我們對資源可用率的判斷完全違反常識。

　　八、變化原則

　　也許有人問過你，在項目管理中不變的東西是什么？我可以告訴你，項目中不變的是"變化"。在項目中不考慮可能發(fā)生的變化是不可思議的。不過在面對項目可能發(fā)生變化而帶來的項目風(fēng)險時，我們的項目管理人員往往會懷有逃避的態(tài)度。經(jīng)濟(jì)學(xué)里大名鼎鼎的風(fēng)險規(guī)避原則便是項目管理人員心理的有效描述。作為項目管理人員來說，應(yīng)該及早預(yù)測可能出現(xiàn)的風(fēng)險，做好風(fēng)險儲備。雖然風(fēng)險儲備不能解決所有的問題，但預(yù)防勝于治療"�？上У氖俏覀兘^大多數(shù)人沒有這方面的意識，否則醫(yī)院的生意未必如此紅火，項目開發(fā)之途未必如此坎坷。

　　九、作業(yè)標(biāo)準(zhǔn)原則

　　一個團(tuán)隊要完成項目的開發(fā)需要有一定的章法。很可惜，在國內(nèi)目前仍然以"作坊式"為主，高舉"我們符合國際CMM X規(guī)范（ISO某某規(guī)范）"的環(huán)境下，未必有多少項目團(tuán)隊注意到這一點。我們曾經(jīng)驚嘆印度的高中生都能編程序，而國內(nèi)卻非本科、碩士不收眼簾。究其原因，在于沒有開發(fā)章法或是章法粗糙，猶如牛皮圣旨一般。一個好的代碼模板和代碼規(guī)范能夠解決大多數(shù)人編寫程序隨心所欲的問題，很可惜，沒有多少項目管理人員有此意識，也沒有多少人愿意去做這項基礎(chǔ)任務(wù)。業(yè)務(wù)軟件開發(fā)需要高超的開發(fā)技巧嗎？不需要，那是故弄玄虛的開發(fā)人員的伎倆。軟件開發(fā)的美在于其簡潔性和規(guī)范性，不在于奇技淫巧。因為缺乏作業(yè)標(biāo)準(zhǔn)，我們付出的代價是客戶的抱怨和無休止的返工。此外，對于那些以形式主意蒙人的項目團(tuán)隊來說，如果你實質(zhì)如同你口頭所說那樣，也許你不會是的這副狼狽相。

　　十、復(fù)用和組織變革原則－解決項目問題的未來之路

　　如何解決日益突出的項目工期、成本、質(zhì)量等問題，這是大多數(shù)項目管理者為關(guān)心的問題。從實踐來看加強(qiáng)復(fù)用的力度，建立項目復(fù)用體系和實施組織變革是效果較好的途徑之一。復(fù)用能夠提高項目的生產(chǎn)率，降低項目風(fēng)險。通過復(fù)用，項目管理者能夠快速的進(jìn)入項目問題定義之中，減少項目開發(fā)人員的工作量，從而盡可能的解決項目在時間、資源方面的過載問題。另外一條途徑是實施項目團(tuán)隊的組織變革（Moc），精簡項目管理機(jī)構(gòu)、重新定義工作職責(zé)，制定柔性的項目工作流程，改善項目開發(fā)人員的溝通狀況，提高項目人員的開發(fā)效率，努力營造一個良好的項目開發(fā)環(huán)境。這樣才能從根本上解決項目開發(fā)的種種棘手問題。

　　結(jié)論
　　
　　作為一個項目管理者來說，了解和運(yùn)用上述原則是不夠的，若要深入的掌握項目管理知識和技巧，還必須深入學(xué)習(xí)項目管理（建議參看PMI《PMBOK》）、管理心理學(xué)、質(zhì)量管理學(xué)、組織變革、系統(tǒng)論等方面的知識，并在工作中不斷的總結(jié)和實踐。唯有如此，我們的項目管理人員看自己個人簡歷時方不會覺得臉紅，才能在公司中樹立自己的管理權(quán)威性，同樣也才會有一個良好的職業(yè)經(jīng)理生涯的開端。