有一些低效率的管理实 践操作仍被许多人采用，造成了完全可以预期的不好的结果，这些实践操作被称为“经典错误”。大多数“经典错误”都有一个具有诱惑力的外表。你需要拯救一 个落后于进度的项目吗？那增加人手吧。你想减少日程安排吗？那把日程安排得更紧一些吧。团队中的一个关键人物激怒了其余队员？那在项目结束后炒他鱿 鱼吧。你有一个很紧急的项目要完成？那把目前所有可用的人力资源召集起来开始工作吧，越快越好！

开发者、管理人员和顾客通常会有很好的理由来解释自己的所作所为，所以这些“经典错误”的具有诱惑力的外表也是解释为什么会再三犯下这类错误的原因。但是，由于“经典错误”已经发生过很多次了，因此它的结果是可以预期的，这些结果显然会和人们原来希望得到的结果不一致。

本章列举了36个“经典错误”，每个错误我本人至少见过一次，而且有许多是我自己也犯过的。你会从案例分析3-1中识别出这些错误。

这些错误的共性在于，如果你想避免它们，那么你的软件项目肯定不能开发得很快。但如果你不去避免他们，你注定会开发得很慢。

如果有些错误看起来很熟悉，好像自己也犯过，不用担心，振作起来。因为有许多人犯过相同的错误，而且一旦你了解了这些错误给你的开发速度所带来的影响，你可以在制订计划的时候进行风险控制。

有些错误会在本书的相应章节中进行讨论，有些则不会进一步讨论。为了便于查阅，这些“经典错误”被分类成了人员、过程、产品、技术等四个方面。

人员

这里是一些与人员有关的经典错误。

#1：不确定的激励措施

无数的调查研究表明，激励很可能是提高产品产量和质量的有效的措施（Boehm 1981）。在案例分析3-1中，在管理的实施中充斥着不确定的激励措施。开头是一番虚情假意的激励性谈话，中间是要求员加班加点地工作，后管理者去享受了一个长假，而员工却要在假期中继续工作，为的只是那些少得可怜的额外奖励。

#2：糟糕的人事管理

在激励之后，对产品产量有巨大影响的不是由团队队员个人的能力决定是由队员之间的关系所决定（Boehm 1981， Lakhanpal 1993）。招募那些资历差的员工将会威胁到企业为快速发展所付出的努力。在那个案例分析中，人事选拔的标准是谁能快被找到，谁被录取，而不是根据 谁的能力强来作为标准。这种做法虽然使项目迅速地开展，但不能快速地完成。

#3：不受控制的问题员工

不处理好问题员工同样会影响工作速度。这类错误在Geral Weinberg于1971年出版了《计算机编程心理学》一书后被管理者 普遍理解。不处理好问题员工往往是团队队员抱怨他们的领导的普遍的原因（Larson and LaFasto 1989）。在案例分析3-1中，整个团队都知道Chip这个人不是什么好东西，但团队领导却视而不见。其结果——重新完成Chip的工作——可以预见 了。

#4：英雄主义

有些软件开发者认为，在项目开发中强调英雄主义是非常重要的，认为英雄主义是非常有益的（Bach 1995）。但是我认为，以任何一种形式来强调英雄主义，其坏处往往要比好处多。在案例分析中，中层管理者 对那些认为只要能做能做成功的人给予了更高的奖励，而那些讲究稳定、长效的工作人员却得到了较低的奖励。其结果是工作中实行的边缘政策直到后一分钟 才发现、认识了组织所面临的紧急的问题，并向上级报告。一个小的开发团队掌握了公司的生杀大权，因为他们不愿意承认不能按期完成任务。对英雄主义的强调促 进了冒极大风险的趋势，而削弱了在软件开发的过程中，利益相关者之间的合作。

当有些管理者 过分强调“能做能成功”的态度时会产生强调英雄主义的行为。当项目管理者视这种态度高于的状态报告时，他们会不完全发挥自己的能力地去采取正确 措施。他们甚至不认为自己需要采取正确措施，直到损失已经造成了。正如Tom Demarco所说，“能做能成功”的态度将原本只是很小的障碍放大成一场真真正正的灾难。

#5：向即将到期的项目追加人手

这也许是常见的“经典错误”了。当一个项目落后与进度时，不在现有队员中下功夫，而是以增加人手的方式来提高产量。Fred Brooks把这种行为比做“火上浇油”（Brooks 1975）。

#6：吵闹、拥挤的办公室

多数开发者对自己的工作环境是不满意的。约60%的人认为他们的工作环境不是不够安静是不够私人化（DeMarco and Lister 1987）。拥有安静、私人的工作场所的工作人员会比那些处在吵闹、拥挤的地方的人要表现得更为出色。吵闹、拥挤的环境会拖延工作日程。

#7：开发者与顾客之间的冲突

这种冲突可以是来自多方面的。当开发者不愿意签定顾客制定的项目进度表时，或者开发者没有履行好他们的承诺时，顾客可能会认为开发者不够合作。而开发者可能会认为顾客过于无理地坚持不现实的项目进度或修改明明已经确定下来的要求。于是这两拨人之间可能发生人身攻击或诽谤。

这种冲突的主要的影响是使交流和沟通变得匮乏，其中又包含了对需求的缺乏理解，用户界面设计不够理想，更糟糕的情况则是顾客拒绝接受已经完成的产品。平均地来说，顾客和软件开发者之间的冲突往往会严重到双方要撕毁合同取消项目的开发（Jones 1994）。这种冲突是非常耗时的，而且会把双方的精力从真正的工作中吸引出来。