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