優(yōu)質(zhì)項目管理的四大要素是：選擇正確的人、為他們分配正確的工作、保持他們的積極性和幫助團隊凝聚起來并保持團隊的凝聚力。安全和變化的辯證關(guān)系在于：除非感到安全，否則人們就不能去迎接變化；在所有成功的工程中，變化都是基本的要素之一；安全感的缺乏會讓人們反對變化；人們可能會因為來自客觀世界的直接的恐嚇而覺得沒有安全感，但是如果察覺到管理者可能濫用權(quán)力來懲罰自己，他們也會覺得沒有安全感。風險控制方面，通過控制風險來管理項目；要為每個項目創(chuàng)建并維護風險統(tǒng)計表；跟蹤根源性的風險，而不只是最后那討厭的結(jié)果；建立簡單的(可能是匿名的)通道，讓壞消息能傳遞到高層?；蛘咴谠缙?，人員超編會迫使項目跨過關(guān)鍵的設(shè)計階段，如果在設(shè)計完成之前，工作先被分給了許多人，那么人與人之間、工作組之間的接口就會很復雜……
如果只是把這些管理箴言一一羅列，另外再舉幾個諸如微軟、寶潔、IBM等大公司的經(jīng)營事跡，那么這本書頂多就是目前我們常見的管理學暢銷書籍及勵志圖書，能成為暢銷但很難成為常銷?！蹲詈笃谙蕖藩毐脔鑿剑鳛橐槐卷椖抗芾硇≌f，它是以主人公被綁架開始的：湯普金斯先生，這位愛打瞌睡的資深項目經(jīng)理，是公司近期裁員的犧牲品，被綁架到一個完全陌生的國度，委以一項近乎不可能的任務，于是開始了一次奇異的、難以測度的冒險……這聽起來完全像一部卡夫卡式的荒誕小說。
這樣的開篇，或許您會說，這只是制造懸念、吸引讀者的套路而已?？墒恰皯夷睢痹局辉摪l(fā)生在那些存在風險、需要膽魄和運氣的領(lǐng)域：間諜或是反問諜、高空救險、買彩票等，哪里有懸念，哪里就有危險，就有失敗甚至喪命的可能。為什么軟件開發(fā)項目會卷入一場懸念、一次歷險之中?“最后期限”，英文原詞是“deadline”，直譯就是“死線”，據(jù)說原本指的是監(jiān)獄里的最后一道界限，犯人一旦越過就格殺勿論——難道作者是以此象征開發(fā)者們頭上懸著的劍?難道作者在暗示，軟件項目就很可能掙扎在這樣的生死界限上，很可能陷入“被劫持”的危險中?
據(jù)說，在軟件行業(yè)之外，“項目”往往意味著規(guī)范的運作，甚至是“成功”的同義語。請設(shè)想一個建筑項目。不考慮款項拖欠和成本回收，單純從設(shè)計、施工角度來說，“失敗”的可能性微乎其微。按此推測，軟件項目很少與有形的“物質(zhì)材料”打交道，成功的概率似乎會較建筑業(yè)更高。但是，任何略有經(jīng)驗的開發(fā)者都會明白我說的“風險”在軟件項目中意味著的比例。讓我們援引業(yè)界公認的“硬數(shù)據(jù)”：作為軟件項目管理權(quán)威，本書作者湯姆·迪馬克(Tom Demarco)在他的另一部名著《人件》中談到，他們“跟蹤研究的所有項目中，大約有15％的項目徹底失敗。在持續(xù)了25個工作年或者更長時間的項目中，足足有25％的項目沒能完成”。
由此，我們可以這么認為，軟件項目從本質(zhì)上來講，首先并且總是處于“危機四伏”的狀態(tài)中。面對如此高的風險，不少深謀遠慮的項目規(guī)劃者甚至會像書中的湯普金斯一樣，讓多個項目組同時開發(fā)同一模塊，取最優(yōu)的結(jié)果。但仍有很多不走運的軟件項目，要么對此沒有充分意識，要么無法負擔大量人力，所以其命運大都前仆后繼地被歸為失敗?；氐杰浖袠I(yè)，盡管有25％的失敗率，但是畢竟多數(shù)軟件項目確實還算得上走運。那么，成功的秘訣和失敗的主因各是什么?
在純技術(shù)領(lǐng)域，確實已有不少論著致力于這樣的工作。很多專家發(fā)現(xiàn)大家總在重復相同的錯誤，進而總結(jié)出了軟件設(shè)計中的一些典型錯誤思路，并把它們稱為“反模式”。而在軟件項目管理方面，如果也有這樣一部記錄成功的航線和沉船的位置的書該多好，我們不就也能據(jù)此把握航向、避開那些臭名昭著的礁石了嗎?筆者最初就是懷著這樣的念頭開始讀《最后期限》。這本書也確實能起到這樣的作用。伴隨著我們的朋友湯普金斯在虛構(gòu)的“摩羅維亞國”的歷險，我們從一個個機智美妙的故事中學到了不少“作為”與“不作為”——每章之后，都有一段以“湯普金斯日記”形式出現(xiàn)的總結(jié)，如果時間實在緊張，單單瀏覽一遍這些日記，就能在工作劃分、人員配備、項目時間計劃、測試、發(fā)布等問題上收獲很多真知灼見。
事實上，讀完全書后，筆者感到自己最大的收獲并非任何特定的管理秘訣，而恰恰是這樣一個認識：沒有任何單一的實踐或原則能夠確保一個軟件開發(fā)項目的成功，任何單一的缺陷也未必會將項目導向失敗。主人公湯普金斯的成功幾乎是不可復制的，因為決勝的因素縹緲而暖昧，并不能歸結(jié)于某一點兒魔術(shù)藥水式的“方法論”或某位天降神兵式的個人；同樣，我們也能看出，即使您身旁總有一位“邪惡的貝洛克部長”似的超級決策者，您的項目也不一定就單單因此而滿盤皆輸。這似乎是對《人月神話》中“沒有銀彈”原則的一次簡單擴充。這一個原則意味著特定情景下的多種因素處于一種動態(tài)、細微而又相互干涉的關(guān)系中，其中任何單個因素都不具有優(yōu)先性。因此，即使某個特定的項目中解決了某個困難，也無法保證從此我們就對它有了免疫力。
軟件項目的這種內(nèi)在的復雜性，也許同樣是其“奇異的魅力”之所在。如果軟件開發(fā)的藝術(shù)完全可以通過抽象的原則“線性地”掌握，那么我們甚至可以自問，會不會有一天軟件項目只由計算機自行開發(fā)，人類開發(fā)者完全被取代呢?而依據(jù)上面的討論，我們或許可以相信，軟件開發(fā)的困難所在，正是機器無法通過形式化的方式克服、而人類開發(fā)者最為擅長的部分。這是真正傾心于這項事業(yè)的人樂于看到的論證：要感謝這些困難，廣大軟件開發(fā)人員不會在某天早晨醒來發(fā)現(xiàn)，自己的職位已被一臺能干的計算機頂替了。
但是如果僅滿足于指認困難的內(nèi)在性，本書的建設(shè)性意義究竟何在呢?在筆者看來，軟件工程學中的“純技術(shù)部分”，尤其是系統(tǒng)構(gòu)架設(shè)計，往往是容易確定，并能夠通過教學、培訓加以掌握的(當然這里和其他自然科學一樣，仍需要悟性、實踐和創(chuàng)新意識)；而對于其他的內(nèi)容，特別是與開發(fā)的“商業(yè)”和“管理”環(huán)節(jié)對應的領(lǐng)域，雖然也包含高度的內(nèi)在嚴格性，但很難直截了當?shù)卣f明，更不容易通過簡單的教學而傳授。這些領(lǐng)域更多地與純粹技術(shù)之外的人類普遍經(jīng)驗相關(guān)，對它們的學習、培育，也許只能經(jīng)過實踐，經(jīng)過教化而緩慢、耐心地進行。于是，《最后期限》的意義在于它用有趣的故事情節(jié)、豐富的人物形象，告訴了我們許多深刻的管理智慧，以及能夠幫助我們滿足最后期限的實用建議。