没有合适的资源?快使用搜索试试~ 我知道了~
关于IT行业的绩效考核
3星 · 超过75%的资源 需积分: 20 113 下载量 143 浏览量
2009-07-07
10:06:59
上传
评论
收藏 69KB DOC 举报
温馨提示
试读
19页
关于IT行业的绩效考核——研发测试人员 研发人员绩效考核的原则和方法,以及测试人员的绩效考核的原则和方法
资源推荐
资源详情
资源评论
关于 IT 行业的绩效考核——研发测试人员
一、研发人员绩效考核的原则
研发人员是企业技术创新的主体,他们的工作成果直接影响着企业的效益和竞争力。对于研发人员的绩效考核应遵循以下原
则:
结果考核与行为考核相结合,以结果考核为主
对于研发人员来说,在考核中如果过于强调对行为的考核,会带来一系列的错误导向。因为如果过于强调行为,员工会更关
心做事的方式,而不是做事的结果。在现实中,我们经常碰到这样的情况:一个不准时开会、从不加班加点、不注意搞好人际
关系的研发人员却能够为企业设计新的工艺,为企业节省巨额资金、取得数项专利、在很有声望的杂志上发表论文、被特邀做
学术报告等;另一个研发人员与他相反,行为上循规蹈矩,完全符合考核的要求,但没有什么实际的贡献。假如过于重视行为
评价,后者的得分会高于前者,你觉得合理吗?当然,行为指标也是需要考虑的考核指标,但对于研发的整体业绩来说就不那
么重要了。
(二)外评与内评相结合,以外评为主
内部评价,包括进度、预算等评估是必要的,但过分强调内部评价是很危险的,因为内评很可能不太关心研发对企业的实际
价值。内部评价作为企业内部的质量控制工具是很重要的。但是,评价的目的应该强调外评。外评非常重要,作用比较大,比
如说用新工艺设计带来的收益来衡量研发的效果。
(三)价值评估与产出评估相结合,以价值评估为主
只对研发产出进行评估是不够的,必须对研发为企业带来的价值进行评估,即研发效果的评价。赢利性是企业的本质特征,
企业不会容许研发经理只用如下指标进行考核:拟订了多少研究方案、发表了多少论文、做了多少设计、设计出了多少产品、
做了多少次展示、获得了多少专利、完成了多少项目……研发的效果更重要地体现在新产品的开发、成本降低、销售量上升、
产品改进、市场占有率等方面。
(四)评价系统要尽量客观
在评价研发业绩时,数量是非常客观的指标,但是,质量和成本数据往往是十分主观的。尽管不可能用十分客观的方式测评
质量,但在设计评价过程时可以尽量减少主观性。一个比较简单的方法是尽可能用外在的数据来评价研发业绩的质量。比如说,
如果你想估计产品改进的价值,你可以请工程和制造人员来估计,而不是让研发部门经理来估计他们成绩的价值。
二、研发人员绩效考核的流程
考核的流程通常包括绩效目标设定、绩效评价、绩效反馈与沟通、绩效改进等环节,循环进行。
(一)设定绩效目标
1.目标设定原则
设立绩效目标着重贯彻三个原则。其一,导向原则。依据企业总体目标和部门目标,层层分解,设立个人目标。其二 ,
SMART 原则。即目标要具体(Specific)、可衡量( Measurable)、可达到( Attainable)、相关的( Relevant)、有时间限
定(Time-based)。其三,目标数量适中原则。目标不要太多,最多 6~8 个
2.目标的设定
对研发人员来说,一般要设定业绩目标和能力发展目标,业绩目标由项目团队目标分解到个人,能力发展目标则要研发人员
根据高绩效研发人员的能力要求,结合个人兴趣来制订个人的能力发展目标,在掌握的技术、完成工作效率、解决客户问题能
力等方面制定相应目标,并制定达到该目标应采取的行动计划。然后由上级根据企业目标进行认可。
(二)绩效考核指标体系的设计
1.设计的原则
考核研发人员的首要原则是考核指标必须紧密结合企业战略,如果企业的竞争策略是先于竞争对手推出新产品,就可以把上
市时间(time to market)或产品开发周期作为首要的考核指标;如果企业的竞争策略在于低成本,则把产品成本作为首要要素 。
第二个原则是研发部门、研发小组和研发个人的考核指标必须息息相关,是由上而下的指标分解过程而形成的体系。第三是根
据研发策略,平衡好长期性与短期性指标、绩效指标与行为指标之间的关系。
2.指标体系
(1)业绩指标
企业的研发人员主要分为项目经理、开发人员、测试人员等,对不同的研发人员,业绩考核的指标有所区别。项目经理的业
绩指标主要有:新产品开发周期、技术评审合格率、项目计划完成率、项目费用控制、客户满意度、团队士气指数等;开发人
员的业绩指标主要有:项目计划完成率、项目流程、规范符合度、设计的可生产性、设计成本降低率等;测试人员的业绩指标
主要有:测试问题解决率、运行质量、计划完成率、开发过程规范符合度等。
(2)行为指标
对于研发人员工作行为的评估,可以从主动性、服从性、责任心、协作精神、工作合理性、纪律性等方面进行考评。
(3)能力指标
可细分为业务知识、业务技能、计划能力、判断能力、解决问题能力、应变能力、人际技能、理解能力、学习能力、创新能
力和领导控制能力(这项能力及以下能力适用于部门经理以上的管理人员)、决策能力、指导帮助下属能力 、组织能力、员工
管理能力等。
考核的目的不同,考核所采用的指标体系也有所区别。如果要考评研发人员过去特定一段时间的工作表现,且考核结果将用
于加薪、发放奖金、红利等奖励,考评指标体系主要为业绩指标和行为指标;如果考核目的为员工前程发展,且考核结果将用
于教育培训、能力开发、升迁、调动等人力资源规划与配置,考核指标体系应包括业绩指标、能力指标和行为指标。各指标之
间的权重也因考评重点不同而相应变化。
四)持续沟通与绩效反馈
研发人员可以说是企业的核心员工,对企业的生存与发展具有极其重要的作用。经常与研发人员进行沟通,了解他们的心理
动态十分必要。如一家软件企业的研发副总去检查项目工作时,看了一名测试工程师的报告后,严肃地批评:“你的测试报告不
及格。”两个月后该测试工程师离职了。后来该工程师给企业写了一封信,吐露了他离职的原因——仅是研发副总的一句批评。
研发副总颇为后悔地说:“我对他的批评只是道出了实情,但如果事后我对他的进步予以表扬、鼓励,事情完全会是另外的样
子。”可见,绩效的沟通、辅导及反馈十分重要。
沟通贯穿整个绩效考核的全过程,而不只是在某个时点、某个环节上交换信息,如绩效考核流程示意图中所示。首先,在绩
效目标的设定过程中,研发部门主管要与研发人员进行沟通,让员工明确部门目标,帮助他们根据部门目标确立自身目标。其
次,对研发人员的考核指标和标准的确定,应该和研发部门的主管以及研发人员进行共同讨论,获取考评人与被考评人的认同。
然后,在绩效评估结束后,上级要把考核结果及时反馈给下级,并与下级进行沟通,以避免黑箱操作,同时有利于下级改进工
作。
(五)绩效改进指导
绩效评价结果反馈给员工后,如果不进行绩效改进和提高的指导,这种反馈就失去了意义。绩效改进指导主要帮助员工分析
绩效不足的原因或改进提高的机会,帮助员工寻求解决的办法,并制定绩效改进的目标、个人发展目标和相应的行动计划,纳
入下一阶段的绩效目标中,从而进入下一轮的绩效考核循环。
每一个测试经理都面临这样的问题,如何对测试人员进行绩效考核。因为测试人员参与的工作不单一,需要的技能也各种各样,
考核测试人员的绩效似乎不是很容易的事,除了一般需要考核的对工作的态度,工作的责任心,积极性这些方面以外,还有一
些其它方面的内容。
要想对测试人员进行考核,就需要开始工作的时侯明确测试人员的职责,对测试人员的期望等,一个团队中不同的测试人员
可能职责不同,比如测试负责人,测试设计人员,自动化测试人员,普通测试人员等,那么对这些人的期望也是不同的,进行
绩效考核的时候需要根据对测试人员的期望进行考核,而这些职责和期望测试人员也是很明确的。
测试人员可能参与不同的软件开发过程,比如需要参与需求和设计的评审,那么也需要对这些工作进行考核,比如需求评审
时可以从测试人员对需求的理解上,测试人员对需求提出的问题的质量上等作出评价。
如果需要测试人员准备测试文档,如测试用例等,那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例
的质量,对需求的覆盖程度,可理解和执行等方面来判段一个测试人员的能力。
对于执行测试的测试人员来说,可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简
单的,是隐藏比较深的,还是一些表面的问题。还可以从问题的书写上进行评价,问题的书写是否详细清晰,开发人员可以再
现,还是含糊其词,不明所以。或者测试人员书写的问题是否是自己的操作问题,一个问题是否写多遍等。
而对于已经发布的产品,也可以从用户反馈的问题来考核测试人员的绩效,但是这个可能需要的时间比较长。
测试人员的沟通能力也是考核的一个方面,无论是书面的还是口头的,测试人员都应该有较好的沟通能力。
另外测试人员的接受指示,把握细节的能力也应该进行考核,测试经理希望把任务分配给可以按照指示完成的人来完成,如
果测试人员自行其事,即使技术能力比较强也对工作无益。
首先我们不能单纯的以测试人员提交的 bug 数量进行考核,那样的结果可能会导致测试人员为了 bug 数量而互相攀比,导致
bug 质量的下降。
所以我觉得下面这几点可能会更合理一些(仅供讨论):
1:有效 bug 率 用来衡量测试人员发现的,被确认为缺陷的有效缺陷比率,比率越高则测试质量越高。这个比率剔除被开发
人员拒绝修改和删除,以及重复的 bug 之后,剩余缺陷数占缺陷总数的一个比率。
测试人员不能只重视 bug 的数量,为了让领导感觉测试人员每天都在工作而随意的提交 bug,从而导致 bug 数量很高,但
质量很低。造成很多 bug 都被拒绝修复或者 bug 不能重现以及 bug 重复报告等问题。
2:测试覆盖率 主要用来衡量测试人员对功能点遗漏测试的情况。我觉得这适合测试组人员较少的公司,每个测试人员要单
独负责一个完整的项目,在这种情况下,进行这样的衡量是有必要的。
3:bug 描述质量 主要衡量测试人员对于 bug 报告的描述情况。bug 报告的描述是否清晰、简洁。开发人员是否能很容易的
理解并依据报告描述重现 bug。很多情况下开发人员拒绝修改 bug 是因为 bug 报告的描述很难理解,并且依据描述不能重现
bug 等。
4:严重 bug 率 主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷。这有助于让测试人员将注意力集中在关键问题
上,减少产品的致命缺陷。
5:市场反馈缺陷率 产品正是发布推向市场后,客户在使用产品的过程中发现的缺陷数占缺陷总数的比率。用来总体衡量测
试组整体的工作情况。
长期以来,如何考核测试人员的工作是富有争论的话题, 一个理想化的方法是
收集测试阶段之后项目阶段的缺陷来确定系统测试的质量。但是,这种方法的
不可操作性在于:一是维护和实施阶段的缺陷难于收集;二是缺陷贯穿产品的
整个使用周期,无法穷尽,难于将时间段分割开来比较;三是成本过于庞大,
时间跨度过长,起不到有效激励的作用。能不能就在项目过程中寻找可以评价
测试人员工作的方法呢?就这这个思路,本人摸索出一套有效的办法。
首先声明的是,第一,这套考核方发在一个功能点估算超过 10000 个的项
目中经过实践,但是对于小项目而言,可能缺少足够的数据和必要性;第二,
项目组内考核的成功不能意味着在测试部门内可以采用类似的考核方法,仅提
供一种参考方法,部门考核可能更多考虑投入工程的工作量大小和任务分配重
要性;第三,除了量化指标外,测试人员工作态度、工作能动性和技术学习意
愿要通过定性分析来得到。
项目组测试人员考核主要包括工作效率和工作质量两大块,工作效率用于考
察活动,而工作质量用于考察产出物质量。由于考核基于测试过程进行,因此
必须在过程结束之后才能进行。当然,由于工程是分布提交测试的,每月可以
根据实际情况进行月考核,工程结束后或任务结束后在统一考核。按照传统测
试周期,测试过程分为:测试计划、测试设计和测试执行三个方面进行。测试
计划属于测试经理的范畴,在最后讨论。测试人员主要是测试设计和测试执行,
测试经理的考核可包含在测试人员的考核内,当然,这部分考核也可以纳入项
目组中进行。考核指标如下:
一 测试设计
工作效率相关指标
文档产出率 这项指标值主要为测试用例文档页数除于编写文档的有效时间获
得。用于考察测试人员测试用例文档的生产率大小。
公式:∑测试用例文档页数(页) / ∑编写测试用例文档有效时间(小时)
参考指标:根据项目汇总得出平均在 1.14 页 / 小时左右,高于此值为优,
低于此值为差。
用例产出率 这项指标值主要为上述指标值的补充,用于考察测试人员测试用
例产出率大小。测试文档页数可能包含的冗余信息较多,因此要查看文档中测
试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有
效时间。
公式:∑测试用例数(个) / ∑编写测试用例文档有效时间(小时)
参考指标:平均 4.21 个用例 / 小时
工作质量相关指标
需求覆盖率 计算测试用例总数之和除于与之一一对应的功能点数之和,主要
查看是否有功能点遗漏测试的情况。
公式:∑测试用例数(个) / ∑功能点(个)
参考指标: 100 %。如果连功能指标都不能满足 100 %覆盖,起码说明测
试不充分。这个指标收集起来相当困难,如果存在需求跟踪矩阵或者测试管理
工具能把用例与需求一一对应就容易得多。
注意:有的功能是难于测试的,那么未能覆盖到的需求要综合分析,明确是
测试人员遗漏?还是无法测试?这需要放入问题跟踪表中进行后续跟踪;另外,
有的功能点包含的信息较多或者有的用例包含几个功能点,这时只能把重复的
功能点或重复用例按一个计,难于区分的要做说明。
剩余18页未读,继续阅读
资源评论
- sonictwb2012-08-31对指定绩效考核制度有帮助
- lonenan2018-06-22差评差评差评
neihou
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功