1.1  死亡之旅的定義

    非常簡單，死亡之旅專案就是“專案引數”超標50%以上的專案。對絕大多數專案而言，這意味著下列限制條件的一個或多個被強加於專案之上：

• 與用合理估算方法得出的數值相比，進度被壓縮了一半以上；因此，對於一個在正常情況下可望用12個月時間完成的專案，現在要求只用6個月或更短。由於當前全球市場上的商業競爭壓力日益增加，這種形式的死亡之旅專案最為常見。    
• 與正常情況下這種規模專案所需人員的數目相比，員工數被壓縮了一半以上；因此，對於需要10個人的專案，專案經理只能得到5個人。這種情況的出現，很可能是因為某些人過於天真：他們相信某種新的程式語言或應用程式開發環境能夠將團隊的生產率魔術般地提高兩倍，儘管團隊從未接受過相應培訓，而且從未就使用這種技術與他們進行過磋商。但不幸的是，由於持續的經濟衰退及其引起的IT預算縮減，在2003年春天我撰寫這個版本的《死亡之旅》時，這種現象的出現正在日益普遍。    
• 預算及相關資源被削減了一半以上。與上面相同，這也經常源自於精簡裁員以及其他削減支出的行為，但它也很可能是對固定總價合同進行競標的結果——這種情況下，市場部門常常會這樣通知專案經理：“好訊息是我們贏得了合同；但壞訊息是為了打敗競爭對手，我們必須削減你一半的專案預算。”這類限制通常會對你能僱傭的人員數目產生立竿見影的影響，但有時，這種影響表面上看不明顯，例如放棄僱傭價格昂貴但卻經驗豐富的人員而僱傭相對廉價、但卻欠缺經驗的新手。不止如此，它還會營造出一種壓倒性的節儉氛圍，在這種環境裡，即使專案團隊要花費整個週末在辦公室加班，專案經理也很難花錢為團隊買一隻比薩餅。   
  
• 與正常情況相比，專案被要求給出兩倍的功能、特性、效能或其他技術要求。例如，專案團隊很可能被要求在固定大小的記憶體或磁碟空間內壓縮排至少兩倍於競爭對手的功能特性；或者被要求系統的事務處理速度必須比所有其他系統高兩倍以上。儘管效能限制條件不一定會導致死亡之旅專案，但我們總是可以利用更加便宜和快速的硬體，而且可以尋找更精巧的演算法和設計方法來達到更高的效能。但是，將功能（例如可用特性）加倍通常意味著必須完成兩倍的工作量；而這肯定會導致一個死亡之旅專案的產生。    

    在很多組織中，以上這些限制條件所產生的直接影響通常是：與正常專案相比，專案團隊要麼每週付出兩倍的工作時間，要麼付出加倍的努力。因此，如果正常情況是一週工作40小時，死亡之旅專案往往要求每天工作13到14小時，而且每週工作至少6天。由於在這種環境下緊張和壓力會自然而然地升級，死亡之旅團隊看起來就像是一直在使用興奮劑一樣。

    描述此類專案的另一種方法如下：

如果公正客觀的風險評估（應包括對技術、個人、合法性、政治等各方面的風險評估）所得出的結果是專案失敗概率大於50%，那麼這就是一個死亡之旅專案。

    當然，即使沒有以上這些關於進度、人員、預算和功能方面的限制，專案也有很大的可能性以失敗告終。例如，在IT部門與使用者之間充滿敵意。但更常見的情況往往是：高風險的評估結果往往是上述限制條件綜合作用的結果。

    1.2  死亡之旅專案的分類

    死亡之旅專案多種多樣，各有特點。它們不僅包括進度、人員、預算和功能限制條件的不同組合，而且還具有不同的規模、範圍和特色。

    根據我的經驗，規模是區分死亡之旅專案的最重要因素。考慮以下4種不同規模的專案： 

• 小規模專案——團隊包含3到6人，目標是努力在3到6個月內完成不可能完成的任務。    
• 中等規模專案——團隊由20到30人組成，涉及的專案預計歷時1到2年。    
• 大規模專案——團隊由100到300人組成，預計專案歷時大約3到5年。    
• 難以置信的超大規模專案——團隊由1 000到2 000人組成，有時人數甚至會更多（在很多情況下，將包括專案顧問和分包商），專案預計歷時7到10年。    

    由於多種原因，在我所訪問過的組織中，小規模死亡之旅專案最為常見；但幸運的是，這類專案成功的概率也最大。因為由3到6人所組成的團隊更有可能緊密團結在一起，如果他們再知道充滿高強度工作的漫漫長夜、損失的週末以及被推遲的假期在幾個月後都會得到補償，那麼這種被高度激勵的團隊更有可能自願為專案犧牲3到6個月的個人生活（而且還有他們的健康！）。

    相比而言，中等規模死亡之旅專案的成功率明顯下降，而大規模死亡之旅專案的成功率幾乎為零。隨著所涉及人員數量的增多，不但凝聚的團隊精神更加難於維持，而且人員流失、出現意外以及發生各種現代社會危險的機率也在迅速地增加。在這種情況下，至關重要的因素不僅包含所涉及人員的數目，而且還包括持續時間的長短：在6個月中每週工作80個小時也許還可以忍受，但如果這種情況持續2年很可能就將導致嚴重的問題。

    至於超大規模的死亡之旅專案，人們甚至很奇怪它們為何會存在。也許與1969年NASA登月專案相關的系統開發專案可以被看做是這類死亡之旅專案的一個成功範例，但絕大多數此種型別的專案一開始就註定將會以失敗而告終。值得慶幸的是，絕大多數高階管理層都認識到了這一點，而且幾乎所有的大型組織（一開始也只有它們才可能做得起這種專案）都嚴格防止啟動這類專案。但是，唉，政府組織仍然會時不時啟動這種專案；除了為處理這種“超級”專案而基本毫無限制的預算，對愛國想法（例如，後9·11時代的國家安全）的狂熱足以矇蔽高階管理層的雙眼，使他們沒有認識到註定失敗的結果。

    除了專案的規模，使用類似“涉及組織的數量”這樣的標準來表示死亡之旅專案的等級也很有幫助。即便是隻需要使單個使用者或一組來自同一部門的同類使用者感到滿意，專案團隊的工作就已經十分困難。而企業範圍專案的難度往往要增加幾個量級，原因很簡單：任何跨職能的活動都包含著政治和溝通問題。因此，與商務重組專案相關的系統開發專案往往會墮落成為一場死亡之旅。在這種情況下，即使開發中所使用的硬體和軟體都十分先進，但政治鬥爭也很可能會導致組織癱瘓，讓專案團隊受到無窮無盡的挫折。

    最後，我們可以找到極其困難的專案與那些根本不可能的專案之間的差異。《Crunch Mode》一書的作者John Boddie指出：

具有優秀的技術人員、卓越的管理人員、突出的設計人員和聰明、忠誠的客戶並不足以保證處於危急關頭的專案得以成功。的確存在根本不可能實現的專案，而且 這種專案每天都在啟動。絕大多數這種型別的專案都可以在開發週期中被識別出來。這種專案看起來有兩大型別：“理解欠佳的系統”和“異常複雜的系統”。

    到此為止，我們仍舊沒有回答為何理智的組織會啟動這樣的專案以及為何理智的專案經理和技術人員會同意參與其中。我們將在下面的章節中討論這些問題。

    1.3  為何會出現死亡之旅專案

    考慮自己組織內所發生的事情，你就不難理解死亡之旅為何會發生。正如非常流行的卡通《Dilbert》的作者Scott Adams指出的：

最初聽說這些故事（關於喪失理性的公司行為）時，我感到很困惑。但仔細分析之後，我找到了一個複雜的定理用以解釋這種古怪的工作行為：人們都是傻瓜。           包括我本人在內，每個人都是傻瓜，而不僅僅是那些SAT分數較低的人們。我們的不同在於：我們會在不同的時間對不同的事物成為傻瓜。無論多聰明，你也會花費許多時間去做一個傻瓜。

    想象這個景象“自己不但是傻瓜，而且還被傻瓜們所包圍”（並且還要接受他們的管理！），這種情景也許令人非常沮喪。哪怕是一個對此的小小暗示，你也許都會把它看做是一種侮辱。如果是那樣的話，你可以參照下表，我在表中列出了較為詳細的死亡之旅專案的發生理由。

    死亡之旅專案發生的原因

    
• 政治、政治還是政治（見1.3.1節）     
• 市場人員、高階管理人員、缺乏經驗的專案經理等人所做出的幼稚承諾（見1.3.2節）     
• 年輕人天真的樂觀主義：“我們週末就能完成！”（見1.3.3節）     
• 新公司的創業精神（見1.3.4節）     
• 海軍陸戰隊精神：真正的程式設計師無需睡眠（見1.3.5節）     
• 市場全球化所導致的殘酷競爭（見1.3.6節）     
• 由於出現新技術而引發的激烈競爭（見1.3.7節）     
• 不可預期的政府法令所導致的巨大壓力（見1.3.8節）
  
• 出乎意料和/或未經計劃的危機——例如，你的硬體/軟體供貨商突然破產，你最好的3個程式設計師突然死於腹股溝淋巴結髮炎（見1.3.9節）     

    儘管表中所列出的各種原因都很簡單明瞭，但它們還是值得進行探討——因為它們很可能向你表明：你的死亡之旅如此瘋狂而缺乏理智，因此根本就不值得參加。實際上，即便專案中並沒有出現表中所列出的確切情況，你仍然應該認真考慮是否真想把自己隨後的幾個月（或幾年）花在這樣的專案上；我們將會在本章隨後的章節單獨討論這個問題。

    1.3.1  政治，政治，還是政治

    很多軟體開發人員都發誓自己不會涉足政治，這是因為他們明白自己並不擅長玩弄政治權術，而且還覺得與政治相關的每件事都十分令人厭惡。可是，唉，政治偏偏無處不在：只要一起幹事的人超過兩個，政治就必然存在。

    然而，一旦政治在龐大而複雜的專案中佔據支配地位，那麼專案就很可能墮落成死亡之旅。請記住我對死亡之旅專案的定義：進度、預算、人員或其他資源比正常情況少50%~100%的專案。為什麼這些限制條件會被強加於專案之上？對於這個問題，雖然情況有可能像下面討論中我們將要看到的那樣，很可能有很多答案；但在很多情況下，答案非常簡單：因為政治。它也許是組織中兩個雄心勃勃的副總裁之間權力鬥爭的產物，也有可能原本就被設計好了失敗的結局，從而作為一種報復形式去懲罰那些在錯誤的時間裡站錯了立場的經理們。當然，答案的可能性多種多樣，無窮無盡。

    對你而言，儘管很難讓“政治家們”承認專案只不過是一場政治遊戲而已；但是，如果你是一個技術人員，向專案經理問清整個死亡之旅專案是否只是一場政治騙局完全合乎情理。即便自己厭惡政治，或者自認是一個政治方面的新手，你也要仔細聽清自己的經理所給出的答案。你並不愚蠢，而且也並不是那麼天真。因此一旦感覺到專案完全是被醜惡的政治所左右，那麼你很有可能完全正確。如果自己的直接上司給出的答案幼稚可笑、模稜兩可或缺乏說服力，你就應該親自去找出正確的結論。換而言之：如果你的專案情況與“Dilbert（呆伯特）”漫畫中的描述完全一樣，那麼此專案很可能就是任何理智的人都不願參加的某種死亡之旅專案。

    如果經理公開同意你的觀點該怎麼辦？如果他說：“對，整個專案其實就是副總裁Smith與Tones之間的權力鬥爭而已……”這時你又該如何應對？如果事實果真如此，那麼你的經理又是為了什麼而參加這個專案呢？正像下面討論人們為何參加死亡之旅專案的章節中我們將要看到的那樣，這很可能有很多原因；但你一定要記住：經理的理由並不一定同樣適用於你。雖然專案中存在醜陋的政治，但並不一定意味著你應該立刻放棄專案或提出辭職，但它確實意味著：你應該將自己的優先順序、目標和行為準則與專案情況分離開來，因為專案中的許多決策（從專案起始時所做出的有關進度/預算/資源的決策開始，這些決策決定了專案是一個死亡之旅）並不把使用者或企業的利益放在第一位。即使專案最終成功結束，結果也很可能是偶然碰到而已，或者有可能是因為原本設計好的犧牲品（即可能是你的專案經理，但也有可能是在你的直接經理上面若干級的一位經理）與其對手相比是一個更聰明的政治家。

1.3.2  市場人員、高階管理人員、缺乏經驗的專案經理等人所做出的幼稚承諾

    幼稚經常與缺乏經驗相連；因此，當人們對建造所需系統需要多少時間和工作量一無所知時，毫不奇怪他們會做出不切實際的承諾。在極端情況下，這甚至會導致我的朋友Tom DeMarco所說的“歇斯底里的樂觀主義”：對於從未嘗試過的複雜系統，儘管專案完工所需時間的合理估算是3年，但組織中的成員卻仍然拼命讓自己相信它不管怎樣都必定能在9個月內被完成。

    不僅如此，我們下面還會看到，這種幼稚和樂觀主義也同樣擴散到了技術人員中。但現在暫時讓我們假設罪魁禍首是你的經理、市場人員或終端使用者——是他們導致了過於樂觀、幼稚的進度和預算，問題是：如果情況越來越明顯地證明最初的承諾過於樂觀，這時他們會做出什麼反應呢？他們是否會延長工期、增加預算並且冷靜地承認情況比預想的要艱苦？他們此時是否會感謝你和同事們此前所做出的英雄主義行為？如果他們確實這樣做了，那麼對你來說，此時最重要的事情就是避免瀑布型生命週期，這樣你才能在交付系統的第一個原型版本後儘快對進度、預算和資源目標做出現實的評估。

    然而，在許多死亡之旅專案之中，這種理智的中途修正措施根本不可能發生。例如，如果高階管理人員已經向客戶做出了幼稚的承諾，並且覺得無論如何都應該信守這個諾言時——不管它是什麼，情況很可能就是如此。在最壞情況下，做出承諾的人自己對實際情況也十分清楚（下面的情況很明顯就是如此）：為了慶祝從一些愚蠢的客戶那裡獲得了新合同，宴會上，市場經理一邊暢飲著啤酒，一邊向專案經理坦言相告：“老兄，如果真的把專案實際需要的時間告訴客戶，我們根本就不可能拿到合同；畢竟，我們都知道競爭對手會提出非常有競爭力的方案。何況不管怎樣，你的手下總是會千方百計湊夠進度和預算，對不對？”

    如果以上承諾來自你的老闆或比你高兩三級以上的經理，情況尤其麻煩。很明顯，在這種情況下，對進度和預算進行估算的整個過程看起來就像是一個談判遊戲（將在第3章中討論這一點）。但這其中還是存在一定程度的幼稚和天真，因為你的經理對“湊齊”進度和預算的抱怨有著不言而喻的暗示：你應該能夠完成強加給你的荒謬進度。另一方面，這種承諾很可能還與所謂的“海軍陸戰隊”思想有關，將在後續章節討論這一點。類似地，市場部門對可笑的進度和預算所做出的承諾很可能是另一種形式的政治；更確切地說，因為市場代表關心的主要目標是銷售提成、完成銷售額或者取悅自己的老闆，所以他很可能根本不關心自己所提出的進度和預算是否荒謬。

    現在讓我們暫時假設死亡之旅專案完全是由“純粹的”幼稚所導致，而不涉及政治和其他惡意因素。問題是：你該如何對待它？正像前面所提到的那樣，關鍵問題之一在於：如果最初的承諾很明顯不能實現，那麼決策者可以修改進度和預算的可能性有多大？儘管可以預先參考具有相似情況的死亡之旅，但實際情況還是很難被事先預測。（如果這是公司裡出現的第一個這種型別的專案，那麼你就處在完全未知的領域之中！）

    如果你有下面這種深刻的印象（無論是從自己的政治本能還是從組織中以往的專案經驗）：無論多麼背離現實，管理層都會堅持最初的預算和進度。這時你就需要對自己是否需要繼續執行專案做出一個重要決定。這其中包括你可以在多大範圍內對專案的其他方面進行談判——比如將被分配到專案的技術人員等，我們將在第2章討論這個問題。

1.3.3  年輕人天真的樂觀主義：“我們週末能完成它！”

    對於與死亡之旅專案相關的許多愚蠢決定，儘管管理層是一個方便的替罪羊，但技術人員也不是完全沒有責任。實際上，在很多情況下，對複雜專案的進度和預算所做出的那些幼稚估算完全來自於技術人員，而高階管理人員只不過是高興地接受了而已。“你認為這要花多長時間？”一個副總裁會這樣詢問技術骨幹，而他很可能在上星期才剛剛被提升為第一級主管。

    如果被問到的這個技術骨幹並不瞭解實際情況，而且他還充滿了朝氣蓬勃的樂觀主義（這與十幾歲少年的錯覺（自認為無所不能、無所不知）十分類似），他的答案往往是：“沒問題，我們也許這個週末就能把它搞出來！”真正優秀的軟體工程師（或者用一個更恰當的詞“黑客”）都非常相信自己只用一個週末就能開發出任何系統。然而，由於某些細節如此令人厭煩，例如文件、出錯處理、使用者輸入編輯和測試等，所以他們並沒有將它們考慮在內。

    如果你就是那個充滿了天真的樂觀的軟體工程師，雖然你負責死亡之旅估算，但很可能你甚至連自己在做什麼都不知道。也許你已經讀完了上一段話，而且對這種明顯的侮辱感到非常憤怒，嘴裡也在不停地嘟囔著：“當然是這樣！我真的能用一個週末做出任何系統！”願上帝保佑你；說不定你真的會成功。無論如何，從我這種老朽嘴中所說出的話永遠都不可能改變你的主意。

    然而，如果你是一個久經沙場的老手，而且你已經發現，由於一些年輕而幼稚的技術經理對專案的進度、預算和資源做出了過於樂觀的承諾，自己將會被繫結在一個死亡之旅專案之上——此時你該怎麼做呢？我認為最好的建議是：“三十六計走為上！”一旦發現自己陷入其中無法自拔，這些技術經理往往會徹底土崩瓦解，做出不理智的行為或陷於徹底停頓。在絕大多數情況下，他們從未處理過如此龐大與複雜的系統，因此也不知道僅憑單純的聰明和匹夫之勇（例如，在週末進行48小時無間斷的編碼）根本無法應付。但無論如何，在專案落後於進度時，他們肯定沒有心情聽你說“我曾警告過你！”。

1.3.4  新公司的創業心理

    我不僅看到這種事情的發生，而且也參加過這樣的專案，甚至有幾次還曾負責這種專案的啟動。在本書第一版付梓後不久，看起來任何新公司只要在公司或產品名稱裡帶有“.com”字樣，就能比“確切知道要幹什麼”拿到更多的風險投資。然而，正如風險投資家和充滿希冀的投資者逐漸看清的情況一樣，剛剛起步的公司通常不但缺乏人手、經費和必要的管理，而且還對專案的成功存在著盲目的樂觀。他們肯定會是這樣：因為在準備了足夠的資金和進行了大量的計劃之前，謹慎、保守的經理永遠都不會考慮啟動一個新公司。

    因此，根據定義，與剛起步的公司相關的專案大部分都屬於死亡之旅專案。不僅如此，在這些專案中，大部分的專案最後都會以失敗而告終，而這最終又會導致公司的消亡。這就是生活——高科技資本主義的全部含義都在於此（不僅僅是在美國，在全世界都是如此）。由於一生中對這種文化長期的耳濡目染，我認為這種現象再正常不過；當然，我的觀點也被自己曾若干次成功完成這種專案的事實所影響。實際上，這種情形通常是啟動死亡之旅專案的積極原因之一，下面將對此進行詳細討論。

    然而，並不是每個人都熟知公司起步時的文化和環境。如果你已經在一個因循守舊的政府部門（或者在大多數的銀行、保險公司和電話公司中）中使用僵化的COBOL 工作了20 年，而現在由於機構裁員、外包或重組而不得不在剛剛起步的公司求得一個職位，很可能你根本不知道自己要參加什麼樣的專案。雖然死亡之旅專案同樣也會出現在大公司之中，但專案人員卻大多來自公司外部。相比而言，在剛起步的公司中，死亡之旅專案的環境截然不同；它看起來更像是由純粹的興奮導致。

    與此同時，剛剛起步的公司往往是前面所討論的這種幼稚的樂觀的受害者。許多這種公司都由狂熱的技術人員所建立，這些創業者確信自己所使用的新技術將會讓他們比比爾·蓋茨還要更加富有；除此之外，其他這類公司則往往由銷售天才建立，這些銷售能手們自信能夠賣掉任何商品，甚至能把因特網化電冰箱賣給輕信的愛斯基摩人。對剛剛起步的公司而言，雖然樂觀的確非常重要，而且風險投資的成功也往往依賴於能夠完成前人不能完成的事業，但即便是充滿開拓精神和樂觀主義的公司，其行動也必須遵守物理和數學的基本定律。因此，如果參加了一個新公司的死亡之旅專案，你一定要弄清楚行動到底是基於為了達到成功而進行的某些計劃，還是基於完全一廂情願的痴人說夢。

1.3.5  海軍陸戰隊精神：真正的程式設計師無需睡眠

    雖然剛剛起步的公司有時比較容易患上“海軍陸戰隊”綜合徵，但根據我所看到的情況，這種症狀最容易發生在類似EDS和Big-X這樣的諮詢組織中。這種“病症”很可能反映了企業建立者的個性和企業建立初期的文化，例如，微軟的組織行為就經常被歸因於這種因素。一般而言，經理會這樣通知你：“每個專案都是這樣做的，因為這就是我們這裡的做事方法。它很有效，我們也因此獲得了成功，我們真的為此自豪。如果你不能這樣做，那麼你就不屬於我們這裡。”

    上面的觀點是否有道理、人道或正確，需要進行單獨的討論。實際上，即便是它是否真的像宣稱的那樣成功也非常值得另加商榷；重要的是要認識到這種觀點的出現並不是偶然的，而是深思熟慮之後的結果。如果你是一個為了信仰而甘願犧牲自己的改革者，很可能你會決定攻擊這種企業文化，但結果很可能會以失敗而告終。這種全面的死亡之旅文化很可能還存在很多長期的負面影響，比如，最好的人才會慢慢流失，而公司最終會破產。但是，在當前這個死亡之旅專案到來時，你卻不可能質疑專案為什麼設定了幾乎不可能的進度和預算目標。原因很簡單，正像上面那個經理的典型言論：“如果不能這樣做，那麼你就不屬於我們這裡。”

    有時，對這種企業行為也存在官方的解釋，例如，“我們的市場競爭十分激烈，而且對手和我們一樣聰明。要想脫穎而出，唯一的辦法只能是付出加倍的努力。”另一些時候，啟動死亡之旅專案的目的就是為了淘汰那些比較年輕（能力較差）的人，以便只有死亡之旅專案的倖存者們才能晉升到“合夥人”或“副總裁”這樣的級別。然而，不管理由是什麼，它通常都很公平；因此也很少出現針對個別專案的抱怨。

    儘管如此，這並不意味著你必須接受這種專案；畢竟，組織裡所有其他專案都是死亡之旅並不代表你肯定能成功完成此專案。它僅僅告訴我們：這樣的一個專案有一個可以理解的啟動原因。

1.3.6  市場全球化所導致的殘酷競爭

    很多組織過去並不能容忍死亡之旅專案的出現，但進入21世紀之後，由於市場全球化帶來的競爭越來越激烈，他們被迫接受這種專案。當然，這也有第二個因素的影響：因特網和Web以及開放受保護市場或減免關稅和配額的政府決策。

    對於某些組織，這種現象並不新鮮；例如，從20世紀70年代起，汽車和電子工業就開始面臨激烈的競爭。但對其他的組織來說，歐亞競爭對手在北美市場上的出現卻實在不亞於一場劇烈的地震。一旦高階管理人員認識到將要面對的殘酷競爭，他們往往會採取不同的極端措施來應對，方式從裁員到將業務外包給世界其他國家，不一而足；除此之外，他們也很可能決定採用一種新產品或新服務來迎接競爭，而這需要建立一種全新而富有挑戰性的系統提供支援。烏拉！又一個死亡之旅型別的專案開始了。

    與這種全球化現象相關的一個最新形式是將軟體開發專案外包給位於印度、中國、俄國或其他國家的海外公司。通過訪問多個國家的軟體組織，我可以證實這些公司通常並不是熱衷於死亡之旅（要求程式設計師以每週7天、每天16個小時的強度進行工作）的苦工作坊。不過，由於這些低成本海外軟體開發資源的存在，國內軟體公司和IT部門很可能將被迫要求美國境內這些薪水相對較高的員工工作更長的時間。正如一位讀者在最近發給我的電子郵件中所指出的：

    “我預計情況正在變得越來越糟。為了大量削減成本，將軟體開發工作外包給海外的趨勢正愈演愈烈，而剩餘的國內軟體公司將遭受巨大的價格競爭壓力。可行的競爭方法只有一個：第一個將產品投入市場，同時削減成本。‘死亡之旅’很可能將成為許多公司的標準過程。經濟狀況的改善並不會改變這些市場現實。”

1.3.7  由於出現新技術而引發的激烈競爭

    雖然市場擴大引起的競爭通常被看成一個防禦問題，但它也能被看成一個主動發揮積極性的時機——例如，“如果採用雙位元組字元來構建這種新系統，我們的產品就能銷往日本市場”。與此類似，如果一家公司對採用較老技術生產的產品感到相當滿意，這時引進一種進行了根本革新的技術很可能會引發一場抵制活動；但是，為了在競爭中取勝，公司很可能決定採用這種新技術。在此書正在編寫的時候，類似無線計算和Web服務的技術就是這種現象的明顯例項；但對於我們的工業來說，真正令人驚奇的是每過幾年就會出現全新的例子。

    如果公司對新技術完全是抵制性的反應，那麼死亡之旅專案的目標就很可能是力圖使舊技術超越其正常情況下所能達到的極限。因此，如果由於以往對老技術（或與其相關的基礎設施）的投資過大而無法完全放棄它，那麼公司就很可能決定重新編寫原有系統，但卻會要求開發人員設法將其速度和魅力提高10倍。

    許多這種型別的死亡之旅專案都包括對新技術的首次使用。請回想自己組織內實施的第一個客戶機——伺服器專案、物件導向專案、關聯式資料庫專案或者因特網/Java專案的情況；在它們中，部分專案只是為了發現新技術的潛在收益而做的適當實驗，但部分專案很可能是為了與那些使用相同技術的公司進行競爭。在後一種情況下，這些專案不但進度和預算極其緊張，而且其規模可能非常龐大。

    但真正使這種專案屬於死亡之旅型別的原因，除了顯而易見的規模、進度和預算特徵之外，是試圖在工業強度的應用程式中使用尖端技術。即便這種技術目前已經基本可用，但它的擴充套件性往往也較差，並不適於大規模應用；不僅如此，此時往往也沒有人知道如何對其取長補短；而且供貨商也不知道如何才能正確提供售後服務；而且……

    儘管年長的技術人員（那些還記得FORTRAN Ⅱ和組合語言過去黃金歲月的人們）很可能將所有這些都當做一段不愉快的經歷，但重要的是不要忘記專案經理和年輕氣盛的工程師們往往會選擇使用這些新技術，因為它們都很新。而這些人正是上面提到的那些對自己的進度和預算限制充滿了幼稚的樂觀的人。當所有人在深夜和週末還在努力將實驗性的新技術或多或少地加入到工序之中時，還會有人對專案已經變成一場死亡之旅產生懷疑嗎？

1.3.8  不可預期的政府法令所導致的巨大壓力

    如前所述，死亡之旅專案的發生與市場全球化相關的原因之一是因為政府權力機構決定減少關稅、消除進口配額和“開放”原先關閉的市場。但這僅僅是政府影響導致死亡之旅專案的例子之一；而放開原先受控制的行業與政府機構私有化是另2個明顯的例子。事實上，今天發生的許多死亡之旅專案都是政府決定放開通訊、金融服務、航空等行業的結果。

    然而，在其他很多情況中，政府權力機構都增大了規章監管力度，特別是在稅收、向股票監管機構報告詳細財務資訊、環境法規等方面。在任何民主社會實行這種法規之前，由於立法機構對細節的辯論和爭執通常很可能都要歷時數月乃至數年之久，因此事先都會有大量預兆出現。然而，細節往往只有在最終才能清晰地呈現出來，而且高階管理人員通常也會採用“在整個事情不可避免之前根本不去理睬它”的對策。隨後，轟隆隆！又一個死亡之旅專案出現了。

    對於許多由於政府強制而導致的死亡之旅專案而言，最為棘手的因素是最後期限：新系統必須在某一日期之前投入執行（例如在元旦之前），否則就會導致每天數百萬美元的罰款。雖然申請延期或放棄並不是完全沒有可能，但在絕大多數情況下，最後期限往往不能更改。一旦新系統不能按時就位，最後的結果對組織來說往往就是與上述情況類似的可怕景象：裁員、破產或者其他不幸。

    請注意，在這樣的專案中，技術往往不是問題的關鍵；它之所以成為死亡之旅完全是因為進度過於緊張。當然，高階管理人員有時會使情況複雜化：或者給專案分配的人員不足，或者給專案分配的預算不足，結果導致專案停滯不前。

1.3.9  出乎意料和/或未經計劃的危機

    你手下最好的兩個程式設計師剛剛走進你的辦公室，通知了你如下資訊：（a）他們剛剛結婚；（b）剛剛加入了要在非洲叢林中建造醫院的傳教團體；(c)今天是他們的最後一個工作日。或者，你的網路服務經理剛剛通知你：你的供貨商已經破產，為了使用另一家供貨商的網路協議，你必須在隨後的30天內重新編寫所有的程式。或者，你的法律部門打電話告訴你：由於沒有遵守神祕的無人知曉的法規Q的第13（b）條款，公司已經被起訴，而且被要求支付鉅額賠償。

    當然，你可以這樣爭辯：在良好管理的公司中，兩個最佳程式設計師的離職不但應該事先被預料到，而且應該制訂出相應計劃；你不會愚蠢到完全依賴一個通訊供貨商；管理層應該早已富有遠見地事先檢查過法規Q的具體細節。對於純粹主義者而言，以上這些危機完全是計劃和管理不足的後果；因此“未經計劃的危機”是一個複雜的情況。

    也許真是如此；但從實用的角度出發，對於商業世界中可能發生的所有瘋狂事件，進行預計並制訂相應計劃的工作正在變得越來越困難。無論好壞，我們生活的世界都充滿了混沌，而死亡之旅專案正是這種混沌的自然產物9。事實上，即便已經預知在將來會出現混沌之事，但在其發生時我們很可能還是不得不使用死亡之旅的方式進行應對。例如，在加州聖安德魯斯附近，儘管每個人都清楚地知道劇烈的地震遲早會發生；但當地震來臨並將整個州的西半部送入太平洋時，人們仍然在使用死亡之旅的方式來應付災難。

    實際上，即便我們知道危機將要發生的精確時間，但它帶來的往往依舊是死亡之旅，因為管理層總是喜歡在迫在眉睫時才進行處理。如果不是這樣，我們又怎麼解釋在千年蟲問題迫近時，許多IT組織內不斷蔓延的恐慌？我們很早就知道2000年1月1日正在到來，也非常清楚這個最後期限無法推遲。不僅如此，我們還精確地知道問題的實質，明白解決它並不需要Java那樣剛剛被發明的技術。既然如此，那為什麼會有如此眾多的死亡之旅專案在1998年和1999年中被啟動？

    無論如何，未知危機能夠導致所有型別的死亡之旅專案。在最壞的情況下，它會導致將最後期限被設定為“昨天，如果不能更快的話”的專案——因為危機業已發生，而且在解決相應問題的新系統被安裝之前情況會日益惡化。在其他情況下——比如關鍵專案人員突然離職、由於危機導致人力缺乏或關鍵智力資源流失，原本合理的專案最終也將被變成一場死亡之旅。

    出於不同的理由，這些通常是最糟的死亡之旅專案型別，因為沒人能夠預測到專案最終會走上這條道路。在上面討論過的“海軍陸戰隊”情況之中，並沒有任何出乎意料的事情發生：從第一天起，專案中每個人都非常清楚此專案將像以前所有的專案一樣，需要付出特別的努力。對於“剛啟動的公司”這種情況，人們預期死亡之旅專案中將充滿了刺激；不僅因為它將令人激動和充滿挑戰，而且因為它一旦成功，所有人都會因此而成為富有一族。

    -------------------------------------------------------

    
    

    本文節選自《死亡之旅(原書第2版)》（英文原書名：Death March, Second Edition），作者：Edward Yourdon。

  《死亡之旅(原書第2版)》涉及整個專案生命週期，對現實中所面臨的所有關鍵問題都進行了系統分析：政治鬥爭、人、過程、專案管理以及工具。無論身兼何職，身處何位：開發人員、專案主管、職業經理、CxO，你都能從本書中找到現實、實用、有效的解決方案！

    Edward Yourdon，曾被選為軟體行業最有影響力的十大傑出人物，而且被選入計算機名人堂，與Charles Babbage、Seymour Cray、James Martin、Grace Hopper、Bill Gates並列。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16502878/viewspace-710929/，如需轉載，請註明出處，否則將追究法律責任。