在软件企业实施敏捷和CMMI的绩效管理方法

发表于:2012-10-08来源:思步网作者:step365点击数: 标签:cmmi
在软件企业实施敏捷和CMMI的绩效管理方法.周末接到漂下达的编写一篇有关绩效管理文章的指令,让我不经想起前段时间折腾了2个月的绩效管理体系,总结了一点儿心得和大家分享一下。 在下笔前,研读了上期《关于绩效》的文摘,发现很多大家的言论,都不太赞成绩效管

  前言

  周末接到漂下达的编写一篇有关绩效管理文章的指令,让我不经想起前段时间折腾了2个月的绩效管理体系,总结了一点儿心得和大家分享一下。

  在下笔前,研读了上期《关于绩效》的文摘,发现很多大家的言论,都不太赞成绩效管理。比如:Frederick Herzberg如是说:“奖励只会产生行动而不是动力。奖励完成出色的工作只会激励员工想要更多的奖金而不是更好的工作。”戴明也说:“所有评估工作的结果是事与愿违的”。

  以上言论,与John Kennedy Effect从相反的两个方面阐述了对绩效管理的看法。相比之下,我更赞同肯尼迪的。就像肯尼迪在演讲中所说:所谓绩效管理,就是一种沟通,使人们提升自己以达到比自己强大很多的境界—而不是独裁者使用的工具。它是一种进行中的计划,辅导,回顾,和奖赏的过程;它可以鼓励人们达到他们的目标,重要到就像把人类送上月球!我个人觉得绩效管理对员工还是有用的。

  就像下面这个小故事所反映的,每个人对事情的看法,也反映出他自己内心真正的态度。

  父子二人经过五星级饭店门口,看到一辆十分豪华的进口轿车。

  儿子不屑地对他的父亲说:“坐这种车的人,肚子里一定没有学问!”

  父亲则轻描淡写地回答:“说这种话的人,口袋里一定没有钱!”

  企业以盈利为目的,不能照顾所有员工的感受。只要是适合企业发展,促进企业壮大的措施,就会被采纳并执行。作为员工的我们也只有适应这个形势,应势所需而发展。

  绩效管理与过程改进的亲密接触

  在实施CMMI的过程改进中,特别强调不能使用度量数据来进行考核,否则就会导致作假使数据失真,这样度量就失去了起初的意义。在我们研究绩效管理和过程改进体系的时候,发现了绩效管理和过程改进的共通性,项目的考核指标分解与项目的任务分解不谋而合。我们将绩效管理和过程改进进行了如下的亲密接触。

  项目经理按照项目计划和项目成员的岗位说明书安排工作,计划说明具体应该做什么事,工作表明具体由谁来做,两者结合安排具体工作。

  任务安排的形式有项目计划、周会、周报和其他一些实时触发的非正式的形式,如面对面的沟通,邮件,即时通讯工具。

  项目成员按照项目经理分配的任务目标开展工作,对于活动的输出产品需要有不同形式的确认,比如,在产品实现阶段,对于项目成员编写的代码,应该有代码规范检查,应用静态和动态的检查工具进行代码质量评估。有些任务不容易考察结果,项目经理可以考察其过程,只要遵照项目组内部的流程或规则,就算符合要求,如遵循配置管理工具的Check in、Check out的规则。

  项目成员需要填写《项目成员工作报告》,分为每天的日报,每周末的周报,每月末的月报,项目经理在其中填写“质量评分”一栏,质量评分的取得是项目经理在QA的配合下取得的,由QA提供考核技术的支持。

《项目成员工作报告》如下图所示:

  绩效考核中谁主沉浮?

  在应用绩效管理体系中,增加了项目经理与项目成员对任务的沟通时间和频率。质量评分统计出来后,项目经理进行排序,并按照韦尔奇“活力曲线”分为A,B,C三类。

  如果是在绩效管理主观评价阶段,项目经理是很难做出这样的判断的。现在我们通过对每天、每周、每月的任务进行量化,项目经理就很容易对项目成员按照百分比进行分类。项目经理所需要做的,是对B类的人员进行培养,使之往A类发展,淘汰不适合团队生存的C类人员。年复一年,项目的整个能力层次就会有所提高。这是一个动态的过程,没有人敢确信自己能永远留在A类当中。

  绩效管理的有效使用,使项目成员脱离了大锅饭的年代,促进项目成员往好的方面进行发展。从C类走向B类,从B类走向A类。无论在什么公司,或者什么社会,最好的资源总是为最优秀的那批人服务的。在盛大网络12月22日发布的2010年三季度《员工发展报告》,过去三个月内,在纳入游戏式管理体系下的4000名盛大网络员工中,40%的员工自动获得职级晋升和薪资增长,10%的员工获得职级大类晋升。这就引发了很多普通的员工对绩效管理系统的质疑,让我们仔细揣摩一下盛大网络人力资源总监的反馈,“绩效管理系统的主要任务是发现、吸引和留住优秀员工,让他们有机会脱颖而出。任何一个公司,都不可能所有人都是优秀员工,这个比例在全体员工中通常是20%-25%。如果每个人都感觉升得很快,这其实是不正常的。”

  可见,绩效管理最终是为企业服务的,而非为我们每个打工者服务。我们要正视自己是打工者的事实,作对企业有用的那批人

  在产品项目开发实施及准备认证的过程中,项目开发团队与质量管理团队的观点碰撞冲突不断。项目开发团队希望集中精力处理技术细节、研究产品开发,质量管理团队按照CMMIL3对质量管理体系的要求,建立项目管理过程中需要形成的大量项目文档模板,并跟踪检查项目文档记录,两个团队工作目标、方向及重点不同,成为双方讨论的焦点。

  从产品项目团队的角度来看:项目组不但要完成待发布版本的软件程序及软件工程文档,还要根据CMMIL3对质量管理体系的要求出具项目过程文档,工作范围增加了,又增加了项目管理过程可视化、质量管理文档化的要求,进度和成本也必须进行相应的调整。项目组需要在产品发布的市场压力、有限的资源限制下,减少项目开发的工作内容,按照CMMIL3要求做好项目及开发过程资料整理,实现知识的传承、文档的可追踪及度量数据的分析。这个调整本身导致项目经理、度量员、配置管理员、质量保证员在正常软件工程领域之外,必须要有额外的负担,形成项目管理过程域及支持过程域所要求的文档。其中项目管理过程域涉及项目计划、项目监督和控制、风险管理三个过程;支持过程域涉及配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案四个过程。

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

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)