軟體項目失敗的五大原因

現狀

        美國的研究者分析了大量軟體開發項目的資料之後，告訴我們，任何時候這個世界上都有超過50%的軟體開發項目正在步向失敗。實際上我記憶中最近看到的確切資料是73%的項目最後都是失敗的，失敗意味著最終提交的系統要麼在滿足市場需求上已經失效，要麼在時間和金錢投入上都大大超過了最初的預計，這還沒有包括由於某些原因而被迫中止的項目。

        連軟體開發領域處於世界最前沿的美國都如此，其它地方的情況可想而知；也許這正是為什麼軟體開發專案管理會成為一門專門的學問之原因。

原因

        言歸正傳，也許我們可以從他人的教訓中吸取一些經驗教訓，以下幾點原因是在一些軟體工程著作中經常被提起的項目失敗原因，它們大多都在我的工作經驗中得到驗證，在此分享給各位，以此作為警戒：

• 不切實際的時間安排

        《期限》這本書，也許是項目干係人都應該看看的書，書裡面對這條導致項目失敗的原因進行了淋漓盡致的刻畫和描寫，遺憾的是這類項目依然隨處可見。幾乎在每本介紹軟體開發的書中，作者都能舉出失敗的例子來證明由外界壓力強加在Team Dev頭上的Deadline會對項目造成什麼樣的傷害，也許在商界，指定一個期限是打不破的定律。

        制定Deadline本身沒有錯，也是必要的，關鍵在於Deadline是否切合實際，切合實際的Deadline不是他人憑空捏造出來的，應該是Team Dev經過仔細評估之後做出的承諾。

• 不恰當的人員配置

        這一條也幾乎是每本講軟體開發專案管理的書必提到的內容，包括了很多種情況：比如人手配備不夠，人員配置混亂，指定了不合適的專案經理，在關鍵時刻加入人手卻指望他們能夠立刻發揮作用，etc.

        軟體開發最經典的2本著作《人件》和《人月神話》早就告訴我們，“人-People”才是軟體開發裡面最關鍵的因素，而很多決策者卻喜歡一定程度上忽略這個事實，這個也沒什麼好說的，我最近的一條體會是：你用什麼樣的人去做這個事情，往往已經決定了你會取得什麼樣的結果，能否取得事先設想的結果，取決於完成工作的“人”以及他們之間的互動關係。

• 破壞性的需求改變

        需求管理已經成了專案管理的必修課之一，這個沒什麼好質疑的，一個項目存在的理由就是為了滿足某種需求；

這裡要強調的是，需求的隨意更改，對項目必然會造成不好的影響，來自客戶的需求如果隨意發生變化，軟體的設計和實現就要不斷地被改動，這是需要時間和金錢代價的；來自Team Dev自身的需求更改，可以造成更大的問題，即提交出來的東西是客戶不需要的。

        需求不是不能更改，是不要隨意更改，要在控制下更改，或者是有一個良好的變更程式來需求的變化不會對項目造成破壞性的影響。

• 低質的工作

        如果迫於某種壓力生產了一個低品質的軟體產品，後期的處理客戶投訴、改錯、測試等工作會蠶食掉你獲得的利潤，會讓你付出更大的代價；已經有很多很多軟體公司在這點上倒下了，以後還會有很多很多的後來人繼續栽跟頭；

        讓我想起了一句話“惡有惡報，善有善報，不是不報，時間未到”。在開發階段，若縮減了必要的品質保證工作，就好像欠下了一筆債，遲早是要還的，買單者可能會是不同的人，但必然還是這同一個公司；在一開始就把品質保證好是成本最低的做法，修複同一個缺陷，越到後面就越需要付出更多的代價。

• 相信奇蹟

        自然界可能是真的有奇蹟，我們應該相信；然而聚集一群人一起做軟體開發這件事情上，有的只是人們的付出產生的結果，連“銀彈”都不會有，怎麼會有奇蹟呢？然而依然有不少人“相信”有奇蹟：譬如期望在混亂無序的團隊中產出高品質的成果；期望在不可能實現的交付日成功交付產品；比如希望在沒有品質控制措施的情況下得到很高品質的產品；

        在軟體產品開發這件事情上，真的是一分耕耘，一分收穫，不存在所謂的奇蹟，需求分析的時候沒有對需求進行良好的管理，最終提交的時候客戶一定會提出問題；設計的時候沒有考慮效能問題，測試時你必將遇到效能上的限制；實現一個功能的時候沒有做好品質控制，最終整合的時候一定會暴漏很多缺陷；所以只有報著踏踏實實的態度才是成功完成項目的王道。