软件项目管理中的十个误区

随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。以下列举了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。 
 
　　误区1：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变 ，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少， 容易被实现。 

　　误区2：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码 进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试(实际上，程序员往往也是进行“白盒法”测试的最佳人选)。 

　　误区3：软件项目管理只是相关技术部门的事情，与公司其他部门无关。在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门(技术委员会)指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。 

　　误区4：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么"新人"的加入是有益的。否则，可能会"好心好意做坏事"。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培训，更重要的(也是难度最大的)是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。 

　　误区5：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在"软件作坊"时代，这是一种普遍使用而且效果不错的方法；而在"软件工厂"时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变--最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力(当然，可以两者均突出最好)。至于项目经理的薪水问题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。 

　　误区6：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。其实这是一种“官僚”的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对"成就感"的追求，应该向每一个人详细描述最终“作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把 这个消息告诉每一位项目成员，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。 

　　误区7：更大的压力可以带来工作效率的提高。软件公司的员工加班情况是时常发生的，对员工增加工作压力、要求加班赶进度，这种方式在初期可以略微提高生产力，因为员工喜欢压力，并且集中精力于项目任务，全力投入。中等压力或许可以将生产力提高25%，甚至使总的交付时间缩短25%。但是只有在压力处在适当的范围时，情况才是这样。压力再大点，增加的压力将不会产生作用，毕竟人的能力是有限的，当员工面对巨大的压力而习以为常时，会将普通的工作量占满整个工作时间，导致实际的生产力下降。如果压力再大一些，员工开始疲惫，直到筋疲力尽，甚至灰心丧气，他们对项目不抱有什么积极的态度，此时的项目结局可想而知。

　　误区8：使用高级语言可以大大提高项目进度，缩短交付期。高级语言相对于他们的前辈确实效率大大提高，程序员使用之可以提升编码速度，从而使整个项目的开发周期缩短；但是在完整的软件生命周期中，编码活动一般仅占总时间的20%左右，而需求搜集和分析、高层设计、测试等活动却无法从高级语言的使用中获益，所以不要认为运用了高级语言就可以制定一个“激进而且安全”的项目进度计划。

　　误区9：小型项目不需要严格的流程控制。小型项目由于涉及的人员较少，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别；开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。往往觉得“把这些事情(流程管理、项目文档)都做完的话，项目就永远做不完了！”事实是如果项目中不做这些事，就得花更久时间才完成得了。

　　误区10：软件产品的质量完全取决于过程。事实上产品的质量受到人员、技术和过程三个要素制约，片面强调过程决定质量就好像认为只有明星程序员才能开发出合格的软件一样片面。而且低劣设计和良好设计之间的区别可能在于设计方法中的完善性，而良好设计和卓越设计之间的区别肯定不是如此。卓越设计来自卓越的设计人员。软件开发是一个创造性的过程。完备的方法学可以培养和释放创造性的思维，但它无法孕育或激发创造性的过程

原文转自：http://www.ltesting.net