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