软件开发的滑铁卢----重大失控项目的经验与教训

 “坦白地说，微软所面临的挑战之一是它的很多员工还没有遭遇过多少失败。很多人从未遇到过失败的项目。结果是，人们把成功视为理所当然的事，这是很危险的。。。人们遭遇失败时，将被迫发挥出创造性，不分昼夜地深入探索并冥思苦想。每个公司都需要有过这种经历的人。”
  ——比尔.盖茨
  “犯错的重要性”，《美国航空杂志》，1995年7月
  上面这段话是摘自《软件开发的滑铁卢——重大失控项目的经验与教训》一书的，两个月前第一次看到这段话，那时刚好经历了一个让我印象无比深刻的项目，对这段话也特别有感触，就第一时间放到了blog上。
  
  两个月过去了，又重新找出这本书来看，对作者提到的一些现象有了更深的共鸣。鉴于这本书目前尚没有中文电子版，所以决定把其中一些值得反复体会的文字，以及自己在读书过程中的一些思考记录下来， 与大家一起分享。
  
  **************************************************************************
  
  所谓的“软件失控项目”，是指在创建系统所需的软件时遇到困难，从而导致大大超出可控制范围的项目。“项目失控”暗示着项目变得无法管理，从而无法达到最初的目标，甚至无法接近目标——这里所指的目标，包括进度目标、成本目标以及满足功能性和非功能性需求的目标。
  
  但软件项目未能达到成本和进度的目标，常常是因为这些目标本身就是错误的，而软件从业人员辛辛苦苦的工作，其实是不断的耗费时间去迎合不可实现的目标；而这些目标通常是由营销人员或客户指定的，其次是由管理人员来制定，很少有实际完成项目的技术人员涉足其中。
  
  书中作者引用了三个词来说明软件项目所处的不同情形：两难境地（crunch mode），死亡行军（death march），和 失控。我特别喜欢作者对“两难境地”和“死亡行军”项目的描述，很生动很形象的这样两种项目对软件从业人员的影响。
  
  
  
  处于“两难境地”的项目面临着无法达到最初目标的威胁，而项目团队在努力想要跨越该困境。软件专家会在办公室给家人打电话说：“我们正处于两难境地，在半夜之前我是不会回家的”。家人也不会吃惊。两难境地的状况可能会持续几天、几周，甚至几个月，这取决于项目本身持续的时间以及它偏离目标的程度。
  
  “两难境地”这个词源自John.Boddie在1987年出版的《Crunch Mode》一书，而这个词并不是Boddie发明的，而是由发现自己被迫完成项目的软件从业者们发明的，通常用来描述进度表极其紧迫的项目，说明项目参与者感受到的压力。
  
  
  
  而“死亡行军”项目简单的说，就是当你发现不得不参与到一个项目中，又不得不通过超常的努力和超长时间的工作才能完成那些不合理目标时，你所参与的这个项目就是一个“死亡行军”的项目。
  
  “死亡行军”这个词源自Ed.Yourdon在1997年出版的《Death March》一书，而这个词也同样是由那些被迫在“死亡行军”项目中行走的人们发明的，通常用来描述进度表几乎不可能完成的项目，说明项目参与者的周围弥漫着的是难以忍受的潜在的失败气味。
  
  
  
  在我们现实的世界中，通常是因为有人对项目结果期望太高，时间要求太紧，所以从项目开始就呈现出“两难境地”；随着项目的进行，项目参与者很快发现自己在进行“死亡行军”，正在设法实现越来越不可能实现的目标；当项目明显成功无望、多个方面都已失败时，改项目就成为“失控”项目了。
  
  大多数人，如果让他们选择的话，都不愿意加入到死亡行军，不想让自己处于两难境地，而且永远不想处于失控的项目中。可因为系统项目通常受到进度表的支配，管理者根据项目预先确定的进度表来检查项目进度，而进度表总是由那些没有能力精确估算的人来确定——比如营销人员或者客户——所以总是时间紧迫，不合情理。
  
  
  
  有意思的是，“两难境地”的提出是在1987年，“死亡行军”的提出是在1997年，两者相隔10年；而我们再反观又过了10年后的今天，2008年，20年过去了，可似乎我们身处的软件行业、软件项目管理并没有出现太明显的改善。虽然真正“失控”的项目只是极少数，而且也并不是所有的死亡行军项目都会失败，但我们可以发现自己要么处于“两难境地”，要么正在“死亡行军”，总是难以逃脱。