死亡之旅（第2版）:基本信息,編輯推薦,目錄,譯者序,前言,

《死亡之旅（第2版）》一書對各種“死亡之旅”項目進行了全面而系統的剖析，涵蓋整個項目的生命周期，深刻分析了這種現象的本質，並討論項目參與者所面臨的所有關鍵問題：政治、談判、人員、過程、項目管理，以及工具，提供了行之有效的解決方法和行動指南。本書不但有助於快速識別死亡之旅項目，而且能夠大大提高從死亡之旅中生還的機率。無論是軟體開發人員、管理人員，乃至各行各業的項目經理、cxo，都能從本書受到啟發，並找到現實而適用的解決方案。

基本介紹

書名：死亡之旅（第2版）
作者：(美)Edward Yourdon
ISBN：9787111359982
出版社：機械工業出版社
出版時間：2012 年1月
開本：16

基本信息,編輯推薦,目錄,譯者序,前言,

基本信息

書名：死亡之旅（第2版）

譯者：周浩宇楊華

上架時間：2011-11-8

頁碼：1

版次：2-1

編輯推薦

本書第2版包含的全新內容和相關內容更新如下：

·將死亡之旅項目轉化為“不可能完成的任務”類型項目

·項目狀態談判：在惡劣環境中得到最佳結果

·極限編程（XP）、敏捷方法與死亡之旅項目

·團隊時間管理：消除導致項目脫軌的干擾因素

·“關鍵鏈進度計畫排定”：識別和消除組織故障

·預測“壓垮駱駝的最後一根稻草”：系統動力學的教訓

·如何根據自身環境選擇最可能有效的工具和方法

·項目“飛行模擬器”：演習你的下一個項目

·通過“選擇”交付最重要的功能和特性

·何時應該“放手離去”

譯者序

古語云：“溫故而知新。”6年之後，再次為機械工業出版社重譯《Death March,Second Edition》，老友重逢般的親切固然在意料之中，但令人驚訝的是這次重譯居然給我帶來了那么多全新的感悟。

從2001年接手翻譯第1版到現在，十年光陰已經悄然而逝，雖然新技術、新方法層出不窮，但死亡之旅的項目現象卻並未得到遏制。它不但在軟體行業愈演愈烈，而且大有蔓延至各個傳統行業的趨勢。情況正如6年前首譯第2版時序言中我所指出的那樣：各個行業、各種組織、每個項目都越來越向著死亡之旅發展。

在這樣的環境中，如何在到達死亡的終點前採取恰當的措施，讓項目不但能夠起死回生，而且獲得良好的效果，必將是所有項目人員首先要思考的問題。然而，對付死亡之旅，大多數人僅僅靠經驗和嘗試，往往缺乏系統的思路，這不但導致失敗的可能性大增，而且錯失了很多發展的良機。

本書具有如下特點：

獨創性：雖然本書也強調各種工具和方法的使用，但絕非面向教科書式的規範項目，而是著重結合死亡之旅項目的特點進行分析；

實用性：本書結合大量項目實際，其中的定義、分析、系統應對思路密切結合實際，對於日趨“水深火熱”的項目人員具有極強的參考作用；

系統性：本書不但結合死亡之旅項目探討如何使用“XP”、“敏捷方法”等諸多焦點技術來提高成功率，而且從進度、風險、項目跟蹤控制等多方面對死亡之旅項目給出了系統的解決方案，從而使本書成為軟體項目人員必備的案頭指南；

可行性：本書給出的分析和解決方案都得自於眾多實際項目的經驗教訓和實際驗證，與其他書籍中的理論方法相比，具有極強的可行性。

雖然本書被歸類於軟體管理，但近十幾年來，每每為不同行業客戶進行管理諮詢、培訓時提起死亡之旅概念，我發現大家的反應幾乎高度一致：“哇，那就是我的項目！”雖然各個行業的內容不同，但所面臨的各種死亡之旅的原因和解決思路並沒有本質的區別。因此，本書不但可以用於軟體行業，撇開軟體專業技術內容，它也同樣可以為其他行業的項目人員提供解決問題的系統思路。

隨著經濟發展和市場競爭的加劇，可以預計，每個項目最終都將具有死亡之旅的特點。如何成功走過自己的“死亡之旅”，必將是每個項目人員都將面臨的問題。因此，無論是對於初涉這個領域的菜鳥，還是對於那些“飽經摧殘”的資深人士，本書都將具有重要的參考意義。

作為國內權威出版機構之一，機械工業出版社一直致力於引進國外優秀的管理書籍。重新出版本書，就是機械工業出版社華章公司的獨具慧眼之舉。我相信，本書的重譯不但會大大助力軟體行業項目管理，而且對各行業項目管理人員的實際水平的提升也將大有裨益。

本書的翻譯和出版歸功於一個團結的團隊。周浩宇負責本書的主要翻譯，楊華、周榮花負責本書的審校。周皓靜、劉紅傑參與翻譯了第1、2、3章，楊芳、陳友林參與翻譯了第4、5、6章中的部分內容，楊穎、楊鐵生、姜鳳芝參與翻譯了第9、10章中的部分內容。感謝本書的責任編輯盛思源，她對本書的編輯和出版提出了很多建設性的意見。此外，本書的出版也離不開陳冀康編輯的付出，如果沒有他的辛勤工作，本書也不可能以如此快的速度面世。

周浩宇

2011年8月於上海

前言

成功無需贅述，但我們必須查清自己的失敗、挫折和疑問。人們很容易忘記以往的困境、錯誤開端和痛苦摸索。我們總把過去的成功歸功於一往無前的決心，而把當前的困境歸咎於這種決心的消逝和減弱。——Eric Hoffer

《Reflection on the Human Condition》（反思人類生存條件）

Aph. 157 (1973)

我知道：你一定是被本書的名字所吸引，因此才決定看一看它到底是什麼內容。但是你實在是太忙了，根本無法確定自己是否能夠抽出時間再看一本關於軟體項目管理的書，更何況它又是在告訴你理想世界裡的做事方法——理智的人會針對項目的預算、進度和資源做出冷靜和明智的決策。

然而，你很可能已經注意到，我們並不是生活在理想世界中，而且事實往往還恰恰相反，雖然有些人毫無理智，所做的決定一點都不冷靜和明智，但因為項目我們也不得不同他們打交道。換句話說，你正在為一個死亡之旅項目工作。本書如此命名有一個巨大的優點：我甚至無需對它進行任何解釋。每當我向同事和朋友提起這個名稱時，他們都帶著會心的微笑說：“噢，沒錯，你一定是在說我的項目。”現在，它既有可能是我的項目，也很可能是你和其他任何人的項目——我們都正在為各種死亡之旅項目工作，至少看起來是這樣。

在這種情況下，你首先應該就以下問題問問自己（儘管你往往在項目結束時才會這么做）：“究竟是什麼原因讓我陷入這樣的項目之中？”我將在第1章中首先討論這個問題，這是因為根據自己作為諮詢顧問（作為局外人研究和觀察了大量此種項目）的經驗，我知道,如果更多的人敢於站出來說：“該死，不，我不參加這個死亡之旅！”世界的發展將會更加健康。

但是，假設你無法避免參與這種項目（比如，由於沒有其他工作可做，或者由於和僱主之間存在著某種形式的“金手銬”關係，從而導致無法離開），此時你就面臨下一個問題：“我如何才能挺過這個項目並且無損於自己的健康、理智和尊嚴？”如果你是樂天派，或許你還會考慮如何克服自己所面臨的障礙從而以低於預算的成本準時完成項目。但如果你業已經歷過大量這種類型的項目，你很可能已經很清楚成功的機會微乎其微，能夠挺過去已經是最好的結果。

在軟體業30多年的工作中，我發現這個行業的人對死亡之旅項目的反應非常有趣。軟體業的部分人員（特別是在矽谷）把這類項目美化成對勇氣的測試，認為它在一定程度上類似於赤足攀登珠穆朗瑪峰。在自己20世紀60年代中期所參加的最初幾個項目中，我就感到存在這種看法，而它在下一代人中繼續流行的事實使我認識到，只要技術像我一生中所經歷的那樣不斷迅速變化，那么這種有趣的觀點很可能就會永久存在。我們的軟體業還並不成熟：每年都有新的珠穆朗瑪峰出現，而同時也會有一批充滿自信的新程式設計師被說服，相信自己能夠赤足一直攀上頂峰。

然而，軟體業另一部分人員的看法卻截然不同，他們認為死亡之旅項目是令人困窘的失敗。在各種各樣的統計中，我們滿眼都是進度延期、預算超支、充斥著錯誤的軟體、不滿的用戶和完全失敗的項目。而諮詢顧問、權威和方法學家不厭其煩地反覆告訴我們導致這種惡果的原因包括：使用了錯誤的方法（或根本沒有方法）、工具或管理技術。換句話說，出現死亡之旅項目完全是因為我們愚不可及或者缺乏能力。

如果你同業界中久經沙場的老手（他們不但曾親身經歷過一些死亡之旅項目而且也已認識到赤足攀登珠穆朗瑪峰並不有趣）交談，他經常會這樣說：“嗨，我並不是傻瓜！我當然也想用正確的方法、工具和管理技術，但我的上級經理和最終用戶不允許我這樣做。這個項目的進度如此荒謬完全是因為從一開始它就是被強加給我們的，而那時我們連項目要乾什麼還根本不知道！”結論：死亡之旅項目的出現是因為高級管理人員都是不擇手段的混蛋，而用戶們不但幼稚可笑而且不切實際。

毫無疑問，上面所有觀點都有一定的道理：在管理項目的過程中我們確實犯了很多愚蠢的錯誤，資深管理人員確實沉迷於荒謬可笑的政治遊戲，而最終用戶們也確實向我們提出了不切實際的要求。我深信這很多是快速變更以及新生代對老一代意見的不尊重的綜合作用結果。但為什麼要尊重老一代的意見呢？畢竟現在這一代主要使用面向Java的編程技術，而我們這一代的編程經驗卻僅僅來自於30年前的自動編碼器與彙編語言。對當前的用戶而言，即便考慮到前輩們要求使用基於主機、字元界面、具備傻終端接口的線上系統，但這對搞清楚自己應該使用哪種Web套用又有什麼作用？

無論對這個現象的解釋是什麼，我們得到了一個令人清醒的結論：死亡之旅項目的產生非常正常，根本不是意外情況。我認為現今的軟體開發人員和項目經理不但十分聰明，而且非常樂於用理智的方式來管理項目；不僅如此，我還認為當今的商業用戶和高級管理人員不僅比上一代更加精通計算機，而且他們對軟體開發人員在有限資源條件下按時交付成果的期望也更加現實。但即使這樣，也並不能讓這兩類聰明人停止啟動新的死亡之旅項目——因為商務壓力和新技術要求不斷啟動這類項目。也許商務經理自己也非常明白新系統的開發至少需要12個月，但他們仍然會向你強調：如果在6個月內不能交付新系統，競爭對手就會用他們的新產品和新服務搶走全部市場份額。與此類似，雖然技術人員也許非常清楚採用新技術（例如網際網路）的風險很大，但他們還是會告訴你：如果這種技術最終獲得了成功，你就能獲得戰略上的競爭優勢，因此值得冒險。

換一個角度來說，根據Standish Group這樣的行業調查結果以及由調查權威Caper Jones、Howard Rubin、Paul Strassmann和Larry Putnam等人所收集的統計數據，項目的進度不但平均落後6~12個月，而且平均超出預算達50%~100%。雖然根據項目大小和其他不同因素的差異情況會有所不同，但嚴酷的現實往往是項目情況幾乎肯定會導致項目經理及其技術人員出現死亡之旅中的行為。如果項目一開始便伴隨著這些高風險因素，那么項目進行中不但一定會出現大量加班的情況，而且人員很可能會在項目結束前身心俱疲。

因此真正的問題在於：如果死亡之旅項目不可避免，那么你怎樣才能逃脫失敗的命運？你應如何做才能增加成功的機率？你應該準備在哪些方面妥協？你應該準備在何時辭職——一旦無法按自己的意願行事的時候？本書就是為了回答這些問題。以上這些問題不但涉及負責項目的經理，而且還與進行設計、編碼、測試、撰寫系統文檔等實際工作的技術人員息息相關。我將在後續章節對這兩組人員進行討論。

對於經理和技術人員，我在這裡事先給你一個提醒：下面章節中的一些評論將會把管理層暗示為“邪惡”的一面，而項目團隊成員則被暗示為受到壓制的無辜犧牲品。很明顯，這種暗示並不適用於所有的項目和公司，儘管死亡之旅項目通常來源於有意識的管理決策。然而，儘管項目團隊成員也許自願參加此類項目，但這些項目的始作俑者往往並不是他們。

如果到此你已經斷定自己沒有時間閱讀本書，那么請你記住下面這個簡單的詞：分類（Triage）——它也許將會為你帶來一些價值，作為你閱讀前言的回報。如果你正在為一個死亡之旅項目工作，那么幾乎可以肯定你將無法在分配的進度和預算之內，利用現有的資源完成用戶所要求的功能和特性。你將不得不做出一些冷酷的決定：確定哪些特性需要放棄以及哪些特性需要集中資源予以保證。實際上，由於一些瑣碎的特性永遠都不會被用到，因此最好是讓它們自己消亡。其他特性雖然重要，但實現起來卻相對簡單，例如它們很可能就是用戶所提供的類庫或你當前所用計算機輔助軟體工程（Computer?Aided Software Engineering，CASE）工具的副產品。根據“分類”在醫學上的寓意：這些特性是否能夠得以倖存完全取決於自身。死亡之旅項目的成敗往往取決於項目團隊對系統關鍵特性的定位能力，因為如果缺乏充足的資源和精力投入，這些關鍵特性肯定必將會消亡。

當然，要想在死亡之旅項目中倖存下來，僅僅靠分類（將在第3章中討論它）還遠遠不夠，我們還要注意如下幾個方面的問題：人件、“過程”、工具和技術。由於我已經爭取將本書表述得儘可能準確，因此你應該能夠在幾個小時內讀完本書；在讀完本書後，即便沒有獲得別的收穫，你至少也能夠對自己的下一個死亡之旅項目有一個更實際的評估。

然而，請務必不要把此書當成一本聖經，也不要認為它將為你的所有問題都給出完美的解決方案。本書並不包含確定無疑的“正確”答案，因為在某種情況下對一些公司適合的解決方案並不一定適用於其他公司。與此相比，有一點同樣重要：一些經理和技術人員自願做出的承諾對其他人員來說很可能就不可接受。雖然在本書中我會給出一些自認合理的建議，但最終還是要由你本人來決定這些建議中哪些適用於自己。

我同樣一直在利用自己的網站不斷收集來自實際項目團隊的意見，這些項目團隊往往會針對最佳實踐、最壞實踐和“酒醉測試器”問題給出一些實用的技巧。即便你的項目預算緊張到不能購買本書（如此吝嗇的預算本身就預示著死亡之旅！），你至少還可以看看死亡之旅的網頁——不用花一分錢。

無論你決定怎么做，祝你在下一個死亡之旅中好運。而且，請記住Samuel Beckett的話：

死亡之旅（第2版）

基本介紹

基本信息

編輯推薦

目錄

譯者序

前言

相關詞條

熱門詞條