每个程序员都经历过项目的洗礼，你是项目成员还是项目经理？许多年过去了，那些让你哭笑不得的场景是否依然没有改变？几位大牛将大量场景抽象为模式，以其幽默、深刻的洞察力讲述了项目失败的原因，这些原因跟每一位程序员息息相关。
1、工作忙乱是生产率高的表现
优先级总是变化不休，所有事项都是“昨天”就要，总是没有足够的时间交付项目，每个项目都是加急项目，而且加急项目还在不断出现。每个人都忙得焦头烂额……永远如此。
2、所有失败的会议…
你经常开会吗？你们会议得出的大多数决定都是正确的，且可以很干净利落地决策和行动吗？还是会议组织杂乱，新想法层出不穷，主题不断变化，新问题源源不断，但却没有一个有答案。最终，大家在会议结束时安排了额外的会议。——所有失败的会议最终都走上这一步，概莫能外。
3、死鱼就在那儿
从开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，却缄口不言。
很多组织过于看重成功，所以任何表达疑虑的人都不会因为说真话得到任何奖赏。事实上，如果谁在项目的前期阶段就声称死鱼的存在，管理层的第一反应多半如下：
“证明给我们看。给我们证明成功的可能性是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。请用严密的数学证明来告诉我们失败无法避免。”
一旦你提出任何缺乏精确证据的东西，就会被指责为软蛋或者是试图逃避辛苦扎实的工作。
4、项目经理是保姆
快偷偷笑吧，这个好难得！
你所在的组织或许已经有一些“保姆型”经理，如果你留意，会发现：不必预约就能见到你的头儿，或者不必在琐碎和令人生厌的管理工作上花费太多时间。周围是开放的氛围，人们畅所欲言，互相学习。这种经理认为培训或进修非常必要，而不是视之为烧钱。他们还会专门安排时间（比如早晨咖啡闲谈或者周五下午阅读探讨），让大家在一起讨论新想法。
5、把灵魂卖给开发语言
合格的专业人士能够根据待解决问题的实际情况来裁剪解决方案，而不是把个人或者团队久经检验的技能强加在问题上。这不是说团队成员不懂应用已知的工具或方法。他们没有把灵魂卖给任何技术，换而言之，一旦出现了好的新思路，他们能够比较优劣，明智地决策。
不把灵魂卖给开发语言的好处是，当技术潮流退去时，你不会在沙滩上裸泳。你可能知道，有些人自诩为开发人员，却很久都没有尝试学习新的编程语言。这些人眼巴巴地搜寻提到自己所用语言——当年也曾风行一时，但现在基本不再使用的编程语言——的工作职位。悲哀就在于，他们把灵魂卖给了那种开发语言。
6、你们为什么不是米开朗基罗
“我给了你凿子，可你为什么不是米开朗基罗？”这样的疑问充斥在迫不及待希望立即提升生产率的组织，以及招聘时重视应聘者的薪水要求而非所掌握技能的组织。热切人人都是米开朗基罗的组织内，架子上总是堆满了各种工具。
没错，工具是有用的，在合适的人手中它们能大幅提升生产率，还可以完成那些本来无法完成的任务。但是，工具的构造者会告诉你，最关键的是，拥有对应的技能来使用工具。所谓凿子，在米开朗基罗拿起它之前，只是拥有锋利边缘的铁器而已。
7、影评人
影评人是团队成员或者公司内部的旁观者，他们认为自己对项目的贡献在于，指出问题所在或者将会出现问题的地方，至于解决问题，那不是自己的职责。
并不是所有评论项目的人都是“影评人”，重要的区别在于选择的时机不同。如果对项目的成败负有责任感，人们一旦发现事情做得不对，或者可以做得更好，就会毫无顾忌地讲出来。他们会走到他们认为可以发挥作用的人面前，讲出自己的想法。他们尽可能及时地行动，因为他们知道时间总是有限的，纠正措施应该越早采取越好。这些人不是“影评人”，他们是跟你携手并肩的“电影制片人”。他们知道自己和项目是一损俱损的，因此他们每天都会把问题揽在自己身上，以增加成功把握。
而“影评人”往往到“电影”结束，或者快要结束的时候才参与进来，此时已经没有足够的时间来采取纠正措施。
8、沉默即同意
利益相关方无法区分真正的赞同和屈从的沉默。承诺被误解的情形通常是：一方表达了需求，然后另一方点头示意明白。前者把这种情形理解为承诺：“我告诉他必须在12 月31 号以前完成，这非常重要。”后者则视为痴人说梦：“当然，他希望我在年底完成，但那不可能。”通常，提要求的人更有权力，而且他会依据法律上的格言“沉默即同意”来设定自己的期望。如果没有对这样的人物说“不”，就相当于在说“是”。
9、稻草人
“客户只有看到了系统，才知道自己真正想要什么……肯定不是那个系统。”
稻草人模型是一种需求钓饵。你给客户一个激发想法的东西，试探出他们的好恶。这些模型都是快速完成的，而且因为它们不保证正确，所以不必花太多精力。由客户来评审解决方案——比如说，“选定区域销售主页”界面——的实物模型、原型或者故事画板。用这些东西模拟未来要交付的软件，作为回报，客户带你走向真正的需求。
最好的分析师不会问：“你们想要什么？”他们意识到这种问题通常会令人不快。人们讨厌对着一张白纸设想答案，但乐意批评已经写在纸上的答案。
10、贪多求全
组织想要贪多求全，就会影响速度，最终导致净收益降低。但是那种诱惑可能是无法抵抗的……
承担超出最大能力范围的工作是降低速度的罪魁祸首。你大概从未见过有人如此坦率地指出数量和速度之间的关系，因为说出来绝对是令人不快的。正因为大家无视这个问题，所以如此多的组织会为了完成大量的工作而让自己慢到几乎动不了。如果他们暂停下来，从麦麸中挑出麦粒，就能明白停滞的原因是没价值的麦麸太多了。
11、坏消息
在组织里，坏消息不能准确向上传达。
12、把坏消息埋在心底
许多企业文化都会传达一种信号：谁发现了杂乱不堪的现象，谁就得负责清理。另外，指出问题，却没有立刻提出改进措施——这会被认为是在抱怨。而在很多组织里面，抱怨者的职业前景相当有限。
13、记者
记者是指这样的项目经理，他们认为，准确报告项目的情况与保证项目成功是两个目标。
想一想记者报道飞机失事的情景。记者觉得自己有责任准确地报道哪架飞机失事了，发生的时间地点，飞机上有多少人，是否有人生还，但他不会因为没有阻止飞机的失事而觉得内疚。那不是他的责任。
记者型项目经理也同样如此。他们的报告清晰、准确、细致，可以列为范本。他们清楚地知道“订单管理”子系统延迟多长时间，偏离关键路径多少天，这项延迟对依赖它的后继任务有什么影响。但是他们忽略了非常重要的事情：这个职位存在的意义，是要保证项目有个圆满结局。
14、数据质量
数据质量往往异常低劣。很遗憾，常见解法竟然是寻找更好的软件来处理它。
数据库软件的质量高出它所处理的数据的质量，这并不罕见，尽管对最终用户来说，系统的质量受制于两者之中更差的那个。各家公司的数据库里面都堆满了不准确的，以及过期或不完整的信息。问题就像鼻子长在脸上一样明显，但人很难看到自己的鼻子。即便每个人都能看出其他人的数据有问题，公司也很难去直面自己的数据质量问题。相反，公司看到的总是软件与数据混在一起的问题。因为软件总是比数据（数据量大得可怕）容易修复，所以公司乐意修复或者更新软件。
这两种做法都没有意义，因为我们要讨论的关键问题不是“为什么我们不应该从软件动手”，而是“为什么明知不是软件的问题，我们仍然从软件动手”。
15、好想法不会很快被接受
更新、更好并不足以保证想法能立刻被接受，接受新想法需要时间。组织会抗拒变化，或者延长决策期，以推迟变化。但是发明和支持更好想法的人可能备受打击，因为看到自己的建议被人忽略，或者被翻来覆去地考量。在军事上，反反复复的思考被称为“慢摇”。在做项目的这些年里，我们看到几乎每一个新出现的好想法都经历过“慢摇”（至少在短时间内是这样的）。举个例子，即使在像软件这种应该是高速发展的行业里面，一些今天已经被广为接受的最佳实践也花了差不多20 年时间才被接受。
经典推荐
作者：Tom Demarco等
译者：余晟 金明
书号：978-7-115-39130-8
定价：49
页数：207
第19届Jolt大奖获奖作品
《人件》作者又一力作
入木三分刻画软件项目众生图
“只要经历过一两个软件项目的磨练，就能从书中找出许多熟悉的模式，也会从大多数模式中获益。”
——Joel Spolsky，《软件随想录》作者
“作者兼具十足的幽默感和深刻的洞察力。本书清楚地讲述了项目因何而失败，有何补救措施，并以极为友善且易于接受的方式提出了切实可行的建议。”
——Warren McFarland，哈佛商学院教授
“对于任何一位曾经在组织里面从事过项目工作的人来说，86个项目模式熟悉得令人心惊。幸运的是，其中有一些模式是良性的，应该给予鼓励。然而悲哀的是，剩下的绝大多数模式不仅仅令人心灰意冷，而且它们对生产率、质量和项目团队士气的破坏程度令人瞠目结舌。”
——Ed Yourdon，《死亡之旅》作者
“这本《项目百态》就是关于项目管理的实话集……读这样一本书，你会笑，更多的时候你会摇头苦笑，甚至如芒在背。”
——熊节，ThoughtWorks中国公司首席咨询师
原文地址：http://blog.csdn.net/turingbooks/article/details/46603299
