|
软件研发项目管理最早源自于70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因,发现70%的项目是因为管理不善引起的,而并不是因为技术实力不够,进而得出一个结论,即管理是影响软件研发项目全局的因素,而技术只影响局部。这个结论非常重要。到了90年代中期,软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。针对软件项目管理不善的局面,我简要谈谈在软件项目管理中存在的一些问题。项目管理者联盟
1 客户需不需要全程参与项目管理者联盟
不少软件企业认为客户的参与主要在三件事情上:协议签订和需求调研、客户需求变更和项目验收签字,其它事情是企业内部项目开发管理的事情,属公司内部行为,无需客户参与。结果,企业经常发现客户严重拖延验收,而且在验收期间客户大量的需求变更,致使项目的进展严重推迟。经常一个预期盈利的项目,最后拖的不堪重负。项目管理者联盟文章
我认为这里边的一个重要原因就是客户没有参与项目的全过程。比方,项目初期的启动会议、项目过程中所有干系人的知情制度,每周的工作例会、项目阶段性工作总结等等都需要客户的参与和反馈。否则当企业一年之后提交一个无比庞大和复杂的最终方案时,客户方根本不了解你的方案的进程,由谁敢签字验收呢?客户只能花上几个月来完全“肢解”消化整个方案,最终当然是发现一大堆问题需要改进,企业只能再花上几个月重新修改,如此往而复始,恶性循环。项目管理者联盟
2 如果需求分析很困难,可不可以先做软件talent.mypm.net
对需求把握得越准确,软件的修修补补就越少。有些需求在一开始时很难确定,在开发过程中要不断地加以改正。软件修改越早代价越少,修改越晚代价越大,就跟治病一样道理。pmp.mypm.net
一是在项目的需求分析阶段,开发方与客户方在各种的问题的基本轮廓上达成一致即可,具体细节可以在以后填充。软件过程改善是一个持续改善的过程,需要不断地学习,需要知识的积累,特别是当主客观环境发生变化时,需要对过程进行修改,以适应变化了的情况。无论多么细致的需求分析,几乎都难以避免修改。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致,导致后来预算超出或者时间 进度达不到要求。这就要求在项目需求分析阶段,开发方与客户方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求,以及对项目进行评估的各种评价标准。并且,在需求分析结束以后,双方还要建立可以直接联系的渠道,以尽早地对需求变动问题进行沟通。项目管理者联盟
3 软件项目需求的改变容易实现吗项目管理者联盟
在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进,往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过,这并不表明“软件项目的需求可以持续不断的改变 ,而且这些改变可很容易地被实现”。实践表明,随着开发进度的推进,实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改需要花费1倍的代价;那么,在系统设计和编码阶段,需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软件版本发布以后,甚至可能要花费60-100倍的代价。由此可见,在项目开展过程中,软件需求的改变应当尽量早地提出。这样才可能花费少,容易被实现。项目管理者联盟
4 项目的质量提高是否要依赖完善的质量测试制度项目管理者联盟
不少企业把软件的测试工作定位于提高软件开发项目的质量。我认为质量测试制度只是一个补救措施,是来挑出各种因素造成的缺陷,但不能避免新的缺陷的出现。真正有效的质量管理是建立在一套质量保证体系上的全过程质量管理方案,每一个环节的规范化管理是质量保证的一个基础,除此之外,规范的项目方案评审制度也是质量保证的必备步骤,经常客户对质量的评价首先是方案质量的优劣。有效的、科学的测试制度也将有助于在提交客户之前发现设计中的问题。项目管理培训
5 所有的内部测试工作是不是全部应该由测试人员完成项目管理者联盟
软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求,在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试;如果测试没有通过,不得已这才考虑对程序代码 进行“白盒法”测试。显然,这种对“白盒法”有意无意的“逃避”,对软件的可靠性和稳定性构成了威胁。如何解决这个问题?一方面需要提高对测试人员的要求,另一方面也需要程序员完成部分的“白盒法”测试。项目管理者联盟
6 如果我们落后于计划,是否可以增加更多的程序员来解决项目管理者联盟
客观情况是软件开发不同于传统的农业生产,人多不见得力量大。如果给落后于计划的项目增添新手,可能会更加延误项目。因为:1)新手会产生很多新的错误,使项目混乱。2)老手向新手解释工作以及交流思想都要花费时间,使实际开发时间更少。所以科学的项目计划很重要,不在乎计划能提前多少,重在恰如其分。如果用“大跃进”的方式奔向共产主义,只会产生倒退的后果。投入项目上的人力,多多益善。在某些业务项目上确实如此。但在系统项目管理中却很少是这样的。人们的技能和知识是不能互换的。如果多一些人加入到系统项目中来,由于协调不利和要培训人员以快速适应工作,通常会减慢项目的进度。bbs.mypm.net
7 技术骨干是否应该成为项目的项目经理service.mypm.net
项目经理一定是所有项目成员中薪水最高的。在“软件作坊”时代,这是一种普遍使用而且效果不错的方法;而在“软件工厂”时代,这种方法却带来各种问题,有时甚至直接导致项目失败。究其原因这主要是因为随着现代软件开发分工的细化,对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术的掌握程度,而是其组织、领导、协调开发团队的能力。至于项目经理的薪水问题,这和定薪制度有很大关系。通常,项目经理执行的是管理人员的薪酬体系,而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的,但不一定是最高的。有时候,为了激励技术人员,项目中的技术骨干得到的酬劳比项目经理要高。www.mypm.net 项目管理者联盟
|
