軟件項目管理的九大方法

　　如何改善我們的軟件開(kāi)發(fā)管理，一條便捷之道便是"尊重常識，尊重歷史經(jīng)驗教訓"。在軟件項目管理中，有許多的原則和經(jīng)驗可以供我們借鑒。 下面是yjbys小編分享的一些相關(guān)資料，供大家參考。

　　一、計劃原則

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

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

　　二、Brooks原則

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

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

　　三、驗收標準原則

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

　　四、默認無(wú)效原則

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

　　五、80-20原則

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

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

　　六、帕金森原則

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

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

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

　　八、變化原則

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

　　九、作業(yè)標準原則

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

【軟件項目管理的九大方法】相關(guān)文章：

軟件測試與項目管理09-17

項目成本管理的方法09-02

項目管理方法09-15

關(guān)于軟件項目管理的建議08-18

軟件項目設計過(guò)程的管理10-09

軟件項目的溝通管理08-11

項目管理方法和項目實(shí)施方法的關(guān)系04-19

項目管理團隊的管理方法07-17

項目時(shí)間管理的方法10-20

項目管理的具體原理與方法09-01