市场人员、高级管理人员、缺乏经验的项目经理等人所做出的幼稚承诺 幼稚经常与缺乏经验相连；因此，当人们对建造所需系统需要多少时间和工作量一无所知时，毫不奇怪他们会做出不切实际的承诺。在极端情况下，这甚至会导致我的朋友 Tom DeMarco 所说的“歇斯底里的乐观主义”：对于从未尝试过的复杂系统，尽管项目完工所需时间的合理估算是 3 年，但组织中的成员却仍然拼命让自己相信它不管怎样都必定能在 9 个月内被完成。 不仅如此，我们下面还会看到，这种幼稚和乐观主义也同样扩散到了技术人员中。但现在暂时让我们假设罪魁祸首是你的经理、市场人员或最终用户——是他们导致了过于乐观、幼稚的进度和预算，问题是：如果情况越来越明显地证明最初的承诺过于乐观，这时他们会做出什么反应呢？他们是否会延长工期、增加预算并且冷静地承认情况比预想的要艰苦？他们此时是否会感谢你和同事们此前所做出的英雄主义行为？如果他们确实这样做了，那么对你来说，此时最重要的事情就是避免瀑布型生命周期，这样你才能在交付系统的第一个原型版本后尽快对进度、预算和资源目标做出现实的评估。 然而，在许多死亡之旅项目之中，这种理智的中途修正措施根本不可能发生。例如，如果高级管理人员已经向客户做出了幼稚的承诺，并且觉得无论如何都应该信守这个诺言时——不管它是什么，情况很可能就是如此。在最坏情况下，做出承诺的人自己对实际情况也十分清楚(下面的情况很明显就是如此)：为了庆祝从一些愚蠢的客户那里获得了新合同，宴会上，市场经理一边畅饮着啤酒，一边向项目经理坦言相告：“老兄，如果真的把项目实际需要的时间告诉客户，我们根本就不可能拿到合同；毕竟，我们都知道竞争对手会提出非常有竞争力的方案。何况不管怎样，你的手下总是会千方百计凑够进度和预算，对不对？” 如果以上承诺来自你的老板或比你高两三级以上的经理，情况尤其麻烦。很明显，在这种情况下，对进度和预算进行估算的整个过程看起来就像是一个谈判游戏(将在第 3 章中讨论这一点)。但这其中还是存在一定程度的幼稚和天真，因为你的经理对“凑齐”进度和预算的抱怨有着不言而喻的暗示：你应该能够完成强加给你的荒谬进度。另一方面，这种承诺很可能还与所谓的“海军陆战队”思想有关，将在后续章节讨论这一点。类似地，市场部门对可笑的进度和预算所做出的承诺很可能是另一种形式的政治；更确切地说，因为市场代表关心的主要目标是销售提成、完成销售额或者取悦自己的老板，所以他很可能根本不关心自己所提出的进度和预算是否荒谬。 现在让我们暂时假设死亡之旅项目完全是由“纯粹的”幼稚所导致，而不涉及政治和其他恶意因素。问题是：你该如何对待它？正像前面所提到的那样，关键问题之一在于：如果最初的承诺很明显不能实现，那么决策者可以修改进度和预算的可能性有多大？尽管可以预先参考具有相似情况的死亡之旅，但实际情况还是很难被事先预测。(如果这是公司里出现的第一个这种类型的项目，那么你就处在完全未知的领域之中！) 如果你有下面这种深刻的印象(无论是从自己的政治本能还是从组织中以往的项目经验)：无论多么背离现实，管理层都会坚持最初的预算和进度。这时你就需要对自己是否需要继续执行项目做出一个重要决定。这其中包括你可以在多大范围内对项目的其他方面进行谈判——比如将被分配到项目的技术人员等，我们将在第 2 章讨论这个问题。  年轻人天真的乐观主义：“我们周末能完成它！” 对于与死亡之旅项目相关的许多愚蠢决定，尽管管理层是一个方便的替罪羊，但技术人员也不是完全没有责任。实际上，在很多情况下，对复杂项目的进度和预算所做出的那些幼稚估算完全来自于技术人员，而高级管理人员只不过是高兴地接受了而已。“你认为这要花多长时间？”一个副总裁会这样询问技术骨干，而他很可能在上星期才刚刚被提升为第一级主管。 如果被问到的这个技术骨干并不了解实际情况，而且他还充满了朝气蓬勃的乐观主义(这与十几岁少年的错觉(自认为无所不能、无所不知)十分类似)，他的答案往往是：“没问题，我们也许这个周末就能把它搞出来！”真正优秀的软件工程师(或者用一个更恰当的词“黑客”)都非常相信自己只用一个周末就能开发出任何系统。然而，由于某些细节如此令人厌烦，例如文档、出错处理、用户输入编辑和测试等，所以他们并没有将它们考虑在内。 如果你就是那个充满了天真的乐观的软件工程师，虽然你负责死亡之旅估算，但很可能你甚至连自己在做什么都不知道。也许你已经读完了上一段话，而且对这种明显的侮辱感到非常愤怒，嘴里也在不停地嘟囔着：“当然是这样！我真的能用一个周末做出任何系统！”愿上帝保佑你；说不定你真的会成功。无论如何，从我这种老朽嘴中所说出的话永远都不可能改变你的主意。 然而，如果你是一个久经沙场的老手，而且你已经发现，由于一些年轻而幼稚的技术经理对项目的进度、预算和资源做出了过于乐观的承诺，自己将会被绑定在一个死亡之旅项目之上——此时你该怎么做呢？我认为最好的建议是：“三十六计走为上！”一旦发现自己陷入其中无法自拔，这些技术经理往往会彻底土崩瓦解，做出不理智的行为或陷于彻底停顿。在绝大多数情况下，他们从未处理过如此庞大与复杂的系统，因此也不知道仅凭单纯的聪明和匹夫之勇(例如，在周末进行 48 小时无间断的编码)根本无法应付。但无论如何，在项目落后于进度时，他们肯定没有心情听你说“我曾警告过你！”。 新公司的创业心理我不仅看到这种事情的发生，而且也参加过这样的项目，甚至有几次还曾负责这种项目的启动。在本书第一版付梓后不久，看起来任何新公司只要在公司或产品名称里带有“.com ”字样，就能比“确切知道要干什么”拿到更多的风险投资。然而，正如风险投资家和充满希冀的投资者逐渐看清的情况一样，刚刚起步的公司通常不但缺乏人手、经费和必要的管理，而且还对项目的成功存在着盲目的乐观。他们肯定会是这样：因为在准备了足够的资金和进行了大量的计划之前，谨慎、保守的经理永远都不会考虑启动一个新公司。 因此，根据定义，与刚起步的公司相关的项目大部分都属于死亡之旅项目。不仅如此，在这些项目中，大部分的项目最后都会以失败而告终，而这最终又会导致公司的消亡。这就是生活——高科技资本主义的全部含义都在于此(不仅仅是在美国，在全世界都是如此)。由于一生中对这种文化长期的耳濡目染，我认为这种现象再正常不过；当然，我的观点也被自己曾若干次成功完成这种项目的事实所影响。实际上，这种情形通常是启动死亡之旅项目的积极原因之一，下面将对此进行详细讨论。 然而，并不是每个人都熟知公司起步时的文化和环境。如果你已经在一个因循守旧的政府部门(或者在大多数的银行、保险公司和电话公司中)中使用僵化的 COBOL  工作了 20  年，而现在由于机构裁员、外包或重组而不得不在刚刚起步的公司求得一个职位，很可能你根本不知道自己要参加什么样的项目。虽然死亡之旅项目同样也会出现在大公司之中，但项目人员却大多来自公司外部。相比而言，在刚起步的公司中，死亡之旅项目的环境截然不同；它看起来更像是由纯粹的兴奋导致。 与此同时，刚刚起步的公司往往是前面所讨论的这种幼稚的乐观的受害者。许多这种公司都由狂热的技术人员所创建，这些创业者确信自己所使用的新技术将会让他们比比尔·盖茨还要更加富有；除此之外，其他这类公司则往往由销售天才创建，这些销售能手们自信能够卖掉任何商品，甚至能把因特网化电冰箱卖给轻信的爱斯基摩人。对刚刚起步的公司而言，虽然乐观的确非常重要，而且风险投资的成功也往往依赖于能够完成前人不能完成的事业，但即便是充满开拓精神和乐观主义的公司，其行动也必须遵守物理和数学的基本定律。因此，如果参加了一个新公司的死亡之旅项目，你一定要弄清楚行动到底是基于为了达到成功而进行的某些计划，还是基于完全一厢情愿的痴人说梦。  海军陆战队精神：真正的程序员无需睡眠 虽然刚刚起步的公司有时比较容易患上“海军陆战队”综合征，但根据我所看到的情况，这种症状最容易发生在类似 EDS 和 BigX7 这样的咨询组织中。这种“病症”很可能反映了企业创建者的个性和企业建立初期的文化，例如，微软的组织行为就经常被归因于这种因素。一般而言，经理会这样通知你：“每个项目都是这样做的，因为这就是我们这里的做事方法。它很有效，我们也因此获得了成功，我们真的为此自豪。如果你不能这样做，那么你就不属于我们这里。” 上面的观点是否有道理、人道或正确，需要进行单独的讨论。实际上，即便是它是否真的像宣称的那样成功也非常值得另加商榷；重要的是要认识到这种观点的出现并不是偶然的，而是深思熟虑之后的结果。如果你是一个为了信仰而甘愿牺牲自己的改革者，很可能你会决定攻击这种企业文化，但结果很可能会以失败而告终。这种全面的死亡之旅文化很可能还存在很多长期的负面影响，比如，最好的人才会慢慢流失，而公司最终会破产。但是，在当前这个死亡之旅项目到来时，你却不可能质疑项目为什么设定了几乎不可能的进度和预算目标。原因很简单，正像上面那个经理的典型言论：“如果不能这样做，那么你就不属于我们这里。” 有时，对这种企业行为也存在官方的解释，例如，“我们的市场竞争十分激烈，而且对手和我们一样聪明。要想脱颖而出，唯一的办法只能是付出加倍的努力。”另一些时候，启动死亡之旅项目的目的就是为了淘汰那些比较年轻(能力较差)的人，以便只有死亡之旅项目的幸存者们才能晋升到“合伙人”或“副总裁”这样的级别。然而，不管理由是什么，它通常都很公平；因此也很少出现针对个别项目的抱怨。 尽管如此，这并不意味着你必须接受这种项目；毕竟，组织里所有其他项目都是死亡之旅并不代表你肯定能成功完成此项目。它仅仅告诉我们：这样的一个项目有一个可以理解的启动原因。 市场全球化所导致的残酷竞争 很多组织过去并不能容忍死亡之旅项目的出现，但进入 21 世纪之后，由于市场全球化带来的竞争越来越激烈，他们被迫接受这种项目。当然，这也有第二个因素的影响：因特网和 Web 以及开放受保护市场或减免关税和配额的政府决策。 对于某些组织，这种现象并不新鲜；例如，从 20 世纪 70 年代起，汽车和电子工业就开始面临激烈的竞争。但对其他的组织来说，欧亚竞争对手在北美市场上的出现却实在不亚于一场剧烈的地震。一旦高级管理人员认识到将要面对的残酷竞争，他们往往会采取不同的极端措施来应对，方式从裁员到将业务外包给世界其他国家，不一而足；除此之外，他们也很可能决定采用一种新产品或新服务来迎接竞争，而这需要建立一种全新而富有挑战性的系统提供支持。乌拉！又一个死亡之旅类型的项目开始了。 与这种全球化现象相关的一个最新形式是将软件开发项目外包给位于印度、中国、俄国或其他国家的海外公司。通过访问多个国家的软件组织，我可以证实这些公司通常并不是热衷于死亡之旅(要求程序员以每周 7 天、每天 16 个小时的强度进行工作)的苦工作坊。不过，由于这些低成本海外软件开发资源的存在，国内软件公司和 IT 部门很可能将被迫要求美国境内这些薪水相对较高的员工工作更长的时间。正如一位读者在最近发给我的电子邮件中所指出的： “我预计情况正在变得越来越糟。为了大量削减成本，将软件开发工作外包给海外的趋势正愈演愈烈，而剩余的国内软件公司将遭受巨大的价格竞争压力。可行的竞争方法只有一个：第一个将产品投入市场，同时削减成本。‘死亡之旅’很可能将成为许多公司的标准过程。经济状况的改善并不会改变这些市场现实。” 由于出现新技术而引发的激烈竞争虽然市场扩大引起的竞争通常被看成一个防御问题，但它也能被看成一个主动发挥积极性的时机——例如，“如果采用双字节字符来构建这种新系统，我们的产品就能销往日本市场”。与此类似，如果一家公司对采用较老技术生产的产品感到相当满意，这时引进一种进行了根本革新的技术很可能会引发一场抵制活动；但是，为了在竞争中取胜，公司很可能决定采用这种新技术。在此书正在编写的时候，类似无线计算和 Web 服务的技术就是这种现象的明显实例；但对于我们的工业来说，真正令人惊奇的是每过几年就会出现全新的例子。 如果公司对新技术完全是抵制性的反应，那么死亡之旅项目的目标就很可能是力图使旧技术超越其正常情况下所能达到的极限。因此，如果由于以往对老技术(或与其相关的基础设施)的投资过大而无法完全放弃它，那么公司就很可能决定重新编写原有系统，但却会要求开发人员设法将其速度和魅力提高 10 倍。 许多这种类型的死亡之旅项目都包括对新技术的首次使用。请回想自己组织内实施的第一个客户机——服务器项目、面向对象项目、关系数据库项目或者因特网 /Java 项目的情况；在它们中，部分项目只是为了发现新技术的潜在收益而做的适当实验，但部分项目很可能是为了与那些使用相同技术的公司进行竞争。在后一种情况下，这些项目不但进度和预算极其紧张，而且其规模可能非常庞大。 但真正使这种项目属于死亡之旅类型的原因，除了显而易见的规模、进度和预算特征之外，是试图在工业强度的应用程序中使用尖端技术。即便这种技术目前已经基本可用，但它的扩展性往往也较差，并不适于大规模应用；不仅如此，此时往往也没有人知道如何对其取长补短；而且供货商也不知道如何才能正确提供售后服务；而且…… 尽管年长的技术人员(那些还记得 FORTRAN  Ⅱ和汇编语言过去黄金岁月的人们)很可能将所有这些都当做一段不愉快的经历，但重要的是不要忘记项目经理和年轻气盛的工程师们往往会选择使用这些新技术，因为它们都很新。而这些人正是上面提到的那些对自己的进度和预算限制充满了幼稚的乐观的人。当所有人在深夜和周末还在努力将实验性的新技术或多或少地加入到工序之中时，还会有人对项目已经变成一场死亡之旅产生怀疑吗？ 不可预期的政府法令所导致的巨大压力 如前所述，死亡之旅项目的发生与市场全球化相关的原因之一是因为政府权力机构决定减少关税、消除进口配额和“开放”原先关闭的市场。但这仅仅是政府影响导致死亡之旅项目的例子之一；而放开原先受控制的行业与政府机构私有化是另 2 个明显的例子。事实上，今天发生的许多死亡之旅项目都是政府决定放开通信、金融服务、航空等行业的结果。 然而，在其他很多情况中，政府权力机构都增大了规章监管力度，特别是在税收、向股票监管机构报告详细财务信息、环境法规等方面。在任何民主社会实行这种法规之前，由于立法机构对细节的辩论和争执通常很可能都要历时数月乃至数年之久，因此事先都会有大量预兆出现。然而，细节往往只有在最终才能清晰地呈现出来，而且高级管理人员通常也会采用“在整个事情不可避免之前根本不去理睬它”的对策。随后，轰隆隆！又一个死亡之旅项目出现了。 对于许多由于政府强制而导致的死亡之旅项目而言，最为棘手的因素是最后期限：新系统必须在某一日期之前投入运行(例如在元旦之前)，否则就会导致每天数百万美元的罚款。虽然申请延期或放弃并不是完全没有可能，但在绝大多数情况下，最后期限往往不能更改。一旦新系统不能按时就位，最后的结果对组织来说往往就是与上述情况类似的可怕景象：裁员、破产或者其他不幸。 请注意，在这样的项目中，技术往往不是问题的关键；它之所以成为死亡之旅完全是因为进度过于紧张。当然，高级管理人员有时会使情况复杂化：或者给项目分配的人员不足，或者给项目分配的预算不足，结果导致项目停滞不前。 出乎意料和/或未经计划的危机 你手下最好的两个程序员刚刚走进你的办公室，通知了你如下信息：( a )他们刚刚结婚；( b )刚刚加入了要在非洲丛林中建造医院的传教团体； (c) 今天是他们的最后一个工作日。或者，你的网络服务经理刚刚通知你：你的供货商已经破产，为了使用另一家供货商的网络协议，你必须在随后的 30 天内重新编写所有的程序。或者，你的法律部门打电话告诉你：由于没有遵守神秘的无人知晓的法规 Q 的第 13 ( b )条款，公司已经被起诉，而且被要求支付巨额赔偿。 当然，你可以这样争辩：在良好管理的公司中，两个最佳程序员的离职不但应该事先被预料到，而且应该制订出相应计划；你不会愚蠢到完全依赖一个通信供货商；管理层应该早已富有远见地事先检查过法规 Q 的具体细节。对于纯粹主义者而言，以上这些危机完全是计划和管理不足的后果；因此“未经计划的危机”是一个复杂的情况。 也许真是如此；但从实用的角度出发，对于商业世界中可能发生的所有疯狂事件，进行预计并制订相应计划的工作正在变得越来越困难。无论好坏，我们生活的世界都充满了混沌，而死亡之旅项目正是这种混沌的自然产物 9 。事实上，即便已经预知在将来会出现混沌之事，但在其发生时我们很可能还是不得不使用死亡之旅的方式进行应对。例如，在加州圣安德鲁斯附近，尽管每个人都清楚地知道剧烈的地震迟早会发生；但当地震来临并将整个州的西半部送入太平洋时，人们仍然在使用死亡之旅的方式来应付灾难。 实际上，即便我们知道危机将要发生的精确时间，但它带来的往往依旧是死亡之旅，因为管理层总是喜欢在迫在眉睫时才进行处理。如果不是这样，我们又怎么解释在千年虫问题迫近时，许多 IT 组织内不断蔓延的恐慌？我们很早就知道 2000 年 1 月 1 日正在到来，也非常清楚这个最后期限无法推迟。不仅如此，我们还精确地知道问题的实质，明白解决它并不需要 Java 那样刚刚被发明的技术。既然如此，那为什么会有如此众多的死亡之旅项目在 1998 年和 1999 年中被启动？ 无论如何，未知危机能够导致所有类型的死亡之旅项目。在最坏的情况下，它会导致将最后期限被设定为“昨天，如果不能更快的话”的项目——因为危机业已发生，而且在解决相应问题的新系统被安装之前情况会日益恶化。在其他情况下——比如关键项目人员突然离职、由于危机导致人力缺乏或关键智力资源流失，原本合理的项目最终也将被变成一场死亡之旅。 出于不同的理由，这些通常是最糟的死亡之旅项目类型，因为没人能够预测到项目最终会走上这条道路。在上面讨论过的“海军陆战队”情况之中，并没有任何出乎意料的事情发生：从第一天起，项目中每个人都非常清楚此项目将像以前所有的项目一样，需要付出特别的努力。对于“刚启动的公司”这种情况，人们预期死亡之旅项目中将充满了刺激；不仅因为它将令人激动和充满挑战，而且因为它一旦成功，所有人都会因此而成为富有一族。 本文节选自死亡之旅(原书第2版)， 周浩宇 杨华 译，由机械工业出版社发行。