研发项目开发效率的影响因素浅析

发布日期:
2015-10-23

浏览次数:

适应日益加剧的竞争环境、把握瞬息万变的市场信息是企业得以生存和发展的基础,某大型IT公司估计其产品推迟上市一个月将导致收入减少530万(人民币)、利润减少265万、还要付出另外的研发费用37.5万。这就对产品研发项目提出了更高的要求:如何在有限的资源投入下以更快的速度满足或者超越用户的需求。

在提高研发效率方面,业界已经进行了大量有益的探索和实践,下面是几种较有代表性的见解:

l  过程/流程决定一切(强调过程的重要性);

l  人是生产力的决定因素(强调人的重要性);

l  采用XXX编程工具,可以使您的开发效率提高一个数量级(强调工具的重要性);

l  良好的计划是项目成功的一半(强调项目管理的重要性);

              ……

尽管每种见解都有大量的拥趸(无论处于业务还是商务角度),但是仍然会遭到大量的挑战而不能自圆其说,从研发项目的实践来看也同样反映了“瞎子摸象”的现象:好像每种见解都是对的,但是又不完全对。

根据美国项目管理协会的定义:“项目管理是在项目活动中运用知识,技能,工具和技术,以便达到项目要求”;项目管理的目标是在给定的资源、预算和时间内安全地完成符合质量要求的项目。以上定义意味着项目的资源、预算、时间和项目范围有着内在的约束关系,在这四个因素已经被“极其乐观”的限定的情况下,项目最终无法完成——项目经理常常会遇到非常紧张的、不可能完成的Deadline,如何应对?项目范围的约束关系告诉我们手中的王牌包括增加人手(有时候人多反帮倒忙,可以参考《人月神话》)、投入更多资源(部分模块外包、使用COTS、购买最好的开发/管理工具)、削减项目范围/需求(承诺在后续版本中提供某些功能,但是用户未必会认同)、降低质量(软件项目交付质量的降低往往意味着客户需求没有完全实现,用户也未必会认同)。

更深一个层次,多个因素影响了研发项目的开发效率,片面强调某一个因素而忽略其他的因素,都无法揭示项目实践中遇到的问题。这里引用一个老笑话:

有个警察看到个喝醉的人在路灯下找东西,他就问:你找什么?那个醉鬼说,车钥匙下车时掉了,我在找。警察问:你不在掉的车子附近找,怎么到路灯下找呢。醉鬼说:那里黑啊,这里亮啊,好找!

其实很多项目经理或者咨询机构都在犯类似这个醉鬼的错误,不管是有意或是无意的——试图在自己最熟悉、最容易控制的因素上寻求突破,而对自己陌生的、难以控制的因素却置若罔闻,尽管它可以为项目带来更大的回报。我推测很大程度上是由于“人类本能的需要心理安全感”。

那么,到底哪些因素影响了开发的效率、他们又能够在多大程度上造成影响?下面的资料是Capers Jones在《Software Assessments, Benchmarks, and Best Practices》中使用的数据,这是目前为止最新资料(虽然量化管理是管理追求的较高层次,但是现在度量方面的专著却几乎绝迹,可能是商业利益使然)。

影响软件项目生产率的积极因素(以影响程度排序):

项目因素

影响程度(%)

项目因素

影响程度(%)

高质量可交付产品复用

350

正式审查的使用

15

高水平的管理人员经验

65

好的办公室人体工程学

15

高水平的技术人员经验

55

低的项目复杂度

13

有效的方法与过程

35

适度的进度压力

11

有效的管理工具

30

生产率测量

10

有效的CASE工具

27

低的需求蔓延

9

高级程序设计语言

24

10天以上的年度培训

8

质量评估工具

19

开发团队分布集中

8

细的岗位分工

18

高昂的团队士气

7

有效的客户参与

18

分层管理机构

5

正式的成本与进度估计

17



 

影响软件项目生产率的消极因素(以影响程度排序):

项目因素

影响程度(%)

项目因素

影响程度(%)

低质量可交付产品复用

-300

拥挤的办公空间

-27

管理人员缺乏经验

-90

低级语言

-25

技术人员缺乏经验

-87

工作场所分散

-24

高的需求蔓延

-77

非正式的成本与进度估计

-22

不适当的CASE工具

-75

岗位分工不细

-15

没有使用审查

-48

没有客户参与

-13

不适当的管理工具

-45

没有年度培训

-12

无效的方法与过程

-41

平面式的管理结构

-8

无质量评估

-40

没有生产率测量

-7

项目很复杂

-35

低的团队士气

-6

过大的进度压力

-30




从上面的数据中可以有很多新的发现,当然是仁者见仁,智者见智:

l  同一要素的不同影响:相同的项目因素,例如“管理人员经验”,对项目生产率的正面影响为65%,也就是说管理人员具备高质量的管理经验,最高可以使生产率提升65%;而蹩脚的管理人员却对生产率造成最高90%的下降。65%对比-90%,并不相同,这一点在“需求蔓延”上面表现的最为突出,是9%对比-77%。这说明了相同的事情如果做的不好,带来的负面影响远远大于将其做好而带来的积极影响;

l  产品/模块复用:复用可以包括平台化开发、模块重用等,高质量产品复用所带来的收益是惊人的,但是如果有问题的模块被复用,就会对相关产品均造成负面影响,这种影响被批量放大,解决起来也更加困难;

l  人的问题:我们会发现管理人员、技术人员的能力经验对项目造成很大的影响,在这方面的努力会得到很好的回报:不少公司愿意在营销运作、过程改进、设备引进等方面投入巨资,在引入和培训人才方面缺乏力度,初衷是认为“人”在短期内不可改变,即便是这样,对“人”视而不见,长期看来只能是在低水平踏步;另一个问题,项目经理往往会认为项目团队的成员是短板,事实却常常相反,项目失利源于经理的经验不足,对项目丧失控制,“能力越大,责任越大(“With Great Power, Comes Great Responsibility”,Uncle Ben to Peter Parker in Spider-Man)”,不断提升应该是管理者的必修课;

l  需求:产品需求可以看作射击的目标,如果目标没有找准或是错误的,项目必定走向失败。需求对于项目的重大意义无论怎么强调都是不为过的,几乎每个项目经理都会被“需求蔓延/变更”折磨过,但是真正能够从中吸取教训的比例却相当少;

l  管理工具/编程语言:运用恰当的管理工具/编程语言会极大的提高工作效率,例如项目管理工具、配置管理工具、团队交流工具、集成开发环境等,但是却不能指望工具可以改变项目的命运或者产生数量级的飞跃,因为整个项目的工作不仅仅是编写代码,需求分析、系统设计、测试设计、评审等活动不能由工具完全代劳;此外,过分迷信工具的效果反而会削弱对其他因素的关注程度;

l  流程:CMM/CMMI的影响已经将过程的重要性渲染得无以复加,但是令人失望的是它只有30%-40%的影响,其实在其他因素不变的情况下,哪怕只有10%的改善已经非常可观了;过程改进方面过犹不及,不顾公司的商业收益而片面强调规范化、一味向某个所谓“业界最佳”实践看齐,更像是一场无收效的做秀而不是真正的过程改进;

l  进度估计与控制:现在已经有很多成熟的估算方法和工具,那些复杂的方法并不见得比相对简易的方法拥有更好的准确度,关键是方法运用和熟悉的程度;适当的进度压力可能刺激开发人员的工作积极性,但是过大的进度压力却可能导致追求进度而放弃产品质量,结果就是产品不稳定,开发周期拖长,直到大家都已经不耐烦了才勉强发布;

l  团队士气:尽管这个因素的影响程度并不大,但是相比耗资巨大、周期漫长的过程改进活动,其投资回报是非常高的。开发团队具备高昂士气并且由衷的愿意为项目做贡献,就会主动的高质量完成工作,这是任何流程规范无法比拟的。电影《勇敢的心》、《特洛依战争》、《魔戒》中,在英雄们率领他的部队展开诗史般的冲锋之前,都会发表一番激情洋溢的演说,用意就是激励起部队斗志,显然这样会比士气低落时的胜算要大很多。但是一味的强调“精神胜利”是不够的,古人曾总结出“一鼓作气,再而衰,三而竭”,试图激励士气并不是一件很容易的事情,不过挫伤士气倒是轻而易举的;

项目管理是一门寻求平衡的艺术,即凭借有限的资源最大程度的满足项目干系人的期望;上述的表格只是众多因素的一个子集,不同的项目在不同的阶段可能会出现不同的短板,这就是我们改进的机会所在。

相关推荐