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

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

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

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

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

　　人员

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

　　#1：不确定的激励措施

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

　　#2：糟糕的人事管理

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

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

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

　　#4：英雄主义

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

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

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

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

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

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

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

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

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

　　#8：不现实的期望

　　最可能引起开发者和消费者或管理者 之间冲突的原因之一是不现实的期望。在案例分析3-1中，如果不是公司需要那么多时间，Bill没有理由相信Giga-Quote项目可能在6个月内开发 完毕。Mike没有纠正这个不现实的期望是问题的主要来源。在其他情况下，项目管理者或开发者会根据过于乐观的项目日程估计来申请项目资金。有时候他们会 作出不能保证实现的承诺。虽然不现实的期望并没有自发地造成项目日程的增长，但它仍会形成开发时间过长的假象，这会使事情变得非常糟糕。Standish Group的一个调查表明，贴近现实的期望是保证商业软件开发项目成功的五大要素之一(Standish Group 1994)。

　　#9：缺乏有效的项目赞助

　　高级别的项目赞助可以在许多方面保证项目的高效开发，包括现实的计划、权变控制，以及新的开发实现操作。如果没有这样一种有效的项目赞助，那么其他更高级别的人事管理就会在组织里迫使你去接受不现实的{zh1}期限，或被迫接受一些削减项目的变化。澳大利亚咨询师Rob Thomsett说，缺少有效的项目赞助事实上注定了项目的失败(Thomsett 1995)。

　　#10：缺乏利益相关者的入伙

　　软件开发中所有的主要成员都要入伙该项目，其中包括执行赞助、团队领导、团队成员、市场部、最终用户、消费者以及其他所有利益相关方。密切的合作只在所有的利益相关者入伙时才会发生，从而保证了项目的顺利进行。

　　#11：缺乏用户的参与

　　Standish Group的调查表明IS项目获得成功的最主要的原因是其用户积极参与了项目的开发(Standish Group 1994)。

　　#12：将权术置于本质之上 www.myp

　　Larry Constantine就四个团队进行了报道，并称他们分别具有四种权术中心(Constantine 1995a)。“政治型”团队倾向于“向上管理”， 即更关注与其上层领导之间的关系。“研究型”团队专注于侦察和收集信息。“隔离型”团队以自我为中心，他们会与非团队成员划清界线。而“通用型”团队则每 件事都做一些：他们和上级搞好关系，进行研究和收集信息的工作，并在工作流程中和其他团队进行协调。Constantine报道称，一开始是“政治型”和 “通用型”团队能够被上级领导重视，但在一年半以后“政治型”团队被打入冷宫。所以说将权术置于成果之上对高效开发来说是致命的。

　　#13：一厢情愿的想法 项目管理论坛

　　我很惊讶，为什么在软件开发中有许多问题{zh1}都归结为一厢情愿的想法。你听过几次类似下面的说法：

　　“团队中没有一个成员认为他们可以按期完成任务，但他们却想如果每个人都努力功能，没有一件事会出错，再加上几次幸运的休假，相信他们就能顺利完成任务。”

　　“我们团队还没有将产品的几个部分进行融合，但我们会在其他发面进行有效的沟通，而且这些部分之间的接口是比较简单的，所以应该只要一两天的时候来修复其中存在的问题。”

　　“我们以谎报低价的方式和他们签订了数据库子系统的承包合同，而要完成这些任务就需要相当的人力资源，这对他们来说是很困难的，因为他们并没有这方面的资历，但也许他们可以用更多的精力来弥补经验上的不足。也许他们可以按时完成任务。”

　　“我们不需要想顾客展示程序的最终原型，我很确定这就是他们想要的。”

　　“这个团队称他们会非常努力地按期完成任务，虽然他们在{dy}个关键时间点上延误了几天，但我相信他们可以按时完成的。”

　　一厢情愿的想法不是乐观，而是闭上了你的眼睛去期望一些根本没有理由相信其存在的东西。这种想法会在项目的{zh1}阶段带来巨xxx烦。它不仅削弱了有意义的计划，而且很有可能这项软件工程有着更多更复杂的问题。