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并列。