基本信息

编辑推荐

内容简介

目录

译者序

前言

基本信息

作者： (美)Edward Yourdon [作译者介绍]

译者： 周浩宇 杨华出版社：机械工业出版社

ISBN：9787111359982

上架时间：2011-11-8

出版日期：2012 年1月

开本：16开

页码：1

版次：2-1

编辑推荐

本书第2版包含的全新内容和相关内容更新如下：

·将死亡之旅项目转化为“不可能完成的任务”类型项目

·项目状态谈判：在恶劣环境中得到最佳结果

·极限编程（XP）、敏捷方法与死亡之旅项目

·团队时间管理：消除导致项目脱轨的干扰因素

·“关键链进度计划排定”：识别和消除组织故障

·预测“压垮骆驼的最后一根稻草”：系统动力学的教训

·如何根据自身环境选择最可能有效的工具和方法

·项目“飞行模拟器”：演习你的下一个项目

·通过“选择”交付最重要的功能和特性

·何时应该“放手离去”

内容简介

《死亡之旅（原书第2版）》对各种“死亡之旅”项目进行了全面而系统的剖析，涵盖整个项目的生命周期，深刻分析了这种现象的本质，并讨论项目参与者所面临的所有关键问题：政治、谈判、人员、过程、项目管理，以及工具，提供了行之有效的解决方法和行动指南。本书不但有助于快速识别死亡之旅项目，而且能够大大提高从死亡之旅中生还的概率。

无论是软件开发人员、管理人员，乃至各行各业的项目经理、cxo，都能从本书受到启发，并找到现实而适用的解决方案。

目录

死亡之旅（原书第2版）》

译者序

前言

第1章 绪论

1.1 死亡之旅的定义

1.2 死亡之旅项目的分类

1.3 为何会出现死亡之旅项目

1.3.1 政治，政治，还是政治

1.3.2 市场人员、高级管理人员、缺乏经验的项目经理等人所做出的幼稚承诺

1.3.3 年轻人天真的乐观主义：“我们周末能完成它！”

1.3.4 新公司的创业心理

1.3.5 海军陆战队精神：真正的程序员无需睡眠

1.3.6 市场全球化所导致的残酷竞争

1.3.7 由于出现新技术而引发的激烈竞争

1.3.8 不可预期的政府法令所导致的巨大压力

1.3.9 出乎意料和/或未经计划的危机

1.4 人们为什么参加死亡之旅项目

1.4.1 虽然风险很高，但回报也很高

1.4.2 珠峰综合征

1.4.3 年轻人的天真和乐观

.1.4.4 不做就要失业

1.4.5 未来获得提升的必要条件

1.4.6 不做就要面临破产或其他不幸

1.4.7 一个突破旧条条框框的机会

1.4.8 报复

1.5 小结

注解

第2章 政治

2.1 确定项目所涉及的政治“玩家”

2.1.1 业主

2.1.2 用户

2.1.3 持股人

2.1.4 干系人

2.1.5 支持者

2.2 确定项目的基本类型

2.3 项目参与者的承诺程度

2.4 导致政治争执的关键问题

2.5 小结

注解

第3章 谈判

3.1 理智的谈判

3.2 识别可接受的折中

3.3 谈判游戏

3.4 谈判策略

3.5 谈判失败后应该做什么

注解

参考文献

第4章 死亡之旅项目中的人员

4.1 雇用和人员配备问题

4.2 忠诚、承诺、激励和奖赏

4.2.1 奖励项目团队成员

4.2.2 加班问题

4.3 沟通的重要性

4.4 团队建设问题

4.5 死亡之旅项目的工作场所条件

4.6 小结

注解

参考文献

第5章 死亡之旅的过程

5.1 分类概念

5.2 需求管理的重要性

5.3 sei、iso—9000、形式化过程与非形式化过程

5.4 “足够好”的软件

5.5 最佳实践和最差实践

5.6 当死亡之旅遭遇xp

5.7 小结

注解

参考文献

第6章 动态的过程

6.1 软件开发过程模型

6.1.1 思维模型

6.1.2 电子表格模型

6.1.3 静态模型与动态模型

6.2 可视化模型

6.3 示例：tarek abdel?hamid的软件过程模型

6.4 小结

注解

参考文献

第7章 关键链进度排定和约束理论

7.1 介绍

7.2 什么样的组织行为是紊乱的

7.3 如何才能改变紊乱的组织行为

7.4 理智世界中的行为

7.5 关键链进度排定

7.6 小结

注解

参考文献

第8章 时间管理

8.1 企业文化对时间管理的影响

8.2 股东争执所浪费的时间

8.3 帮助项目团队更好地利用时间

注解

第9章 管理和控制项目进展

9.1 “天天做”概念

9.2 风险管理

9.3 对进展监控的额外建议：里程碑评审

注解

参考文献

第10章 工具和技术

10.1 最小工具集

10.2 工具和过程

10.3 选择新工具的风险

10.4 小结

注解

参考文献

第11章 模拟器和“军事演习”

11.1 介绍

11.2 军事演习概念

11.3 小结

注解

参考文献

译者序

古语云：“温故而知新。”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的话：