這本書是2023年10月由prentice hall出版社出版，2023年2月電子工業出版業引進的。作者robert l.glass是40年it行業經驗的「老iter」，從20世紀80年代開始，就專門收集和研究it行業中那些知名的、重大「失控」專案，並努力從中抽 取一些規律和經驗，供同行參考。雖然書中研究和討論的17個案例都發生在20世紀80年代中後期至2023年之間，從時間上看顯得有些「過時」，但是鑑於 國內跟美國之類的發達國家在工程學和軟體專案管理方面都還存在著巨大的差距，並且書中的專案都算得上一些「超大型」專案，相信國內絕大多數同行都沒有接觸 過，所以這本書在今天開來，仍然是非常非常有價值的。
不過，如果只是在一些專案中做過開發工作，而沒有做過一些大型的、複雜的專案，也沒有嘗試去思考如何讓乙個it專案成功，甚至沒有切身的體會過完整的「it行業」是乙個什麼概念，那麼這本書就顯得有些太深了。
另 外，作者寫這本書的目的也並不是為了系統的講解it專案管理，所以不能指望看過這本書後就能學會做專案；但是如果你已經有了一些專案管理的經驗，那麼倒是 很容易通過這本書來重新系統的總結和提公升已有的知識和經驗，想想如果自己以後遇到類似的專案該怎麼辦，如何盡量避開這些問題和風險。
托爾斯泰說過，「幸福的家庭都相似,不幸的家庭各有各的不幸」，但it專案剛好相反——成功的專案可能各有各的原因，但「失控」的專案，卻總是有些相似的問題。
在 本書中，作者引用了kpmg在2023年和2023年進行的兩次調查的報告，而兩份調查報告的核心，是對英國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%的專案失控是最先有管理層意識到的；
·2023年只有7%的企業認為技術問題是導致專案失控的主要原因，但2023年這個數字上公升到了45%；
·有55%的被調查專案根本沒有實行過任何風險管理，而38%的實行了風險管理的專案中，又有50%的專案在啟動後沒有識別到任何風險；
最後，作者結合自己對失控專案的研究和分析，又給出了另外3條結論。
·那些一開始就被牽涉到「政績」和某些其他的商業利益，並被大肆宣揚的專案，大多最終會失控——根據國內的經驗來看，這類專案常見的問題是專案目標定位模糊而經常發生變化，或者根本就沒有人關心專案真正的成敗與否；
·越來越多的系統要求用來處理實時互動操作，這導致效能問題越來越成為影響專案的最終成功的問題；
·大型的涉及到複雜整合的行業應用，越來越容易成為失控的專案。
專案開發流程 你知道軟體開發專案的管理流程嗎？
做軟體專案就是把使用者的要求轉化成需求，然後需求轉化成設計，然後設計轉化成 總的來說，就是把大的專案劃分成小的專案，大的模組劃分成小的模組。任何專案都是這樣做的需求和設計，尤其是大的專案，總是要劃分成小的模組，這樣能讓專案的不同參與者負責各自的模組，然後再整合起來進行測試。軟體專案的整個流程 一 專...
軟體開發專案流程
當我們發現市場上有乙個專案有利可圖，且我們有能力做的時候，發起的一次專案可行性 關於立項，我們根據自己公司的情況來下定義，因為大的網際網路公司都有比較正規的立項流程，我們這裡不做介紹。這裡我們主要介紹關於中小型公司，沒有特別標準的流程的公司。根據專案整合管理工程師的教課資料，總結以下階段 專案建議書...
安排乙個簡單的軟體開發專案的進度
1 建立初步的工程網路圖 2 計算每個事件的最早發生時刻 eet 和最遲發生時刻 let 並在工程網路圖中標明。3 確定並標出關鍵路徑。4 計算非關鍵作業的機動時間，並在工程網路圖中標出。5 在時間和資源的約束下，利用機動時間安排進度。在安排進度時，必須先保證關鍵作業得到滿足，然後，利用機動時間安排...