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