读《死亡之旅》
这篇书评可能有关键情节透露
在软件工程的图书中，《死亡之旅》是本相当奇特的书。它并没有讲一个软件工程方法，而是在讲一种软件工程实施中的现象。
“死亡之旅”（Death March或者译为“死亡行军”）项目是这样一种现象：在软件开发中，软件要素的制约与软件目标存在一倍及以上的差距。这些要素可能包括人才、时间等方面。如果你接到了一个需要一个5人团队半年时间才能完成的项目，却被要求三个月完成。这个时候，你的团队就在死亡行军了。在这本书中，作者对死亡之旅现象产生的原因、环境以及身处死亡之旅项目中的人的种种遭遇、困难、行为都有介绍。
为什么会产生这种死亡之旅项目？
这个话题就足够讨论很长时间，书中也讨论了很多可能的原因。结合我个人的项目经历，我认为现实环境中最容易出现的原因是管理层的盲目自大，还有一线开发者没有话语权。从某种层面来说，这两种原因通常都会同时出现。管理层永远都是容易盲目乐观的，特别是进行内部管理时。由于身处高位，他们都通常更容易获得来自中层管理者的过多乐观汇报。如果管理者自认为曾经从事过基层技术工作，那就更容易自认为对技术了如指掌，一切都尽在掌握。“找你们几个低效的程序员来搞只是因为老子没时间”。实际上项目的复杂度总是比从外面看上去更高的。一个简单的原因是一个系统需要应付所有可能的输入，甚至异常情况。而外观上人们只能看到简单的关键路径。对于习惯了在线付款的你根本看不到支付系统在背后为多少种信用卡异常编写了代码，因为你可能一辈子也遇不上数据库异常回滚。所以，一个技术出身的领导者更容易作出愚蠢的决定，确信那些明显脱离实际的项目资源评估。因为他们像其他高管一样乐观，却比其他高管更自信，所以，很多“悲剧”就上演了。
对于书中提到的其他客观因素，我倒不太认为会很严重得引发死亡之旅项目。企业的竞争压力确实在增加，但如果意识到这是个死亡之旅项目，理智的高管也不太可能做出决定，因为这很有可能导致投资损失，并且耽误那些本可以争取到的市场机会。当然，如果由于政治原因做出决定，除了自认倒霉没有任何话好说。
如果不幸遇到死亡之旅项目，作为项目经理或者一线研发工程师，你还有什么可选择吗？
走为上计。我认为书中提出这个方案是很严肃的。出现这种很不理智的决定本身已经说明了整个组织存在着过于草率或者不够客观的决策，存在着很大的风险。如果确实出现了这样的问题，一走了之没什么不好，只是很多时候我们走不了。
挺过难关。这是最常见的一个选择。一般情况下，作为下属，无奈得忍受上级决定已经成为习惯。你可以有一些可选择的方案来减少困难。例如对一些项目的不重要因素降低要求；想办法激励团队或提供更高待遇。（换几个更有效率的工程师？申请独立的工作环境？提高团队伙食？）在死亡之旅的路上，除了路途中的艰难，还有可怕的终点审判。要学会通过一些方式让管理层更好地接受这个结局，也是挺过死亡之旅的关键因素。
还有第三种选择吗？也许有，但是幸运的人毕竟是少数。软件开发是一个有伸缩性的工作，核心的制约是开发人员的工作效率。如果有办法通过所有可能的方式提升开发效率，甚至在总体上提升一倍，那么你就真正赢得了死亡之旅的全程！有哪些因素可以考虑？
减少开发人员的无关工作（填写毫无意义的工作报告；减少开发人员被邮件和电话打断的机会）
在制度和团队风格上打消成员的内心障碍（例如“反正要加班，不如白天少干点”）
切实得激励团队成员，让大家忘掉项目的不明朗前景
识别项目障碍并小心引入工具
真的会有将团队生产力提高一倍的可能吗？是有的，但机会不多。团队的改进空间有限，在巨大的压力下又不能付出过多的学习成本，所以希望不大。同时，加班和工具对提升团队产出的影响也不可能达到如此大的比例（想想老生常谈的“没有银弹”）。
所以想摆脱死亡之旅项目真正的希望还是要靠更了解软件工程规律的管理层和决策体系，更有说服力的评估方法和敢于指出问题的组织氛围。
同步发表在我的博客 http://hi.baidu.com/thinkradar/item/84a588936fe0771f336eeb5b
“死亡之旅”（Death March或者译为“死亡行军”）项目是这样一种现象：在软件开发中，软件要素的制约与软件目标存在一倍及以上的差距。这些要素可能包括人才、时间等方面。如果你接到了一个需要一个5人团队半年时间才能完成的项目，却被要求三个月完成。这个时候，你的团队就在死亡行军了。在这本书中，作者对死亡之旅现象产生的原因、环境以及身处死亡之旅项目中的人的种种遭遇、困难、行为都有介绍。
为什么会产生这种死亡之旅项目？
这个话题就足够讨论很长时间，书中也讨论了很多可能的原因。结合我个人的项目经历，我认为现实环境中最容易出现的原因是管理层的盲目自大，还有一线开发者没有话语权。从某种层面来说，这两种原因通常都会同时出现。管理层永远都是容易盲目乐观的，特别是进行内部管理时。由于身处高位，他们都通常更容易获得来自中层管理者的过多乐观汇报。如果管理者自认为曾经从事过基层技术工作，那就更容易自认为对技术了如指掌，一切都尽在掌握。“找你们几个低效的程序员来搞只是因为老子没时间”。实际上项目的复杂度总是比从外面看上去更高的。一个简单的原因是一个系统需要应付所有可能的输入，甚至异常情况。而外观上人们只能看到简单的关键路径。对于习惯了在线付款的你根本看不到支付系统在背后为多少种信用卡异常编写了代码，因为你可能一辈子也遇不上数据库异常回滚。所以，一个技术出身的领导者更容易作出愚蠢的决定，确信那些明显脱离实际的项目资源评估。因为他们像其他高管一样乐观，却比其他高管更自信，所以，很多“悲剧”就上演了。
对于书中提到的其他客观因素，我倒不太认为会很严重得引发死亡之旅项目。企业的竞争压力确实在增加，但如果意识到这是个死亡之旅项目，理智的高管也不太可能做出决定，因为这很有可能导致投资损失，并且耽误那些本可以争取到的市场机会。当然，如果由于政治原因做出决定，除了自认倒霉没有任何话好说。
如果不幸遇到死亡之旅项目，作为项目经理或者一线研发工程师，你还有什么可选择吗？
走为上计。我认为书中提出这个方案是很严肃的。出现这种很不理智的决定本身已经说明了整个组织存在着过于草率或者不够客观的决策，存在着很大的风险。如果确实出现了这样的问题，一走了之没什么不好，只是很多时候我们走不了。
挺过难关。这是最常见的一个选择。一般情况下，作为下属，无奈得忍受上级决定已经成为习惯。你可以有一些可选择的方案来减少困难。例如对一些项目的不重要因素降低要求；想办法激励团队或提供更高待遇。（换几个更有效率的工程师？申请独立的工作环境？提高团队伙食？）在死亡之旅的路上，除了路途中的艰难，还有可怕的终点审判。要学会通过一些方式让管理层更好地接受这个结局，也是挺过死亡之旅的关键因素。
还有第三种选择吗？也许有，但是幸运的人毕竟是少数。软件开发是一个有伸缩性的工作，核心的制约是开发人员的工作效率。如果有办法通过所有可能的方式提升开发效率，甚至在总体上提升一倍，那么你就真正赢得了死亡之旅的全程！有哪些因素可以考虑？
减少开发人员的无关工作（填写毫无意义的工作报告；减少开发人员被邮件和电话打断的机会）
在制度和团队风格上打消成员的内心障碍（例如“反正要加班，不如白天少干点”）
切实得激励团队成员，让大家忘掉项目的不明朗前景
识别项目障碍并小心引入工具
真的会有将团队生产力提高一倍的可能吗？是有的，但机会不多。团队的改进空间有限，在巨大的压力下又不能付出过多的学习成本，所以希望不大。同时，加班和工具对提升团队产出的影响也不可能达到如此大的比例（想想老生常谈的“没有银弹”）。
所以想摆脱死亡之旅项目真正的希望还是要靠更了解软件工程规律的管理层和决策体系，更有说服力的评估方法和敢于指出问题的组织氛围。
同步发表在我的博客 http://hi.baidu.com/thinkradar/item/84a588936fe0771f336eeb5b
