灾难拯救

出版时间：2012-6  出版社：电子工业出版社  作者：本拿塔  页数：259  字数：294000  
Tag标签：无  

前言

　　前言　　几年前，我听了这样一个故事。一个俄国人、一个法国人、一个日本人和一个美国人不幸被食人族抓住了。在被扔进沸水锅之前，酋长告诉他的俘虏，每人可提一个请求，而他会满足他们在这世上的最后要求。　　俄国人请求喝最后一杯伏特加，法国人请求让一位年轻的本地姑娘给他最后一吻，日本人说他请求做最后一次关于质量的演讲。最后轮到了美国人说自己的请求，他说：“请先把我扔进沸水锅吧，这样我就不必再听一次关于质量的演讲了！”　　什么事都要讲个时机和场合。当一个软件项目陷入严峻的困境时，软件开发机构最想听到的是他们应怎样扭转败局，使项目进行下去。然而此时，并没有可遵循的PMI、IEEE、SEI或ISO标准帮助他们拯救项目。PMI、IEEE、SEI和ISO这些组织提供了预防项目失败的方案，而没有提供拯救项目于危难的办法。当项目迫近“被扔入沸水锅”的结局之时，它最后的请求是“救我”，而不是“再告诉我一次如何避免陷入困境”。　　本书是一本“救治”之书。本书探讨了如何拯救面临失败的软件项目使之回到正轨，虽然其中也偶有内容论及灾难预防。本书描述了拯救（或解救）面临失败的软件项目（或称软件项目灾难）的10个步骤。本书有广泛的目标读者群，包括软件开发人员、项目经理、高级管理人员以及软件项目利益攸关者（同软件项目之间存在很大利益关系的人）。　　本书也旨在成为一本教材。在本书每一章的末尾，都有本章小结，并提供了习题。　　本书中有的内容要求读者具备一些软件工程知识，不过这样的内容很少，具备软件工程知识并不是使用本书的必要条件。本书对于缺少管理知识的软件工程师和对于缺少软件开发知识的项目管理人员一样有用。　　本书共包括13章：　　第1章为绪论。本章介绍了灾难拯救的概念，探讨了软件项目何时需要拯救行动的介入。在本章中，还对本书中使用的几个基本术语进行了阐释。　　第2章论述了判断项目灾难来临的方法。对于遇到麻烦的项目来说，本章是决定是否需要对它采取后面各章中描述的拯救步骤的一章。　　第3章至第12章描述了灾难拯救过程的10个步骤（每章描述一个步骤）。　　第13章为结束语，标题是“把最后的拼图放入位置”。在本章中，有些内容是关于灾难预防的。本章综览之前各章描述的10个步骤，并阐述了如何进行时间安排以使全部拯救过程在两周时间里完成。　　本书所介绍的拯救过程中，很多步骤之间存在交叠，且每一步骤都依赖于它前面的步骤，因此，本书不适合随兴翻到哪里看哪里、“东一榔头西一棒槌”的阅读方式。如果读者从头到尾地了解了整个拯救过程，就更容易理解每个拯救步骤。因此，强烈建议您在实施拯救过程之前从头到尾学习本书全部内容。不过，您也不必因为我的上述建议而气馁，本书每一章都有“本章小结”，您可以仅仔细阅读与正在实施的拯救步骤有关章节而对其他各章只阅读“本章小结”的简化方式来学习。　　本书内容偏重实践而非理论。本书在介绍很多方法和技术时，并未说明其理论基础。不过，本书中提供了大量的参考书目，以飨对理论背景感兴趣的读者。参考书目信息见本书末尾部分。　　在本书出版之前，有一些关于项目灾难局面能否扭转的讨论，也就是说，当我们想拯救一个项目的时候，将这个项目称为灾难是否合适。对于任何一名在大型技术公司工作过并听到过某位沮丧的高级经理说“这个项目是个灾难！”的人来说，答案都是很明显的。如果灾难局面不可扭转，那么，项目在彼时彼地就会被放弃了，但是，高级经理接下来通常会说的是：“我们需要马上使它回到轨道！”是的，这正是本书所要论述的。　　我在摩托罗拉公司和其他一些技术公司从事了多年的软件项目管理工作，并对数百家软件开发机构的软件项目开发数据进行了收集和分析，这是形成本书中“拯救”概念的基础。在本书之前，我曾写过一篇同名的论文，这篇论文发表在了美国国防部出版的软件工程期刊CrossTalk上。　　感谢埃米尔（Amir）在本书问世过程中给予的极大帮助，他的贡献和评论是无价的。　　E. M. Bennatan　　2006年1月

内容概要

　　Jolt大奖素有“软件业之奥斯卡”的美称，本丛书精选自Jolt历届获奖图书，以植根于开发实践中的独到工程思想与杰出方法论为主要甄选方向。本书是作者在几十年软件项目管理实践经验的基础上写成的，从软件项目是否需要拯救的判断到具体拯救的步骤，面面俱到，为拯救陷入灾难的软件项目提供了一套易理解且便于操作的有效方法。

作者简介

作者：（美国）本拿塔（Bennatan E.M.） 译者：侯艳飞，侯玉芳，李萌  本拿塔，E.M.Bennatan拥有丰富的管理实战经验。这些经验源自他在摩托罗拉公司多年担任高级主管的经历。在任期间，他带领团队开发了很多大型软件系统，并领导过多个跨国设计中心。他还曾是米德威公司（Midway Company）的工程副总裁，任职期间管理着数百名软件和硬件工程师。Bennatan先生经常在软件项目管理方面做演讲。他还是《在预算范围内按时完成：软件项目管理、实践和技术（第三版）》（On Time Within Budget:Software Project Management,Practices and Techniques,Third Edition）一书的作者。Bennatan先生目前是先进项目解决方案公司的总裁以及波士顿Cutter联合公司（Boston Cutter Consortium）的高级顾问。

书籍目录

第1章 绪论
 1.1 灾难拯救过程概述
 1.1.1 案例研究
 1.1.2 做出拯救决定
 1.1.3 拯救过程
 1.2 一些调查数据
 1.3 一些提示
 1.4 本章小结
第2章 确定项目是否陷入灾难
 2.1 进度
 2.1.1 设置进度警报器
 2.1.2 调整进度警报器
 2.1.3 监视延长后的时间表
 2.2 预算
 2.2.1 设置预算警报器
 2.2.2 其他需考虑的事项
 2.3 质量
 2.3.1 问题列表警报器
 2.3.2 顾客满意度警报器
 2.4 学会利用经验
 2.5 本章小结
 习题
第3章第1步——停止
 3.1 停止项目
 3.1.1 为什么停止项目
 3.1.2 谁来停止项目
 3.1.3 项目停止程序
 3.2 准备下一步
 3.3 开展团队行动
 3.4 处理反对意见
 3.5 可能出现哪些问题及如何解决
 3.6 本章小结
 习题
第4章第2步——选定评估者
 4.1 该选谁——合格评估者的素质要求
 4.2 案情陈述
 4.2.1 应包含的内容
 4.2.2 管理者的承诺
 4.2.3 评估者的承诺
 4.3 大型软件项目
 4.4 可能出现哪些问题及如何解决
 4.5 本章小结
 习题
第5章第3步——评估项目现状
 5.1 评审
 5.1.1 软件项目评审概述
 5.1.2 评审面临失败的软件项目
 5.2 项目状态信息的来源
 5.2.1 口头的状态信息
 5.2.2 操作性的状态信息
 5.2.3 文档类信息
 5.3 评估大型软件项目
 5.3.1 大型项目有何不同
 5.3.2 评估团队
 5.3.3 评估大型项目的指导方针
 5.4 拼拼图
 5.5 可能出现哪些问题及如何解决
 5.6 本章小结
 习题
第6章第4步——评估项目团队
 6.1 一般原则
 6.2 评审团队整体
 6.3 评审项目管理
 6.4 评审团队成员
 6.5 整合信息
 6.6 可能出现哪些问题及如何解决
 6.7 本章小结
 习题
第7章第5步——确定最低目标
 7.1 项目目标和拯救过程
 7.1.1 区分目标、具体目标、需求和交付成果
 7.1.2 项目目标由谁制定
 7.1.3 同目标监督者结成同盟
 7.2 目标最低化的准则
 7.2.1 降低目标的过程
 7.2.2 一个降低目标的案例
 7.2.3 处理反对意见
 7.3 大型项目的目标最低化
 7.4 可能出现哪些问题及如何解决
 7.5 本章小结
 习题
第8章第6步——确定最低目标能否实现
 8.1 可实现的目标
 8.1.1 可行性分析方法
 8.1.2 被拯救项目的可实现目标
 8.1.3 如果目标不可实现
 8.2 中期报告
 8.3 可能出现哪些问题及如何解决
 8.4 本章小结
 习题
第9章第7步——重建项目团队
 9.1 回顾团队评估
 9.2 识别问题
 9.3 重建团队
 9.3.1 应对变更
 9.3.2 实施变更
 9.3.3 处理反对意见
 9.4 重建大型项目团队
 9.5 可能出现哪些问题及如何解决
 9.6 本章小结
 习题
第10章第8步——风险分析
 10.1 风险分析概述
 10.2 风险分析过程
 10.2.1 预测问题
 10.2.2 分析阶段
 10.2.3 实施风险行动方案
 10.3 风险分析的一个例子
 10.4 可能出现哪些问题及如何解决
 10.5 本章小结
 习题
第11章第9步——修改计划
 11.1 软件项目计划制定综述
 11.1.1 软件项目计划概念
 11.1.2 软件项目开发计划
 11.1.3 项目计划制定工具
 11.2 制定一个被拯救项目的计划
 11.2.1 为被拯救项目制订计划的指导方针
 11.2.2 其他需考虑的事项
 11.3 可能出现哪些问题及如何解决
 11.4 本章小结
 习题
第12章第10步——创建早期预警系统
 12.1 早期预警系统的组成要素
 12.2 开发数据收集
 12.2.1 项目开发数据的作用
 12.2.2 重启后项目的数据收集
 12.3 定期项目现状评审
 12.4 项目报警机制
 12.5 启动校正行动
 12.6 后续行动
 12.7 可能出现哪些问题及如何解决
 12.8 本章小结
 习题
第13章 尾声：把最后的拼图放入位置
 13.1 项目结束后的总结回顾
 13.2 人为因素
 13.3 灾难拯救的时间表
 13.4 最终报告
 13.5 案例分析
 13.6 结束语
参考书目
术语表

章节摘录

版权页：   插图：   6.不相关信息（好像有来自其他拼图玩具的拼图） 这里，好消息是知道信息是不相关的，这本身就是成功的一半。这样问题就降为了一个在将信息排除之前对它进行重新评价的问题：该信息确实是不相关的吗？（例如，对一项功能的描述，该功能最初被认为是属于该项目的，但是审查后被排除了出去。） 若对信息的不相关程度有所疑问，那么在将它排除出去之前，向项目的主要人员（项目经理、市场代表、客户或者拯救发起人）进行咨询。不过，不要将不相关信息抛弃；以后你可能会改变对其价值的看法。 一般来说，与不合适的拼图相关的多数问题能够通过口头方式解决和澄清。主要的挑战通常在于找出拥有正确信息或缺失信息的人。在评估过程开始时，准备好一个项目信息主要拥有者列表是很有用的。在项目重要成员（高级经理、项目经理、客户代表、市场代表，等等）的帮助下编制这个列表。 5.5 可能出现哪些问题及如何解决 本章所介绍的指导方针旨在提高成功完成评估的可能性，但显然，事情还是有可能出错。未雨绸缪是一种好的策略。实际上，做好准备是最好的预防方法之一。 下面介绍了一些较常见的导致评估过程失败的原因，并提出了应对之道。 缺乏合作 在评估陷入困境的项目时，缺乏合作是很常见的，特别是在评估开始后的最初几天里，这种现象尤为常见。对局外人怀有敌意或猜疑，担忧工作安全，或者对面临失败的项目兴趣下降，是出现缺乏合作问题的原因。 行动建议：答案在于高级管理层发出对拯救过程的强有力且看得见的支持信号。一个有效的解决办法是在拯救发起人、评估者以及不合作的人或团体之间召开一次三方会议。 项目复杂 对于外部评估者来说，项目可能太复杂，难以在可利用的有限时间内充分理解它。如果不能在合理的时间内（通常是2～3天）找到一名专家顾问，那么问题就会变得特别严峻。 行动建议：这通常是一个优先级的问题。提高寻找专家这项工作的优先级。给专家增加薪金，或者从另一个项目中抽调一位专家。专家成本应视未能拯救项目将会带来的损失而定。 评估过程延期 当评估过程费时过长时，不去寻找步伐缓慢的原因（即不去解决作为步伐缓慢原因的问题）是一种常见的行为趋向，因为寻找原因也会花费时间。但是，若有迹象表明评估过程会使整个项目拯救过程延期不止一天两天，那么就需要立即去寻找步伐缓慢的原因。注意，这并不意味着延期一两天是可以容忍的；实际上，这样的延期会将拯救过程置入危险的境地。 可能是前面提到的两个问题中的一个（缺乏合作或者项目非常复杂）导致了评估过程延期，也可能是由于所选的评估者不合适，导致了评估过程延期。 行动建议：如果步伐缓慢是前面提到的两个问题中的一个造成的，那么应用前面讲到的相应办法解决。如果步伐缓慢问题与评估者有关，那么拯救发起人就需要采取行动了，有可能需要更换评估者。如果步伐缓慢是由其他原因引起的，那么高级管理层应参与到解决问题行动中来。

编辑推荐

《灾难拯救:让软件项目重回轨道》荣获2007年Jolt世界图书大奖，适用于软件项目经理和高级经理，也可供软件开发人员和与软件项目有关的其他人员参考，还可作为软件工程和项目管理方面的教材。《灾难拯救:让软件项目重回轨道》是一本“救治”之书。它探讨了如何拯救面临失败的软件项目使之回到正轨，虽然其中也偶有内容论及灾难预防。《描述了拯救(或解救)面临失败的软件项目(或称软件项目灾难)的10个步骤。《灾难拯救:让软件项目重回轨道》有广泛的目标读者群，包括软件开发人员、项目经理、高级管理人员以及软件项目利益攸关者(同软件项目之间存在很大利益关系的人)。。在每一章的末尾，都有本章小结，并提供了习题。

用户评论 (总计4条)

•   总的看了下，尤其是前一部分，虽然很多内容觉得没有什么新意，感觉跟正常的项目管理差不多，但更加的全面，考虑的因素更多，相信如果参考着做的话，应该会避免很多问题，作为工具书来说很不错，不仅仅是技术和项目管理。
•   图书不错，送货速度不敢恭维
•   书不错，需要慢慢的读，博文视点的书还比较有水平。
•   经典书，不解释