細(xì)數(shù)軟件項(xiàng)目失敗的五大原因
現(xiàn)狀
美國(guó)的研究者分析了大量軟件開發(fā)項(xiàng)目的數(shù)據(jù)之后，告訴我們，任何時(shí)候這個(gè)世界上都有超過(guò)50%的軟件開發(fā)項(xiàng)目正在步向失敗。實(shí)際上我記憶中最近看到的確切數(shù)據(jù)是73%的項(xiàng)目***都是失敗的，失敗意味著最終提交的系統(tǒng)要么在滿足市場(chǎng)需求上已經(jīng)失效，要么在時(shí)間和金錢投入上都大大超過(guò)了最初的預(yù)計(jì)，這還沒(méi)有包括由于某些原因而被迫中止的項(xiàng)目。
連軟件開發(fā)領(lǐng)域處于世界最前沿的美國(guó)都如此，其它地方的情況可想而知；也許這正是為什么軟件開發(fā)項(xiàng)目管理會(huì)成為一門專門的學(xué)問(wèn)之原因。
原因
言歸正傳，也許我們可以從他人的教訓(xùn)中吸取一些經(jīng)驗(yàn)教訓(xùn)，以下幾點(diǎn)原因是在一些軟件工程著作中經(jīng)常被提起的項(xiàng)目失敗原因，它們大多都在我的工作經(jīng)驗(yàn)中得到驗(yàn)證，在此分享給各位，以此作為警戒：
不切實(shí)際的時(shí)間安排
《***期限》這本書，也許是項(xiàng)目干系人都應(yīng)該看看的書，書里面對(duì)這條導(dǎo)致項(xiàng)目失敗的原因進(jìn)行了***的刻畫和描寫，遺憾的是這類項(xiàng)目依然隨處可見。幾乎在每本介紹軟件開發(fā)的書中，作者都能舉出失敗的例子來(lái)證明由外界壓力強(qiáng)加在開發(fā)團(tuán)隊(duì)頭上的Deadline會(huì)對(duì)項(xiàng)目造成什么樣的傷害，也許在商界，指定一個(gè)***期限是打不破的定律。
制定Deadline本身沒(méi)有錯(cuò)，也是必要的，關(guān)鍵在于Deadline是否切合實(shí)際，切合實(shí)際的Deadline不是他人憑空捏造出來(lái)的，應(yīng)該是開發(fā)團(tuán)隊(duì)經(jīng)過(guò)仔細(xì)評(píng)估之后做出的承諾。
不恰當(dāng)?shù)娜藛T配置
這一條也幾乎是每本講軟件開發(fā)項(xiàng)目管理的書必提到的內(nèi)容，包括了很多種情況：比如人手配備不夠，人員配置混亂，指定了不合適的項(xiàng)目經(jīng)理，在關(guān)鍵時(shí)刻加入人手卻指望他們能夠立刻發(fā)揮作用，etc.
軟件開發(fā)最經(jīng)典的2本著作《人件》和《人月神話》早就告訴我們，“人-People”才是軟件開發(fā)里面最關(guān)鍵的因素，而很多決策者卻喜歡一定程度上忽略這個(gè)事實(shí)，這個(gè)也沒(méi)什么好說(shuō)的，我最近的一條體會(huì)是：你用什么樣的人去做這個(gè)事情，往往已經(jīng)決定了你會(huì)取得什么樣的結(jié)果，能否取得事先設(shè)想的結(jié)果，取決于完成工作的“人”以及他們之間的互動(dòng)關(guān)系。
破壞性的需求改變
需求管理已經(jīng)成了項(xiàng)目管理的必修課之一，這個(gè)沒(méi)什么好質(zhì)疑的，一個(gè)項(xiàng)目存在的理由就是為了滿足某種需求；
這里要強(qiáng)調(diào)的是，需求的隨意更改，對(duì)項(xiàng)目必然會(huì)造成不好的影響，來(lái)自客戶的需求如果隨意發(fā)生變化，軟件的設(shè)計(jì)和實(shí)現(xiàn)就要不斷地被改動(dòng)，這是需要時(shí)間和金錢代價(jià)的；來(lái)自開發(fā)團(tuán)隊(duì)自身的需求更改，可以造成更大的問(wèn)題，即提交出來(lái)的東西是客戶不需要的。
需求不是不能更改，是不要隨意更改，要在控制下更改，或者是有一個(gè)良好的變更程序來(lái)需求的變化不會(huì)對(duì)項(xiàng)目造成破壞性的影響。
低質(zhì)的工作
如果迫于某種壓力生產(chǎn)了一個(gè)低質(zhì)量的軟件產(chǎn)品，后期的處理客戶投訴、改錯(cuò)、測(cè)試等工作會(huì)蠶食掉你獲得的利潤(rùn)，會(huì)讓你付出更大的代價(jià)；已經(jīng)有很多很多軟件公司在這點(diǎn)上倒下了，以后還會(huì)有很多很多的后來(lái)人繼續(xù)栽跟頭；
讓我想起了一句話“惡有惡報(bào)，善有善報(bào)，不是不報(bào)，時(shí)間未到”。在開發(fā)階段，若縮減了必要的質(zhì)量保證工作，就好像欠下了一筆債，遲早是要還的，買單者可能會(huì)是不同的人，但必然還是這同一個(gè)公司；在一開始就把質(zhì)量保證好是成本***的做法，修復(fù)同一個(gè)缺陷，越到后面就越需要付出更多的代價(jià)。
相信奇跡
自然界可能是真的有奇跡，我們應(yīng)該相信；然而聚集一群人一起做軟件開發(fā)這件事情上，有的只是人們的付出產(chǎn)生的結(jié)果，連“銀彈”都不會(huì)有，怎么會(huì)有奇跡呢？然而依然有不少人“相信”有奇跡：譬如期望在混亂無(wú)序的團(tuán)隊(duì)中產(chǎn)出高質(zhì)量的成果；期望在不可能實(shí)現(xiàn)的交付日成功交付產(chǎn)品；比如希望在沒(méi)有質(zhì)量控制措施的情況下得到很高質(zhì)量的產(chǎn)品；
在軟件產(chǎn)品開發(fā)這件事情上，真的是一分耕耘，一分收獲，不存在所謂的奇跡，需求分析的時(shí)候沒(méi)有對(duì)需求進(jìn)行良好的管理，最終提交的時(shí)候客戶一定會(huì)提出問(wèn)題；設(shè)計(jì)的時(shí)候沒(méi)有考慮性能問(wèn)題，測(cè)試時(shí)你必將遇到性能上的限制；實(shí)現(xiàn)一個(gè)功能的時(shí)候沒(méi)有做好質(zhì)量控制，最終整合的時(shí)候一定會(huì)暴漏很多缺陷；所以只有報(bào)著踏踏實(shí)實(shí)的態(tài)度才是成功完成項(xiàng)目的王道。
原文鏈接：http://www.cnblogs.com/cavenran/archive/2011/06/05/2073094.html
【編輯推薦】
