项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 博客 圈子

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
价值源于交流与分享
会员区:
登陆ID 密  码
功能区: 公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册






 项目型组织  项目管理  工程项目  科技项目  项目化管理  管理软件  资格认证  职业休闲
EPM体系与流程 综合集成管理 总承包管理 IT软件开发 项目型制造 P3E/P6 PMP | PgMP 职业发展探讨
组织与人力资源 进度,范围,成本 国际工程 生物制药 专业服务 微软PROJECT IPMP | PRINCE2 管理学堂
项目管理信息化 团队建设与沟通 房地产 汽车设计开发 生活项目 PowerOn专版 软考项目管理 英语角|读书版
多项目与大项目 质量与风险 监理与咨询 手机数码 文体娱乐 注册建造师 房车吃游
PMO建设与管理 采购与合同 工程设计 项目管理硕士 闲聊版|商务版
俱乐部北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立 TOP榜精华 | 最新 | 最热 | 会员

版面信息

说明:探讨关于项目管理软件系统的定义,设计,开发,应用和实施等,借助项目管理软件系统提升项目管理绩效

本版版主

roadfar
登录:2018/8/2
次数:218
注册:2008/11/25
发帖:159
penny
登录:2022/3/25
次数:63
注册:2008/4/18
发帖:53

俱乐部导航

北京大连福州广州杭州
南京山东上海深圳四川
天津武汉西安郑州 

联盟·近期活动

社区热点

开放讲座|项目组合管理与PfMP认证
开放讲座|PgMP:项目管理思维与方法
开放讲座|《项目组合管理与PfMP认证
网络讲座|《项目组合管理与个人职业
开放讲座|《项目组合管理与PfMP认证
网络直播|产品经理的四大核心技能提
如何轻松拿下PgMP?免费学习机会--.
国际项目组合经理PfMP访谈:张富贵
由PMO评论主办的第十二届中国PMO大.
如果不参加这次直播你会痛失一次学.

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

更多:

推荐信息

·项目经理沙龙俱乐部
·推荐项目管理公开课程
·联盟VIP会员服务
·联盟99元大课堂
·建造师课程辅导免费试听

社区圈子

项目经理职业生.
圈主:zhenjm
行业:综合应用

项目管理知识宝.
圈主:wenyu2010
行业:工程设计安装

软件项目经理水.
圈主:camer
行业:IT软件

集团企业生态体.
圈主:ETPPM
行业:综合应用

深圳IT项目管理
圈主:lshcom
行业:综合应用

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net


版权所有 © 2003-2004
京ICP证070584号 
BBS业务许可2007第353号 
最佳显示模式:1024*768像素
项目管理与PMP认证
软件项目管理中的十个误区 [发表于 2006/6/16]
状态 开放帖 浏览量 972   
  随着计算机硬件水平的不断提高,计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进,计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法,完成思想观念上的转变。以下列举了10个在现代项目管理中思想观念上容易陷入的误区,希望能够抛砖引玉,引发大家更多的思索和讨论。

  误区1:软件项目的需求可以持续不断的改变,而且这些改变可很容易地被实现。的确,在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进,往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过,这并不表明“软件项目的需求可以持续不断的改变 ,而且这些改变可很容易地被实现”。实践表明:随着开发进度的推进,实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价;那么,在系统设计和编码阶段,需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软 件版本发布以后,甚至可能要花费60-100倍的代价。由此可见,在项目开展过程中,软件需求的改变应当尽量早地提出。这样才可能花费少, 容易被实现。

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

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

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

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

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

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

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

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

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

本文转自《新浪财经 》。

--------------------------------------------------------------------------------------------------------
日出东海落西山,愁也一天,喜也一天;
遇事不钻牛角尖,人也舒坦,心也舒坦!
>>> 由论坛统一发布的广告:
楼主 美女约,不在线,有人找我吗?lanny


职务 无
军衔 主帅
来自 石家庄市
发帖 1648篇
注册 2006/3/9
PM币 11397
经验 6476点

  
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号