探析軟件項(xiàng)目管理九大原則

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

　　軟件開發(fā)的殘酷的現(xiàn)實(shí)告訴我們：沒有規(guī)則的軟件開發(fā)過程帶來的只可能是無法預(yù)料的結(jié)果。我們中的大多數(shù)項(xiàng)目管理人員在其個(gè)人簡(jiǎn)歷中紛紛寫到："擁有多年的豐富的項(xiàng)目管理經(jīng)驗(yàn)"，但在實(shí)際開發(fā)中，"豐富的"管理經(jīng)驗(yàn)變成了軟件開發(fā)人員可怕的夢(mèng)魘。一次次的失敗、一次次的返工，她所謂的項(xiàng)目管理經(jīng)驗(yàn)只不過是再一次的游戲于"無間"（十八層地獄）。一次，在與不少項(xiàng)目管理者的交流中，大家紛紛提到的軟件變更帶來的可怕影響。

　　但是正如完整的法律體制不能制止犯罪，但沒有完整的法律體制犯罪會(huì)更加猖獗一樣，頻繁的軟件變更固然可怕，但是沒有一個(gè)完整的項(xiàng)目管理對(duì)應(yīng)機(jī)制，我們無法相像項(xiàng)目最終會(huì)是一個(gè)什么樣子。此外還有一次，筆者在求職時(shí)，招聘公司的技術(shù)主管（40-50歲左右），向我吹噓公司按CMM4的過程規(guī)則來進(jìn)行軟件的開發(fā)和管理。殊不知，我一問下面開發(fā)人員，她們?cè)诮?jīng)歷無數(shù)的加班后正在給已經(jīng)完成的軟件項(xiàng)目添加軟件概要設(shè)計(jì)書，這讓我大吃一驚。如此這樣形式主義的公司，不呆也罷。

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

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

　　一、計(jì)劃原則

　　沒有計(jì)劃，你無從知道什么時(shí)候控制和變更。制定一個(gè)詳盡的計(jì)劃，以詳細(xì)到開發(fā)人員可以理解的程度為宜。計(jì)劃能夠告訴你什么時(shí)候應(yīng)該做什么。沒有計(jì)劃，你無從知道自己需要做什么。不少項(xiàng)目經(jīng)理告訴組員需要做什么東西后揚(yáng)長而去，絲毫沒有一個(gè)相關(guān)任務(wù)（活動(dòng)）之間的說明。由于沒有計(jì)劃或是計(jì)劃太粗糙、不切實(shí)際，很多項(xiàng)目1/3甚至1/2的時(shí)間花在返工上面。因?yàn)橛?jì)劃中遺漏了某一項(xiàng)關(guān)鍵任務(wù)，項(xiàng)目就有可能宣告失敗。

　　試想一下，制定一個(gè)周密合理的計(jì)劃需要耗費(fèi)這么多的時(shí)間嗎？需要付出項(xiàng)目失敗的代價(jià)嗎？還有很多項(xiàng)目管理人員常常錯(cuò)誤認(rèn)為"變化比計(jì)劃快"，但實(shí)際的情況是，由于沒有計(jì)劃，你無法預(yù)測(cè)和估量變化給你的項(xiàng)目所帶來影響，你所面臨的將會(huì)是比面條還難以理清？混沌"狀態(tài)。此外，對(duì)于開發(fā)人員來說，"目標(biāo)導(dǎo)向（Objective Oriented）"是充分調(diào)動(dòng)其工作積極性的最佳方法，每一個(gè)任務(wù)階段的成果能夠?qū)T工的工作效率維持在一個(gè)較高的水平。因?yàn)榻谀繕?biāo)總是比遠(yuǎn)期目標(biāo)來說更容易看到和達(dá)到。為此，制定一個(gè)計(jì)劃吧，讓它符合目標(biāo)導(dǎo)向（通過各個(gè)具體任務(wù)計(jì)劃促使項(xiàng)目總計(jì)劃的達(dá)成）。

　　二、Brooks原則

　　向一個(gè)已經(jīng)滯后的項(xiàng)目添加人員，可能會(huì)使項(xiàng)目更加滯后。因?yàn)樽鳛樾录尤氲膯T工來說，相關(guān)培訓(xùn)、環(huán)境熟悉和人員之間的溝通通路的增加，迫使項(xiàng)目的工作效率急劇下跌。工作效率下降需要加班來進(jìn)行彌補(bǔ)，但加班造成的疲勞會(huì)再次使工作效率降低。同時(shí)工作成本卻不斷的向上攀升。不過就目前來說，項(xiàng)目管理人員絲毫不會(huì)理會(huì)這一點(diǎn)，"人多力量大"也許更能引人入勝。不少項(xiàng)目管理人員抱怨到時(shí)間的急迫性，須知很多項(xiàng)目內(nèi)時(shí)間的急迫性來自于項(xiàng)目管理人員不假思索和不基于常理的邀功表現(xiàn)，沒有充分考慮的開發(fā)人員能力的多樣性

　　所致。為此，正規(guī)的企業(yè)不得不耗費(fèi)大量的加班費(fèi)用于加班人員的津貼，同時(shí)亦要承擔(dān)違反《勞動(dòng)法》的潛在法律危險(xiǎn)?，F(xiàn)在一種萬不得已的做法是，假設(shè)項(xiàng)目開發(fā)人員之間的任務(wù)的關(guān)聯(lián)性不是太大的情況下，采取兩班倒或是三班倒的方法來保證時(shí)間的延續(xù)性和相關(guān)開發(fā)人員的工作高效性。

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

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

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

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

　　五、80-20原則

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

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

　　六、帕金森原則

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

　　七、時(shí)間分配原則

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

　　八、變化原則

　　也許有人問過你，在項(xiàng)目管理中唯一不變的東西是什么？我可以告訴你，項(xiàng)目中唯一不變的就是"變化".在項(xiàng)目中不考慮可能發(fā)生的變化是不可思議的。不過在面對(duì)項(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ù)測(cè)可能出現(xiàn)的風(fēng)險(xiǎn)，做好風(fēng)險(xiǎn)儲(chǔ)備。雖然風(fēng)險(xiǎn)儲(chǔ)備不能解決所有的問題，但預(yù)防勝于治療".可惜的是我們絕大多數(shù)人沒有這方面的意識(shí)，否則醫(yī)院的生意未必如此紅火，項(xiàng)目開發(fā)之途未必如此坎坷。

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

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

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

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

　　結(jié)論

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