分类： 项目管理
2011-11-14 16:36:27
非常简单，死亡之旅项目就是“项目参数”超标50%以上的项目。对绝大多数项目而言，这意味着下列限制条件的一个或多个被强加于项目之上：
在很多组织中，以上这些限制条件所产生的直接影响通常是：与正常项目相比，项目团队要么每周付出两倍的工作时间，要么付出加倍的努力。因此，如果正常情况是一周工作40小时，死亡之旅项目往往要求每天工作13到14小时，而且每周工作至少6天。由于在这种环境下紧张和压力会自然而然地升级，死亡之旅团队看起来就像是一直在使用兴奋剂一样。
描述此类项目的另一种方法如下：
如果公正客观的风险评估（应包括对技术、个人、合法性、政治等各方面的风险评估）所得出的结果是项目失败概率大于50%，那么这就是一个死亡之旅项目。
当然，即使没有以上这些关于进度、人员、预算和功能方面的限制，项目也有很大的可能性以失败告终。例如，在IT部门与用户之间充满敌意。但更常见的情况往往是：高风险的评估结果往往是上述限制条件综合作用的结果。
1.2 死亡之旅项目的分类死亡之旅项目多种多样，各有特点。它们不仅包括进度、人员、预算和功能限制条件的不同组合，而且还具有不同的规模、范围和特色。
根据我的经验，规模是区分死亡之旅项目的最重要因素。考虑以下4种不同规模的项目：
由于多种原因，在我所访问过的组织中，小规模死亡之旅项目最为常见；但幸运的是，这类项目成功的概率也最大。因为由3到6人所组成的团队更有可能紧密团结在一起，如果他们再知道充满高强度工作的漫漫长夜、损失的周末以及被推迟的假期在几个月后都会得到补偿，那么这种被高度激励的团队更有可能自愿为项目牺牲3到6个月的个人生活（而且还有他们的健康！）。
相比而言，中等规模死亡之旅项目的成功率明显下降，而大规模死亡之旅项目的成功率几乎为零。随着所涉及人员数量的增多，不但凝聚的团队精神更加难于维持，而且人员流失、出现意外以及发生各种现代社会危险的几率也在迅速地增加。在这种情况下，至关重要的因素不仅包含所涉及人员的数目，而且还包括持续时间的长短：在6个月中每周工作80个小时也许还可以忍受，但如果这种情况持续2年很可能就将导致严重的问题。
至于超大规模的死亡之旅项目，人们甚至很奇怪它们为何会存在。也许与1969年NASA登月项目相关的系统开发项目可以被看做是这类死亡之旅项目的一个成功范例，但绝大多数此种类型的项目一开始就注定将会以失败而告终。值得庆幸的是，绝大多数高级管理层都认识到了这一点，而且几乎所有的大型组织（一开始也只有它们才可能做得起这种项目）都严格防止启动这类项目。但是，唉，政府组织仍然会时不时启动这种项目；除了为处理这种“超级”项目而基本毫无限制的预算，对爱国想法（例如，后9·11时代的国家安全）的狂热足以蒙蔽高级管理层的双眼，使他们没有认识到注定失败的结果。
除了项目的规模，使用类似“涉及组织的数量”这样的标准来表示死亡之旅项目的等级也很有帮助。即便是只需要使单个用户或一组来自同一部门的同类用户感到满意，项目团队的工作就已经十分困难。而企业范围项目的难度往往要增加几个量级，原因很简单：任何跨职能的活动都包含着政治和沟通问题。因此，与商务重组项目相关的系统开发项目往往会堕落成为一场死亡之旅。在这种情况下，即使开发中所使用的硬件和软件都十分先进，但政治斗争也很可能会导致组织瘫痪，让项目团队受到无穷无尽的挫折。
最后，我们可以找到极其困难的项目与那些根本不可能的项目之间的差异。《Crunch Mode》一书的作者John Boddie指出：
| 具有优秀的技术人员、卓越的管理人员、突出的设计人员和聪明、忠诚的客户并不足以保证处于危急关头的项目得以成功。的确存在根本不可能实现的项目，而且这种项目每天都在启动。绝大多数这种类型的项目都可以在开发周期中被识别出来。这种项目看起来有两大类型：“理解欠佳的系统”和“异常复杂的系统”。 |
到此为止，我们仍旧没有回答为何理智的组织会启动这样的项目以及为何理智的项目经理和技术人员会同意参与其中。我们将在下面的章节中讨论这些问题。
1.3 为何会出现死亡之旅项目 考虑自己组织内所发生的事情，你就不难理解死亡之旅为何会发生。正如非常流行的卡通《Dilbert》的作者Scott Adams指出的：
最初听说这些故事（关于丧失理性的公司行为）时，我感到很困惑。但仔细分析之后，我找到了一个复杂的定理用以解释这种古怪的工作行为：人们都是傻瓜。
包括我本人在内，每个人都是傻瓜，而不仅仅是那些SAT分数较低的人们。我们的不同在于：我们会在不同的时间对不同的事物成为傻瓜。无论多聪明，你也会花费许多时间去做一个傻瓜。
想象这个景象“自己不但是傻瓜，而且还被傻瓜们所包围”（并且还要接受他们的管理！），这种情景也许令人非常沮丧。哪怕是一个对此的小小暗示，你也许都会把它看做是一种侮辱。如果是那样的话，你可以参照下表，我在表中列出了较为详细的死亡之旅项目的发生理由。
死亡之旅项目发生的原因
尽管表中所列出的各种原因都很简单明了，但它们还是值得进行探讨——因为它们很可能向你表明：你的死亡之旅如此疯狂而缺乏理智，因此根本就不值得参加。实际上，即便项目中并没有出现表中所列出的确切情况，你仍然应该认真考虑是否真想把自己随后的几个月（或几年）花在这样的项目上；我们将会在本章随后的章节单独讨论这个问题。
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并列。
