软件开发项目管理中的“经典错误”

UML软件工程组织

软件开发项目管理中的“经典错误”

2008-10-31 来源：yeeyan.com

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

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

本章列举了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）。这种冲突是非常耗时的，而且会把双方的精力从真正的工作中吸引出来。

#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：计划不足

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

#18：在压力中放弃计划

当项目进度遇到麻烦，开发者就会放弃原先制定好的计划（Humphrey 1989）。问题的严重性并不在于放弃了计划，而在于没有建立一个备用方案，从而陷入编写-修复的循环中。在案例分析3-1中，团队因为按时进行第一次发布（这很正常），因而放弃了他恩的计划。结果是，这一时间点之后的工作都是无计划的，甚至Jill开始用一部分时间来为她以前的队员工作，且没有一个人知道。

#19：在“模糊的前端”中浪费时间

“模糊的前端”指的是在项目开始之间所进行的验证和预算阶段。不少项目会花上几个月甚至几年的时间来进行这项工作，然后制定出一个非常紧迫的项目进度。从“模糊的前端”中节约几个星期或几个月的时间要比在经过压缩后的项目进度中节约时间容易、便宜和有保障得多。

#20：不充足的前期工作

比较紧急的计划会尝试着缩减一些不必要的工作，所以诸如需求分析、建构和设计等不能产生代码的工作就成为了缩减的首要目标。有一次我接手了一个非常糟糕的项目，我说我想看一下项目的设计图，团队领导却说他们没有时间做出设计图。

这个错误还被称为“直接跳进编码阶段”，其结果是可以料想到的。在案例分析中，条状设计图被质量设计工作所代替。在产品可以被发布之前，设计图的工作只能被否决，更高的质量工作必须要立刻完成。缩减了前期工作的项目肯定要在后期工作中弥补这些工作，而花费的精力却是10倍甚至100倍的（Fagan 1976; Boehm and Papaccio 1988）。如果你没有额外的5个小时去把第一项工作做好，难道你能找到额外的50个小时去做接下来的工作吗？

#21：不充足的设计

在不充足的前期工作中，不充足的设计是一个特例。紧急的项目会使用来进行项目是设计的时间减少，同时高压的环境会让提出替代方案变得非常困难。项目设计的目的在于权宜而不是质量，所以在项目完成之前你需要一些非常耗时的项目设计周期。

#22：不充足的质量保证

一个紧急的项目会通过减少设计和编码的检查、减少测试计划并只进行简单地测试。在案例分析中，设计回顾和编码回顾都只花了很少的时间以完成项目进度。而结果是，当项目进行到关键的地方，仍有过多的程序错误导致推迟5个多月发布。这种后果是很典型的。在质量保证过程中减少了一天的工作，就会在后期增加3到10天的工作量（Jones 1994）。这会降低项目开发的速度。

#23：不充足的管理控制

在案例分析中，有一些管理控制措施会用来对即将发生的工作失误进行警告。但是，当项目出现了问题，这些管理控制就被放弃了。如果你想让项目一直保持在轨道上，那你就必须知道项目是否在轨道上，即有一个评定的标准。

#24：过早的或过于频繁的整合

在产品即将发布之前，应该做一些准备，如提高产品的星等、打印最终使用文档、组织最终的帮助系统挂钩、修饰一下安装程序、找出不能完成任务的组件等。在紧急的项目中，人们喜欢把项目过早地整合起来。由于在完成之间不能进行组合，于是有人就在工作过程中对项目进行许多次的整合，直到成功。这些额外的整合并没有使项目受益，而只是浪费时间和拖延进度罢了。

#25：忽略了某些任务

如果人们不对已经完成的项目作仔细的记录，而忘记了其中某些不显眼的任务，那这些任务会越积越多。这些被忽略的工作会累计到整个进度的20%到30%。

#26：计划以后再抓紧

如果你要完成一个6个月的项目，而用了3个月的时间完成了2个月的工作，你会怎么做？许多开发人员会说他们计划以后再抓紧，但是他们从来没有这样做过。你在建立项目的时候你会知道得越多，其中包括还需要多少时间去完成它。所以这些信息也需要反映在项目日程中。

另一种错误来自于项目的变更。如果你的项目变了，那你需要完成该项目的时间也会发生变化。在案例分析3-1中，项目的主要需求改变了，而项目开发团队却没有制定相应的措施来对进度表作出调整。面对日益增多的新要求，而不在项目进度中反映出来，一定会导致不能按期交货。

#27：糟糕的编码

有些组织认为快速、随意的编码是同样快速开发的捷径。他们争辩道，如果开发者被充分地激励了，他们就能克服万难。这远远不是实施，本书的其他章节会阐述其中原因。“企业家模式”通常是守旧的“编码-修复”模式的幌子，而且这种模式几乎不管用。这也是“错加错不等于对”的一个例子。

产品

以下列举一些在定义产品的时候所容易犯的错误。

#28：过高的需求

有些项目从一开始就被提出了过高的需求。项目需求的提出往往会超过实际的需求，这无疑会增长项目的进度。用户对市场和开发速度的需求要比那些复杂的特性来得高，而且复杂的特性会大大改变项目的开发进度。

#29：过低的需求

即使你成功避免了过高的需求，平均每个项目都会在其生命周期中发生25%的改变（Jones 1994）。某一个改变至少会增长25%的开发进程，这对快速开发来说是致命的。

#30：开发者画蛇添足

开发者会被新科技所吸引，有时会想要在项目开发中尝试一些新的特性，或者参照别的程序里的组件，自己写出它的实现，即使项目没有这样要求。这些设计、实现、测试、撰写文档的经历都是不需要的，且会增长项目进度。

#31：来回推搡的谈判

有一种奇怪的谈判策略，管理者在确认了进度上的失误后，即没有按时完成任务，就在进度更改后又加上新的任务。这样做的理由耐人寻味，因为确认了进度上失误的这个管理者也表示承认了项目进度是有错误的。但是当项目进度重新调整正确后，同一个人又用明显的举动将其再一次搞错。这无疑将拖延开发进度。

#32：以研究为中心的项目开发

Cray超级计算的设计师Seymour Cray说，他从来没有试图过同时跨越两个领域进行开发，因为那样做风险太高了（Gilb 1988）。许多软件项目开发人员可以从Cray那里好好学一学。如果你的项目着眼于研究出新的算法或实践方式，那你就不是在进行软件开发，你是在做软件研究。软件开发进度是可预测的，而软件研究的进度即使从理论上讲也是不可测的。

如果你的产品目标中包括了研究出新的算法、提高速度、内存使用等，那你就得预见项目进度是非常不确定的。如果你的项目中还有其他弱点，如人员的短缺，人员资历不足，模糊的需求，于承包人之间不稳定的接洽，那就把项目进度扔到窗外去吧。如果你真的想要完成那些研究，那就不要期望进度会很快！

技术

剩下的经典错误是和现代技术的使用和误用有关的。

#33：银弹综合症

在案例分析中，人们把太多的期望寄托在所谓的新技术中（报告生成器，面向对象编程，C++），而它们是否能在此项目中发挥效用还不得而知。当项目开发团队决定使用一种新的方法或技术，其他它能解决目前所面临的问题时，他们一定会非常失望（Jones 1994）。

#34：对新工具和方法太过犹豫

在技术革新时，组织很少会大幅度提高他们的产能，不管他们引进了多少先进的技术。先进的技术所带来的好处基本上不在他们的学习范围之内，而要学习这些新的技术以发挥其最大效能是需要花费时间的。新的技术同时会包含新的风险，只有使用后才会发现。人们宁愿使用慢速的稳定的提高，而不是经历起伏过大的收获。案例分析3-1中的开发团队应该已经计划到使用了新技术后会使产能提高10%，而不是乐观的相信这会使开发速度提高一倍。

有一个特例，当在使用过去项目的代码时，这种犹豫会更加明显，但时间的节省并没有想像中的多。

#35：在项目开发过程中更换工具

这是一种惯常的备用手段但很少奏效。有时这对于相同产品线内的升级会有效，如3.0版、3.1版甚至4.0版。但其中的因为使用新工具而产生的学习时间、重复劳动和不可避免的错误往往会抵消掉在项目中途更换工具的好处。

#36：缺少自动化的源代码控制

不进行自动化的源代码控制会使关键项目遭受不必要的风险。如果没有它，当两个程序员在开发同一个部件时，他们就需要进行手工整合。他们也许会达成约定，把修改好的文件存入一个主文件夹，并在修改时注意查看文件时间信息。但是有些人总是会覆盖他人的工作。当人们用过时的结构来编写程序，在发现之后又必须进行重写。当用户举报程序的错误时间，你就不能重新编译项目。源代码平均每个月要更改10%，而手工的源代码控制是跟不上的。