軟體開發的滑鐵盧-重大失控項目的經驗和教訓

【IT168 分析評論】

這本書是1997年10月由Prentice Hall出版社出版，2002年2月電子工業出版業引進的。作者Robert L.Glass是40年IT行業經驗的“老ITer”，從20世紀80年代開始，就專門收集和研究IT行業中那些知名的、重大“失控”項目，并努力從中抽 取一些規律和經驗，供同行參考。雖然書中研究和讨論的17個案例都發生在20世紀80年代中後期至1997年之間，從時間上看顯得有些“過時”，但是鑒于 國内跟美國之類的發達國家在工程學和軟體項目管理方面都還存在着巨大的差距，并且書中的項目都算得上一些“超大型”項目，相信國内絕大多數同行都沒有接觸 過，是以這本書在今天開來，仍然是非常非常有價值的。

不過，如果隻是在一些項目中做過開發工作，而沒有做過一些大型的、複雜的項目，也沒有嘗試去思考如何讓一個IT項目成功，甚至沒有切身的體會過完整的“IT行業”是一個什麼概念，那麼這本書就顯得有些太深了。

另 外，作者寫這本書的目的也并不是為了系統的講解IT項目管理，是以不能指望看過這本書後就能學會做項目；但是如果你已經有了一些項目管理的經驗，那麼倒是 很容易通過這本書來重新系統的總結和提升已有的知識和經驗，想想如果自己以後遇到類似的項目該怎麼辦，如何盡量避開這些問題和風險。

托爾斯泰說過，“幸福的家庭都相似,不幸的家庭各有各的不幸”，但IT項目剛好相反——成功的項目可能各有各的原因，但“失控”的項目，卻總是有些相似的問題。

在 本書中，作者引用了KPMG在1989年和1995年進行的兩次調查的報告，而兩份調查報告的核心，是對英國250家軟體企業的“失控”項目進行的統計、 分析和“失控根源”分類。根據KPMG的報告，這些項目最終“失控”的原因，歸咎于沒有指定完整的項目目标（特别是需求）、拙劣的計劃和評估、采用新技 術、缺乏或根本不具備項目管理方法、團隊中缺少資深人士、硬體/軟體供應商的低劣表現；而本書的作者在最後又附加了一條“系統無法滿足性能和可靠性要求 ”。下面就對這7大根源先做一個整理。

1. 沒有指定完整的項目目标

在KPMG的報告中，有51%的項目失控被認為與“沒有指定完整的項目目标”，而核心又是我們在IT項目中最常見的一個問題——需求。作者也列出了幾個常見的需求問題，包括：

1）需求過多，系統過于龐大：似乎注定了越龐大的項目需求就越複雜，也越容易失敗；

2）需求不穩定，使用者無法決定他們真正想要解決的問題；

3）需求模棱兩可

4）需求不完整

作者在書中也用占整本書1/3的篇幅講述了2個很典型的案例，來說明需求突然發生重大變更和項目目标定位過高導緻的“失控”案例。可如何做好需求管理，控制好需求變更，這在今天仍然是一個難題。

2. 拙劣的計劃和評估

在 這一節裡，作者提到的關鍵，是對項目的難度和工作量評估不準确，導緻項目的進度永遠達不到schedule的要求，并且被無限期的拖延下去。這的确是我們 在IT項目中遇到的第二個難題，似乎所有的項目的完成時間都要比預定計劃推後一些，雖然不能說一定是計劃和評估做的差導緻的——因為項目經理還要承擔着監 控和控制項目進度的職責——但在我們身邊的很多項目中，的确存在對項目難度和工作量估計不足，或缺少科學的度量方法的問題；而這又最終導緻我們在項目的初 期就已經處于“兩難境地”，并逐漸進入“死亡行軍”的狀态。（關于“兩難境地”和“死亡行軍”的論述，請參見“軟體開發的滑鐵盧——重大失控項目的經驗與教訓（之一） ”）。

3. 采用新技術

新 的技術、架構、平台、方法論、解決方案、術語縮寫的推出，相對于10年前（本書第一次出版的時候）越來越頻繁，而且貌似這些新東西更新換代的速度越來越 快，生命周期越來越短。曾經有做開發的朋友說自己很羨慕那些做C或者C++的人，因為可以“沉下去”，不受外界這些“新東西”的幹擾，積累下真正的技術和 經驗；相對來說，軟體測試也占有類似的優勢，畢竟我們現在所使用的方法和技術，大多也都是20年前或者10年前發明并流傳下來的——當然，那些沉迷于自動 化架構開發或者嘗試各種新工具的人會不同意我的看法。

新技術的采用，有時的确可以極大的提高生産率，并解決一些棘手的問題，幫助項目最終成 功。但是技術的選型就成了最大的問題，因為新東西推出的太快，而我們的IT行業中真正的技術專家、資深人士又總是少數，大多數ITer或者說開發人員，要 麼隻有2-3年的開發經驗，對核心技術和行業應用的把握能力有限；要麼迫于項目進度的壓力，很少有機會去深入的研究和實踐這些技術。

當然，還有另外一個關鍵的額問題，就是技術本身的成熟度問題——新技術是否已經被類似行業或者規模的項目檢驗過。

4. 缺乏或根本不具備項目管理方法

MSF（Microsoft Solution Framework，微軟解決方案架構）對于項目成功的關鍵，歸結于人、流程和技術的完美結合。技術，高價聘請外援可以解決的幹脆利索；流程，需要長期積 累，但總也是個相對穩定的“風險”；唯有人，或者說PM，是沒有辦法的，即使有一個優秀的團隊，也沒法把一個不稱職的PM變得稱職起來。而這個，反倒是在 萬事俱備後剩下的最大的風險。

5. 團隊中缺少資深人員

其實這個就不用多說了，就如比爾.蓋茨先生的那段話所說，“坦白地 說，微軟所面臨的挑戰之一是它的很多員工還沒有遭遇過多少失敗。很多人從未遇到過失敗的項目。結果是，人們把成功視為理所當然的事，這是很危險的。。。人 們遭遇失敗時，将被迫發揮出創造性，不分晝夜地深入探索并冥思苦想。每個公司都需要有過這種經曆的人。”

資深人員，就是那些經曆坎坷，被各種痛苦的“兩難境地”項目折磨過，從一次次“死亡行軍”中走過來，有着豐富的經驗，知道一個完整的IT項目需要經曆那些過程，能夠幫助項目盡早識别和規避風險，并解決各種突發事件的人。

6. 硬體/軟體供應商的低劣表現

這 條分類也是來源于KPMG的調查報告，作者說他手上并沒有這方面的案例。不過實際上，可以在本書的17個案例中看到一些端倪。特别是最近我所接觸的一些項 目，也越來越多的涉及到與外包商的合作——而這也是目前IT行業的趨勢。是以我會在今後的項目中留意這一類問題，也許在不久的将來就能有一些身邊的案例可 以拿出來讨論。

7. 系統無法滿足性能和可靠性要求

這一條是本書的作者加的，并不在KPMG的報告中。也許有人會說10年前 作者關心的那些性能問題，現在通過更好的硬體、網絡以及新的平台和技術都已經可以解決或避免了，已經不再需要擔心。可是我們也要看到，10年後的今天，計 算機系統所需要處理的業務和需求也在變得日益複雜，而開發人員卻并不是個個都關心系統性能的；最終，過于複雜、混亂而低效的代碼，仍将導緻性能、可靠性和 并發性問題。

在本書中，作者也提供了一個案例，講述了一個存在性能缺陷的系統，如何給使用者帶來巨大的損失，并險些使一家企業是以而倒閉。

另外，作者也提到了KPMG報告中一些有趣的結論。

·許多失控項目都是（或曾經是）“野心過大”的項目；

·失控項目可能有一個主要原因，但總是由多個原因導緻的；

·50%的項目在開發過程中顯示可能會失控，而25%的項目在初始的計劃階段就已經顯示出将來可能會失控；

·72%的失控項目，最初是由項目團隊成員發現的；而隻有19%的項目失控是最先有管理層意識到的；

·1989年隻有7%的企業認為技術問題是導緻項目失控的主要原因，但1995年這個數字上升到了45%；

·有55%的被調查項目根本沒有實行過任何風險管理，而38%的實行了風險管理的項目中，又有50%的項目在啟動後沒有識别到任何風險；

最後，作者結合自己對失控項目的研究和分析，又給出了另外3條結論。

·那些一開始就被牽涉到“政績”和某些其他的商業利益，并被大肆宣揚的項目，大多最終會失控——根據國内的經驗來看，這類項目常見的問題是項目目标定位模糊而經常發生變化，或者根本就沒有人關心項目真正的成敗與否；

·越來越多的系統要求用來處理實時互動操作，這導緻性能問題越來越成為影響項目的最終成功的問題；

·大型的涉及到複雜內建的行業應用，越來越容易成為失控的項目。