#8：不现实的期望

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

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

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

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

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

#11：缺乏用户的参与

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

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

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

#13：一厢情愿的想法

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

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

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

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

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

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

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

过程

与过程相关的错误会降低项目的开发速度，因为他们会浪费人们的智慧和精力。以下列举一些影响坏的错误。

#14：过于乐观的项目进度

一个要在三个月内完成项目的 人与一个要在一年内完成项目的人所面临的压力和挑战是不同的。过于乐观的项目进度会使项目被过分重视，削弱了有效的计划，并缩减了上层开发活动如需求分析 和设计，这将使项目面临失败。这还会对开发者连续施加压力，使他们的士气和产能受挫。这也是案例分析3-1中问题的一个主要来源。

#15：风险管理不足

有些错误可以被视作经典错误，有些则只在特定的项目中发生。在经典错误中，如果不注意主动地进行风险管理，会将一个快速开发项目变成慢速的。风险管理失败是普遍的经典错误之一。

#16：承包人失职

公司有时候会因为项目太 紧急不能自己完成把项目的一部分交给承包人来做。但是承包人通常会迟交任务，且质量很差，甚至没有达到指定的要求（Boehm 1989）。当程序的需求不够确定，或是程序结果设计得不好，那这其中的风险将会在寻找承包人时得到放大。如果与承包人之间的关系处理得不够好，会降低 项目的开发速度，而不是加快。

#17：计划不足

如果你不计划快速地完成项目，那不可能快速地完成。