大多数典型错误其表面都具有诱惑性，给人们一种诱人的前景，但通常却不能产生期望的结果。

　　“想挽救进度已经落后的项目吗？---- 给项目补充更多人员！”

　　下面分别按照人员、过程、产品和技术四个维度列出36个典型错误。

---

人 员

• 典型错误1：挫伤积极性

　　对人员不够关心和重视；过度的进度压力；缺乏激励；过分夸张的激励等。

• 典型错误2：人员素质低

　　人员能力欠佳，工作效率低，甚至做多错多。

• 典型错误3：对有问题的员工失控

　　不对有问题的人员采取措施是项目组成员对领导最常见的抱怨。

• 典型错误4：英雄主义

　　强调个人英雄主义会导致发生额外的风险，也会削弱在软件开发过程中多个角色的合作。

• 典型错误5：项目后期加入人员

　　盲目地在项目后期加入人手等于火上浇油。

• 典型错误6：办公室环境拥挤嘈杂

　　拥有安静、隐蔽办公环境的人员比工作在嘈杂、拥挤环境中的人员往往会有更好的工作业绩表现。

• 典型错误7：开发人员与客户之间发生摩擦

　　主要原因是缺乏沟通。这种摩擦耗费时间，它会转移客户和开发人员双方对项目工作的注意力。

• 典型错误8：不现实的预期

　　过高的期望值和主观的不切实际的设想。是导致开发人员和客户或项目经理之间的摩擦常见原因之一。

• 典型错误9：缺乏有效的项目支持

　　软件开发项目的许都方面都需要高层的支持，包括实际的计划、变更控制以及新型开发方法的采用等。缺乏有效的高层支持事实上注定了项目的失败。

• 典型错误10：缺乏各种角色的齐心协力

　　软件开发中所有主要人员必须齐心协力专注于项目，包括高层支持者、项目领导、项目成员、市场人员、最终用户、客户和任何项目介入者。

• 典型错误11：缺乏用户介入

　　没有用户早期介入的项目充满需求误解的风险，易受项目后期功能蔓延的威胁。

• 典型错误12：政治高于物质

　　“政治家”型项目强调“管理至上”，主要精力集中在他们与经理的关系上。将政治凌驾于结果之上对软件项目会造成极大伤害。

• 典型错误13：充满想象

　　闭上眼睛毫无理由地希望某事将像想象那样运作。很多软件开发问题都是由于充满想象造成的。

       想象示例：

• 项目组不知道他们能不能按时完成项目，但他们认为如果每个人能更努力工作，并且不出现问题，他们应该能完成项目。
  
• 我们无需向客户演示最新的修改，我们确信这个效果是客户想要的。
  
• 项目组错过了一个里程碑好几天了，他们说会更努力工作赶上下一个里程碑，我想他们能够及时赶上的。

• 典型错误14：过于乐观的计划

　　定制过于乐观的项目计划相当于自己为项目失败画出了底线，导致缩短分析、设计等关键性前期开发活动；同时也向开发人员施加了额外压力，会长期对开发人员的自信心和生产率造成巨大伤害。

• 典型错误15：缺乏足够的风险管理

　　如果你不主动管理风险，风险随时会来找你，打乱你的开发计划。

• 典型错误16：承包人导致的失败

　　如果不对承包商加以认真管理，交付可能延期，并且质量难以保证。

• 典型错误17：缺乏计划

　　没有计划的项目就像飘荡在海洋中的小船，没人知道会飘到哪里。

• 典型错误18：在压力下放弃计划

　　很多项目组定制了计划，但遇到了麻烦时就放弃计划。项目失败的原因不是在于放弃计划本身，而是不能及时修订计划制定替代计划，并一头栽进编码和问题处理中。

• 典型错误19：在模糊的项目前期浪费时间

　　由于花在审批、预算等前期工作的时间过长，或需求无限循环等原因，导致压缩开发计划。项目前期节省几周或几个月时间比将开发计划压缩同样时间来得更容易、更廉价，风险也更少。

• 典型错误20：前期活动不符合要求

　　研究数据：

　　前期被跳过的活动或工作通常在后期会以10倍到100倍的代价来完成。如果一项工作在项目初期需要5小时完成，那么在项目后期你至少需要50小时才能完成它。　　（Fagan 1976，Boehm and Papaccio 1988）

• 典型错误21：设计低劣

　　前期活动不符合要求的一个特殊情况就是设计低劣。高压环境导致设计缺乏周密思考往往导致设计低劣。

• 典型错误22：缺少质量保证措施

　　研究数据：

　　项目前期砍掉1天的质量保证活动，到项目后期就需要3到10天的处理代价。（Jones 1994）

• 典型错误23：缺少管理控制

　　缺少管理控制点就难以对项目的阶段和状态进行跟踪，因此不能知道项目是否按正常轨道前进。

• 典型错误24：太早或过于频繁的集成

　　在构建未完全锁定时，进行过早的集成或额外的集成不利于产品，它仅仅是在浪费时间，延长进度。

• 典型错误25：项目估算时遗漏必要的任务

　　训、公司和部门会议，技术评审会议等活动在项目估算时通常被遗漏。

• 典型错误26：追赶计划

　　当进度落后时不重新检查任务和调整计划，而是简单地决定把进度赶上来。

　　另一种情况是，当产品出现变更却没有做相应的计划调整。

• 典型错误27：鲁莽编码

　　没有足够的需求基础和清晰的架构设计而进行“边编码边修改”造成太多重复工作和返工，这样的做法使项目大多以失败告终。

---

 

产 品

• 典型错误28：需求的镀金

　　项目的产品要求要求比实际需求多得多的产品特性或复杂功能，却又不给进度计划分配足够的时间。

• 典型错误29：功能蔓延

　　在整个开发过程中，项目平均会有25%的需求变更，对软件计划至少有25%的影响。如果任由客户不断提出新需求，项目就会一直都做不完。

• 典型错误30：开发人员的镀金

　　开发人员着迷于新技术，有时渴望在自己的产品中使用这些技术，而不管那些技术是否适合或是否会对系统整体造成破坏。

• 典型错误31：又推又拉的交易

　　管理者批准进度落后的项目顺延，但同时又给这个项目加入新任务。

• 典型错误32：研究导向的开发

　　软件开发进度是完全有理由可以预测的，而软件研究进度甚至理论上都是不可预知的，不能采用像软件研究一样的工作方式引导项目开发。

---

 

技 术

• 典型错误33：银弹综合症

　　过于相信某些技术宣传（某种开发过程、某种程序设计方法、某种开发语言），缺少在特定环境下使用这些工具的必要信息。当团队寄望利用他们来解决进度问题时，不可避免会失败的。

• 典型错误34：过高估计了新技术或方法带来的节省量

　　无论采用多少新工具或方法，以及这些工具或方法有多好，他们很少能够大幅度提高生产率。软件开发由多个任务组成，特定的工具或方法只会可能提高特定任务的生产效率。同时，它们所带来的效率常常被学习它们所花费的时间抵消了。

• 典型错误35：项目中间切换工具

　　在项目中间更换工具时，伴随使用新工具而带来的人员学习和掌握的过程、重复的工作、不可避免的错误等会彻底抵消它所带来的益处。

• 典型错误36：缺乏自动的源代码控制手段

　　缺乏自动的源代码控制容易造成版本冲突、历时版本丢失、更新丢失等一系列问题，并浪费大量的时间处理这些问题。

该文章在 2012/4/9 10:31:56 编辑过