反思自己歷年來經(jīng)歷過的大大小小的成功或失敗的項目，在做一個項目時，我們應(yīng)該思考一下：
1、該項目的目標(biāo)或需求明確、完整、可行嗎？
2、項目計劃是否根據(jù)實際情況而制定，計劃是否可行？
3、團隊對采用的新技術(shù)、框架、平臺是否掌握好了？
4、是否有項目管理方案？項目管理方案適合項目的實際情況嗎？
5、項目組是否存在核心的資深人員？
6、是否有進行性能評估？

如文章所講：我們要盡力避免“兩難境地”、“死亡行軍”和“失控”的項目！

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

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

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

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

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

1. 沒有指定完整的項目目標(biāo)

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

1）需求過多，系統(tǒng)過于龐大：似乎注定了越龐大的項目需求就越復(fù)雜，也越容易失?。?/p>

2）需求不穩(wěn)定，用戶無法決定他們真正想要解決的問題；

3）需求模棱兩可

4）需求不完整

作者在書中也用占整本書1/3的篇幅講述了2個很典型的案例，來說明需求突然發(fā)生重大變更和項目目標(biāo)定位過高導(dǎo)致的“失控”案例?？扇绾巫龊眯枨蠊芾?，控制好需求變更，這在今天仍然是一個難題。

2. 拙劣的計劃和評估

在這一節(jié)里，作者提到的關(guān)鍵，是對項目的難度和工作量評估不準(zhǔn)確，導(dǎo)致項目的進度永遠達不到schedule的要求，并且被無限期的拖延下去。這的確是我們在IT項目中遇到的第二個難題，似乎所有的項目的完成時間都要比預(yù)定計劃推后一些，雖然不能說一定是計劃和評估做的差導(dǎo)致的——因為項目經(jīng)理還要承擔(dān)著監(jiān)控和控制項目進度的職責(zé)——但在我們身邊的很多項目中，的確存在對項目難度和工作量估計不足，或缺少科學(xué)的度量方法的問題；而這又最終導(dǎo)致我們在項目的初期就已經(jīng)處于“兩難境地”，并逐漸進入“死亡行軍”的狀態(tài)。（關(guān)于“兩難境地”和“死亡行軍”的論述，請參見“軟件開發(fā)的滑鐵盧——重大失控項目的經(jīng)驗與教訓(xùn)（之一） ”）。

3. 采用新技術(shù)

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

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

當(dāng)然，還有另外一個關(guān)鍵的額問題，就是技術(shù)本身的成熟度問題——新技術(shù)是否已經(jīng)被類似行業(yè)或者規(guī)模的項目檢驗過。

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

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

5. 團隊中缺少資深人員

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

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

6. 硬件/軟件供應(yīng)商的低劣表現(xiàn)

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

7. 系統(tǒng)無法滿足性能和可靠性要求

這一條是本書的作者加的，并不在KPMG的報告中。也許有人會說10年前作者關(guān)心的那些性能問題，現(xiàn)在通過更好的硬件、網(wǎng)絡(luò)以及新的平臺和技術(shù)都已經(jīng)可以解決或避免了，已經(jīng)不再需要擔(dān)心。可是我們也要看到，10年后的今天，計算機系統(tǒng)所需要處理的業(yè)務(wù)和需求也在變得日益復(fù)雜，而開發(fā)人員卻并不是個個都關(guān)心系統(tǒng)性能的；最終，過于復(fù)雜、混亂而低效的代碼，仍將導(dǎo)致性能、可靠性和并發(fā)性問題。

在本書中，作者也提供了一個案例，講述了一個存在性能缺陷的系統(tǒng)，如何給用戶帶來巨大的損失，并險些使一家企業(yè)因此而倒閉。

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

·許多失控項目都是（或曾經(jīng)是）“野心過大”的項目；
·失控項目可能有一個主要原因，但總是由多個原因?qū)е碌模?
·50%的項目在開發(fā)過程中顯示可能會失控，而25%的項目在初始的計劃階段就已經(jīng)顯示出將來可能會失控；
·72%的失控項目，最初是由項目團隊成員發(fā)現(xiàn)的；而只有19%的項目失控是最先有管理層意識到的；
·1989年只有7%的企業(yè)認為技術(shù)問題是導(dǎo)致項目失控的主要原因，但1995年這個數(shù)字上升到了45%；
·有55%的被調(diào)查項目根本沒有實行過任何風(fēng)險管理，而38%的實行了風(fēng)險管理的項目中，又有50%的項目在啟動后沒有識別到任何風(fēng)險；

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

·那些一開始就被牽涉到“政績”和某些其他的商業(yè)利益，并被大肆宣揚的項目，大多最終會失控——根據(jù)國內(nèi)的經(jīng)驗來看，這類項目常見的問題是項目目標(biāo)定位模糊而經(jīng)常發(fā)生變化，或者根本就沒有人關(guān)心項目真正的成敗與否；
·越來越多的系統(tǒng)要求用來處理實時交互操作，這導(dǎo)致性能問題越來越成為影響項目的最終成功的問題；
·大型的涉及到復(fù)雜集成的行業(yè)應(yīng)用，越來越容易成為失控的項目。