死亡之旅读后感精选

　　《死亡之旅》是一本由Edward Yourdon著作，机械工业出版社华章公司出版的平装图书，本书定价：49.00元，页数：243，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《死亡之旅》精选点评：

　　●非常有助于在项目里爬坑，挽救兄弟们于水火之中，强烈推荐

　　●作者的直言不讳令人印象深刻，简直就是软件界的马基亚维里。

　　●每个做IT的人都应该读一读的书

　　●内容很直接，贴近现实

　　●血泪之作+1 区分什么是死亡之旅, 尽量不要被卷进去, 卷进去以后不要过多指望技术手段, 政治手段可能会更有效

　　●作为领导应该考虑的问题，今后在来关注。

　　●不可不读的经典，让我不再幼稚和盲目乐观，作者对软件工程看得很透彻。

　　●那次从西安飞回来的时候，为了打发飞机上的时间在西安买的书，没打折！！！但是内容也不打折！！！

　　●挺实在的一本书，没有鼓吹那些高大上的东东，都是实实在在的血泪凝结的经验之谈。

　　●慕Yourdon大名

　　《死亡之旅》读后感(一)：一本不错的项目管理入门书籍

　　对项目管理不了解，因为随手从图书馆借了这本书。

　　与起来借来的书籍相比，这本书有意思得多。

　　比较真实吧。一些项目管理的入门书籍，说得很宽泛，有些还很文艺。但这这类型的书只要一本就够了。而这本书会介绍比较真实的“死亡之旅”的情况。对工作也很有帮助。

　　很多内容，会道出工作中的关键之处，可以马上就用到自己的工作中来。

　　《死亡之旅》读后感(二)：項目經理和程序員要看

　　這首先是一本教讀者審時度勢的書。對於一個死亡之旅的項目，如何去判定？看項目發起人，項目發起的背後真正原因。遭遇這樣的項目時，是戰還是離？“具體情況具體分析”，看你的上司是誰，是一個什麽樣的人，這是一什麽樣的項目，神風特攻隊？自殺還是醜陋的？還是？

　　決定留下來，一定要明確真正的目標和真正的需求，要與干系人談判、溝通、發佈這個目標。這個目標會遭到很多人和因素的干擾，項目經理就要排除這種干擾。需求是可以分類的，變化的、動態的，要捕捉它。

　　死亡之旅的目標是在有限的資源（時間、人力、技術、資源）下，完成可用的交付，而不是過程。任何不能促使這個目標實現的活動、技術，都是不值得採用的。

　　團隊的形成是有規律的，是一個動態的，追求的是“動態平衡”。團隊的產出率有其上限，“人月神化”是不存在的。

　　《死亡之旅》读后感(三)：迎难而上的技巧

　　最近很流行美国大学的哲学课程，死亡啦，幸福啦，在书店乍一看到，还以为是这一类的书呢。《死亡之旅》并不是讲那些终极问题的，而是把它落实到具体的生活中，就是那些令人抓狂的项目及其管理上。

　　软件开发项目是越来越多了，“死亡之旅”类型的项目也愈发的多起来了。死亡之旅的项目有诸多细分的类型，也有不同的原因所导致。有的是管理层的一意孤行，有的是年轻工程师团队的自掘坟墓，有的是突如其来的危机导致，有的则是灭亡前的最后一搏。

　　总体来说，对于理性的个人而言，此类“死亡”项目还是“避之则吉”。但是，最后参与其中的，又都各有各的理由。离职的成本太高，要出一口恶气，妄图一战成名，或者是光荣的最后一搏。其实有着众多的理由让人参与其中。

　　那么一旦踏上了旅程，那就全力想着，怎么能活下来。《死亡之旅》这是很好的求生指南，特别对项目经理而言。

　　政治上的沟通自然要顺畅，还要找到靠山，不然要啥没啥，和等死没啥区别。

　　各种谈判自然力所能及的去讨价还价，总要死的不是那么难看才好。

　　挑选成员，必然是要能同心协力的，共赴黄泉的。不然有人脚底抹油，必然有人死无全尸。所谓不怕神一样的对手，就怕猪一样的队友。

　　在开发的过程中，有些工具要好好采用，例如XP，最佳实践，但是务必要有趁手的家伙。有些工具看上去锃亮，拾起来却不顺手，最后让人拿西瓜刀给切了。

　　关键任务的安排和良好的时间管理在“死亡之旅”中更显重要。争分夺秒，运筹帷幄，才可能绝处逢生。

　　当我刚刚开始阅读此书的时候，我以为是教大家如何识别死亡之旅，并且脚底抹油的。读到后来才明白，原来是让我们迎难而上的。在这不靠谱的世界里，忽悠是多么的重要。但是在忽悠的同时也有有真材实料，否则只能忽悠致死了。

　　《死亡之旅》读后感(四)：读《死亡之旅》

　　在软件工程的图书中，《死亡之旅》是本相当奇特的书。它并没有讲一个软件工程方法，而是在讲一种软件工程实施中的现象。

　　“死亡之旅”（Death March或者译为“死亡行军”）项目是这样一种现象：在软件开发中，软件要素的制约与软件目标存在一倍及以上的差距。这些要素可能包括人才、时间等方面。如果你接到了一个需要一个5人团队半年时间才能完成的项目，却被要求三个月完成。这个时候，你的团队就在死亡行军了。在这本书中，作者对死亡之旅现象产生的原因、环境以及身处死亡之旅项目中的人的种种遭遇、困难、行为都有介绍。

　　为什么会产生这种死亡之旅项目？

　　这个话题就足够讨论很长时间，书中也讨论了很多可能的原因。结合我个人的项目经历，我认为现实环境中最容易出现的原因是管理层的盲目自大，还有一线开发者没有话语权。从某种层面来说，这两种原因通常都会同时出现。管理层永远都是容易盲目乐观的，特别是进行内部管理时。由于身处高位，他们都通常更容易获得来自中层管理者的过多乐观汇报。如果管理者自认为曾经从事过基层技术工作，那就更容易自认为对技术了如指掌，一切都尽在掌握。“找你们几个低效的程序员来搞只是因为老子没时间”。实际上项目的复杂度总是比从外面看上去更高的。一个简单的原因是一个系统需要应付所有可能的输入，甚至异常情况。而外观上人们只能看到简单的关键路径。对于习惯了在线付款的你根本看不到支付系统在背后为多少种信用卡异常编写了代码，因为你可能一辈子也遇不上数据库异常回滚。所以，一个技术出身的领导者更容易作出愚蠢的决定，确信那些明显脱离实际的项目资源评估。因为他们像其他高管一样乐观，却比其他高管更自信，所以，很多“悲剧”就上演了。

　　对于书中提到的其他客观因素，我倒不太认为会很严重得引发死亡之旅项目。企业的竞争压力确实在增加，但如果意识到这是个死亡之旅项目，理智的高管也不太可能做出决定，因为这很有可能导致投资损失，并且耽误那些本可以争取到的市场机会。当然，如果由于政治原因做出决定，除了自认倒霉没有任何话好说。

　　如果不幸遇到死亡之旅项目，作为项目经理或者一线研发工程师，你还有什么可选择吗？

　　走为上计。我认为书中提出这个方案是很严肃的。出现这种很不理智的决定本身已经说明了整个组织存在着过于草率或者不够客观的决策，存在着很大的风险。如果确实出现了这样的问题，一走了之没什么不好，只是很多时候我们走不了。

　　挺过难关。这是最常见的一个选择。一般情况下，作为下属，无奈得忍受上级决定已经成为习惯。你可以有一些可选择的方案来减少困难。例如对一些项目的不重要因素降低要求；想办法激励团队或提供更高待遇。（换几个更有效率的工程师？申请独立的工作环境？提高团队伙食？）在死亡之旅的路上，除了路途中的艰难，还有可怕的终点审判。要学会通过一些方式让管理层更好地接受这个结局，也是挺过死亡之旅的关键因素。

　　还有第三种选择吗？也许有，但是幸运的人毕竟是少数。软件开发是一个有伸缩性的工作，核心的制约是开发人员的工作效率。如果有办法通过所有可能的方式提升开发效率，甚至在总体上提升一倍，那么你就真正赢得了死亡之旅的全程！有哪些因素可以考虑？

　　减少开发人员的无关工作（填写毫无意义的工作报告；减少开发人员被邮件和电话打断的机会）

　　在制度和团队风格上打消成员的内心障碍（例如“反正要加班，不如白天少干点”）

　　切实得激励团队成员，让大家忘掉项目的不明朗前景

　　识别项目障碍并小心引入工具

　　真的会有将团队生产力提高一倍的可能吗？是有的，但机会不多。团队的改进空间有限，在巨大的压力下又不能付出过多的学习成本，所以希望不大。同时，加班和工具对提升团队产出的影响也不可能达到如此大的比例（想想老生常谈的“没有银弹”）。

　　所以想摆脱死亡之旅项目真正的希望还是要靠更了解软件工程规律的管理层和决策体系，更有说服力的评估方法和敢于指出问题的组织氛围。

　　同步发表在我的博客 http://hi.baidu.com/thinkradar/item/84a588936fe0771f336eeb5b