月度绩效考核表(IT工程师)

月度绩效考核表(IT工程师)

月度/季度绩效计划/考核表(中层及以下适用)

1 / 1

研发人员的绩效考核

研发人员的绩效考核 作者:李子明 很多企业的绩效考核工作常常会面临这样的问题:相对其他部门,研发部门的考核指标提取、考核方式确定都有一定的难度。这也是人力资源专业人员和研发部门管理者困惑的难题。曾经有企业试图对研发人员实行完全的定量考核,甚至提出以编写软件代码的行数作为一个重要考核指标,结果员工开始将一个命令可以解决的问题,拆分为几个命令,于是“大家都很忙,疲于写程序,工作结果完全超过了预期目标,但是软件的功能却没有实现”,完全背离了绩效考核设计的初衷,考核不得不紧急叫停。虽然这种方式停止了,但如何公正客观地评价研发人员工作业绩的问题却依然摆在管理者面前。 研发人员考核难在哪里 研发人员考核的困难主要集中于以下几点: ■ 绩效指标提取困难,由于研发人员工作本身的独特性以及工作成果不易衡量,因此难以提炼直观量化的数字性指标; ■ 工作内容界定困难,特别是预研人员,一些成果仅仅是证明某种试验或测试方法可行与否,证实与证伪具有同样的价值,难以在任务下达之前予以明确; ■ 定性内容较多,影响考核的公正性; ■ 考核方式的选取问题,很多企业的研发管理者为了回避考核的难题,而采取背后打分、不沟通的方式。 面临如此多的问题,如何对研发人员进行业绩评价呢其实,考核中最为关键的是指标和评价方式,这两者是员工工作的向导和公司的价值取向,出不得偏差,否则就可能事倍功半,甚至劳而无功了。这里,我们也从这两点出发,分析研发人员的指标提炼和评价方式。 怎样提炼绩效指标 任何一项工作的展开必然是这样的思路:“正确的行为,沿着正确的道路,达成正确的结果”,提炼绩效指标也需要沿着这样的逻辑关系,从研发成果向前推出成功的路径以及正确的行为要求,具体见下图。 研发人员的考核指标可以界定为两个方面:一个是效益指标,一个是效率指标。效益指标是研发的成果在市场中产生的价值反映,如产品销售额、市场占有率等。效率指标则是指公司内部的研发效率和阶段成果完成情况,包括路径指标和行为指标,具体如产品开发周期、研发费用、产品规划符合度、批次整改率、单板/整机直通率、产品数据准确率等等。绩效指标提炼的过程实际上就是管理程序和工作流程的分析过程: 路径指标 路径指标是衡量研发过程是否符合总体研发规划的过程检测指标。 从研发的整体流程环节看,虽然研发的成果不同,但是他们所遵循的程序是一致的,明确每一环节的关键监控点,也就可以形成考核的路径指标。这些路径指标的达成保证了最终结果的实现。 产品开发周期、研发费用等指标比较易于理解,产品规划符合度指标虽然不多见,却非常重要,下面是某公司对此的界定(见表一)。

开发绩效考核方案

开发绩效考核方案

开发考核方案 1. 目的 为了提供工作效率,改变工作现状,并使项目奖金公正合理地分配到项目组成员手中,特制订本方案。 2. 适用范围 研发部全体成员。(参与开发项目的其它技术人员) 3.基本原则 以公司《工资及奖金发放管理办法》为基本依据,结合部门实际,力求公平,充分体现个人价值,兼顾团队。项目奖金定义采取积分制,每人将根据完成项目的多少和进度状况获得不同的积分。前期定义每分不少于***元,在发放奖金时,公司可根据业绩状况加以提高,不会降低。 4.项目奖金发放步骤 1)根据市场需求,业务部或客户下发《新产品开发申请表》。 2)研发部经理下发《产品设计任务书》,根据部门当时人员配置情况,确定项目负责人;若其它人员有异议,可经过 公开竞聘方式决出项目负责人和项目组成员。 3)项目负责人根据项目开展需要,并编制《产品设计进度计划》。 4)根据分工难度和工作量大小确定项目积分分配比例。 5)项目小组完成开发任务。 6)根据开发设计流程进行项目资料归档验收、确认。

7)记录积分(积分公开透明)。 8)年中或年底根据积分发放项目奖金。 5.项目积分分配比例的确定 5.1 项目积分总体分配比例 5.1.1部门积分:每个新项目的总积分的30%划为部分积分,部门积分在全部门平均分配。 5.1.2量产机种后期维护部门积分,根据年度订单数据,大项目积3分,中项目积2分,小项目积1分。 5.1.3机种维护工程师量产机种后期维护积分,大项目3分,中项目2分,小项目1分。机种维护工程师的积分分配方法 5.1.4新立案的开发项目积分的70%交于项目组分配,由项目组全体成员按工作难度和工作量大小确定的比例进行分配。 5.2 工作难度及工作量的确定 5.2.1项目评估 对项目难度进行评估,将项目分为大项目、中项目、小项目。 大项目:整机设计,包含结构、软件、电路全新设计; 中项目:部分设计,结构、软件、电路部分全新设计; 小项目:局部设计,其中一部分设计。 对项目时间的评估参考: 大项目:3-4个月以上; 中项目:1-3个月;

研发人员绩效考核制度

一、目的 为适应公司发展需要,规范公司技术研发人员的薪酬考核发放业务流程,建立和完善以岗位绩效为主要形式的收入分配体系,以调动员工的积极性和创造性,特制定本制度。 二、适用范围 本制度适用于技术研发中心所有在岗员工。 三、考核原则 1.考核内容和流程以公开、公平、公开为原则,以确保考核结果的公正性; 2.客观原则,强调以数字和事实为依据,对考核结果做出客观性评价; 3.业绩改善原则,绩效考核是一个管理手段而非最终目的,考核责任人将通过不断沟通帮助考核对象发现工作中存在的问题,找到改进的方向,从而使组织和员工达到更高的水平。 四、职责 1.技术研发中心各部门副经理级以上成员组成绩效管理小组,负责考核方案的审核、绩效沟通、受理考核争议投诉等; 2.行政管理部负责对考核结果的计算、统计并对考核汇总统计结果进行绩效工资核算。 五、薪酬模式 1.技术研发中心员工的薪酬由岗位工资、绩效工资、科研奖励三部分组成; 岗位工资:是员工个人收入中相对固定的部分,是依据员工岗位特点及岗位价值评估结果并结合员工个人历史情况确定的基本收入; 绩效工资:是指每月进行绩效考核评分,按绩效工资系数发放; 科研奖励:是指技术研发中心按照科研课题产生的社会效应和经济效应对参与科研人员的奖励; 2.技术研发中心应当在每月5日前确定当月绩效计划,提交电子版考评表至行政管理部备档; 3.行政管理部于每月8日将绩效考评表下发至各考核人,考核人应于每月30日将纸质版考评表完成并保密送至行政管理部(为保证考评的公正性及保密性,考评表应由部门绩效负责人/考核人直接送至行政管理部相关人员); 4.为确保对被考核人考核指标透明度及公平性,绩效考核评定指标确定后,被考核人应确认指标并签字; 5.月度绩效结束后,行政管理部将统一人员绩效考核结果汇总,提交至董事长审批,行政管理部负责对考评结果以短信形式公布; 6.非正式员工不纳入绩效考核范畴; 7.被考核人员工作未满一个考核周期,不论何种原因离职,均不计考核; 8.申诉:被考核人如对考评结果存在异议,在知道绩效评估结果三个工作日内提出申诉,填写《员工季度绩效申诉表》向部门经理或行政管理部提起申诉,受理申诉者必须在三个工作日内反馈处理过程与结果。 六、考核办法、考评内容及考评标准 1.考评内容:主要参照员工当月关键工作任务、岗位职责进行工作考评,即:KPI考核(关键绩效指标法)。以员工个人素质、工作态度、专业知识、工作能力、工作业绩(岗位

总监理工程师绩效考核表(修改)

总监理工程师目标设定与绩效考核表被考核人:考核月份:12月 权自评上级 考核指标完成标准扣分原因 重分评分 完成指标: A.当年应收账款完成率大于48%。 B.往年应收账款完成率为100%(注:一些重大特殊项 目由于市场原因或甲方原因不能付款的,总监理工程 师必须得到用户方的书面证明文件,由事业部经理确 认后交公司财务部备案,由总经理批准具体回款时限) 当月应收账款完成 1.当月100%完成指标不扣分。 25 指标 2.当月完成指标小于100%且完成指标大于等于80%, 扣5分。 3.当月完成指标小于80%且完成指标大于等于60%,扣 15分。 4.当月完成指标小于60%,扣25分。 注:如未完成出具公司认可的甲方证明,暂时不扣分。 1.监理资料不完整,检查不到位,每个项目每次扣5 分。如造成无法验收,甲方投诉每次扣25分。 2.监理资料签字不正确,跨职位签字,一次扣5分。 3.监理资料不及时,不准确,不合格。每次扣2分。

三次以上扣10分。 4.监理资料按时效性提交技术部电子版,缺失一次扣 工程监理资料指标 25 5分。 5.监理资料检查时,必须为原件资料,复印件无效,无原件资料,扣5分 6.所属监理人员监理资料检查、整理、存档不到位,造成监理资料缺失、遗失,每次扣5分,情节严重扣 25分。 1.所属监理项目监理人员安排不到位被建设单位投 诉,每次5分。 2.所属监理人员工作不认真,造成投诉,每次5分。 3、所属监理人员一个月内必须了解所监理项目的重点 人员管理指标 25 部分,部门进行抽查,不知道者,总监扣5分 3.所属监理工作造成后期市场无法开展,客户否定监理单位,一次扣25分。 1.重要工程项目总监调配不合理一次扣5分,安全生 产违规造成公司受损一次5分,情节严重扣25分。 2.隐蔽工程检查,验收,分项工程检查,验收,总验 收监理工程师不到场,项目验收资料缺失、遗失,一次扣5分。 项目实施,安全生产 25 3.每月提交安全生产报告一份,没提交者,扣2分 4.每周进行一次总监巡检,并做好记录,少一次扣2 1

测试人员绩效评价标准

测试人员绩效评价方法 版本记录: 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据,其它考核的标准参照支持服务中心的部门考核大纲,该标准仅作为整体考核标准中的综合考核的一部分。 2适用范围 本标准适用于软件测试人员的考核。 3 评价标准与原则 3.1提交BUG的数量和执行测试用例的数量

测试中发现的BUG数量: 1)同一个项目组内,提交bug数 2)每人日提交的bug数 3.2测试人员发现的问题的本身价值 1)Bug的严重程度是衡量bug的质量的一个重要因素,好的bug应该是极端严重的,对系统造成极大危害的。 2)Bug的双方面评判,对于bug的价值开发人员在另外一个角度上进行评判。 3.3、测试文档的质量 测试文档的质量往往是测试人员的测试水平的反映,只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告,说明测试的全面性和测试过程的质量 3.4 测试技能水平 1)测试用例设计水平 2)测试工具掌握使用水平 3)测试结果分析判断水平 3.5测试技能以外的综合能力 考察一个测试人员的责任心,如果一个测试人员工作不符责任,随意敷衍,即使提交的问题单数量多,也不能证明他测试的质量高。其次积极的工作态度是提高测试质量,和整体团队风气的关键,沟通能力直接影响测试的工作效率与不同部门间的合作分工。 1)工作态度 2)沟通能力 3)钻研能力 4)团队合作能力 4考核办法一览表

注:缺陷分类算法: A*(1+加权系统)/(A+B+C+D+E)*20 B*(1+加权系统)/(A+B+C+D+E)*20 C*(1+加权系统)/(A+B+C+D+E)*20 D*(1+加权系统)/(A+B+C+D+E)*20 E*(1+加权系统)/(A+B+C+D+E)*20

研发人员绩效考核与激励制度

研发人员绩效考核与激励制度 1、目的 提高研发质量和效率,考核研发人员和研发过程及结果,体现公平、公正和公开原则,调动研发人员的积极性与创造性,确保研发项目按计划进度和质量要求完成。 2、适用范围 本制度适用于本公司研发人员和研发项目的绩效考核和激励管理。 3、定义 3.1研发项目 研发项目按其内容分为四大类:新工艺、新产品、新材料、新标准。 3.2研发项目合同/项目任务书 指甲方(董事长或授权人)与乙方(项目研发组)就明确研发项目的任务、阶段、验收细则、奖惩办法等事项达成的书面协议。合同签订时须确定目标、时间、经费、奖金和项目负责人。 3.3项目奖金标的额 是指在项目立项时根据项目类别确定的某一项目的项目奖金额度。 3.4评审委员会 公司设评审委员会,由公司董事长或授权人、项目组长。负责公司各类奖项(包括其他非研发项目和奖项)的评定。 4、职责 4.1董事长(或授权代理人) 研发项目的立项审批,研发合同/协议的签订、批准,研发项目考核结论的确认和奖励的批准。 4.2公司分管副总 立项审核,资源配置,项目考核结论评估、项目奖励、申报资料等审核和调整,研发项目的考核及协调处理。 4.3项目负责人(项目组长) 全权负责项目的开发过程控制,是项目计划分解、研发质量、进度、创造性和成本控制的直接负责人。 4.4评审委员会 根据相关部门提供的项目计划、质量、费用等数据和资料等,负责组织对研发项目的考核,评估,奖励的评定。项目考评小组对考核结论负责,组长为项目考评的第一责任人。 5、过程控制及要求

5.1研发计划的日常检查、考核 5.1.1项目研发组主要检查项目月、季研发计划的执行情况、存在问题、须协调事项等,收集相关资料,检查各类研发计划的完成情况。 5.1.2项目研发组必须对月、季研发计划完成情况的真实性把关。如出现不实情况,将对考核负责人按500元/次·项处罚。 5.1.3研发人员的月度绩效考核按公司《月度绩效考核制度》执行。 5.2研发项目目标与进度考核 5.2.1目标考核 研发项目结果没有达到项目任务书内容与目标要求时,原则上应给予负激励。 5.2.2文件资料考核 项目研发过程中各种资料齐全完备。项目任务书(合同)、研发可行性报告、各阶段的评审资料、设计图纸(蓝图及电子图档)、工艺技术文件资料、试验检测报告等类资料,资料不完整的按500元-2000元/类,从该项目奖金中扣罚。对重要技术资料丢失或重要技术泄密的,将对直接责任人进行经济处罚,给公司造成严重后果或重大损失的将追究其刑事责任,并追究相关领导的连带责任。 5.2.3进度考核 5.2.3.1项目阶段进度延期,但不超过1个月(含),扣除该阶段奖励的50%,特殊情况项目组申请,经分管领导批准,可酌情少扣或不扣。 5.2.3.2项目阶段进度延期1个月至2个月(含),扣除该阶段奖励的100%,特殊情况项目组申请,经公司分管副总批准,可酌情少扣,但扣除额不得低于50%。 5.2.3.3项目阶段进度延期超过2个月,不管任何理由,应给予对应的负激励。 5.2.3.4项目阶段进度延期而项目最终验收不延期时,项目组申请后,公司分管副总可酌情补发已考核各阶段所扣除的部分奖励(但补发金额不得大于所扣除金额的80%)。 5.2.3.5公司领导对进度有特别要求的项目,没有按要求完成直接给予负激励。 5.2.3.6研发承包合同(任务书)对项目进度有特定的考核奖惩措施时,按承包合同执行。 5.3项目立项及项目类别评定方法 5.3.1立项原则 根据公司发展战略、规划和立项要求,按市场需求和预测、技术领先、技术经济效益 好和提高公司品牌和市场竞争力的原则选题立项。 5.3.2项目评审

软件测试工程师绩效评估表

软件测试工程师绩效评估表 一.软件测试工程师职责: 1 与软件产品部配合完成软件需求分析讨论,并根据需求说明书制定《项目测试(计划) 方案》;编写《测试用例》;建立测试环境; 2 负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改 软件的模块测试和系统测试;建立、推广并维护实施软件版本管理系统; 3 负责推广实施软件开发文档规范化工作,管理研发产品相关文档; 4 负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作,并提供测 试报告; 5 负责监督软件开发流程的执行,并负责提出软件开发过程改进建议,提高软件产品质 量。 6 与开发工程师和研发部门交流报告任务进展情况,并提出最近的测试需求; 7 测试部负责制订测试计划、测试用例和测试实施方案,项目主负责人安排测试与对应 的开发人员交流完成测试执行工作;及时提交准确、完整的《项目测试报告》; 8 项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配,需要与研发之 外的部门定期交流掌握下周或近期可能测试任务; 9外部接口都由测试部主管负责完成,与其他项目组和产品部门协调项目进度; 二.软件测试的不确定性: 1 软件测试的目的就是使软件的错误不断趋进于零,但软件的错误是永远找不完的; 2 开始测试时,可能软件使用1个小时就出现10个错误;测试修正后1个小时出现一 个错误,继续修正,继续测试,直到约一个月出现一个错误。这时这个出错几率已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部门来维护。 3 测试一些成熟的游戏或应用,测试过程中很难发现大量的缺陷;而测试一些不成熟 的游戏或应用,在测试前期,会出现大量的问题;这样就导致不同的工程师发现不同数量的bug; 4 软件测试的进度首先会按照测试计划逐步进行,但是在测试过程中,测试进度会随研 发部门的进度而调整;所以积极的与研发部门交流、协调测试中的问题是相当必要的。 三.测试工作最低成功标准及测试工程师考核内容: 测试工作的最终目标就是发现客户可能发现的所有错误。如果移植测试在使用第一天就发现了你没测试出来的错误,那测试是失败的。如果使用了很久(如几个月)才出现错误,那说明测试还是成功的。 测试工程师考核内容: 1 测试工程师比开发工程师更了解产品;(产品各模块总体把握能力) 2 测试工程师能从客户的角度来检测软件的功能;(用户身份) 3 测试工程师获取资料,使得编制的测试用例更切合测试的重点、难点以及关注点;

总、专业监理工程师绩效考核表

-- 专业监理工程师绩效考核表 项目:岗位:姓名:日期: 序 考核内容分值考核标准考核方法得分备注号 熟悉监理业清楚熟悉项目全过程的监理业务内容,明确 1 务、明确岗位 5 分本专业监理工程师职责。 A 、熟悉、明确得 5 询问 职责分; B、不全面得 3 分; C、不熟悉得 0 分 编制或执行监 2 5 分 理细则 熟悉设计图纸 及相关规范, 3 20分有解决问题能 力在总监领导下熟悉项目情况,清楚本专业监理的特 点和要求,能在实施前 1 个月编制切 实可行的监理细则或遵照执行。 A 、编制内容查阅细符合要求,并且执行效果好得 5 分; B、能编则、巡检 制但操作性不强,执行有效果得 3 分; C、不记录能编制,但 引用能遵照执行有效果得 2 分;D、无监理细则得 0 分 要求监理工程师熟悉设计图纸,掌握相关规范, 能提早发现设计和施工中存在的问题或 隐患,提出处理意见和措施报总监理工程 查阅监理师,并且跟踪督促落实,有书面通知和记 日志、监录。 A 、能及早发现问题,提出意见并得以妥 理通知和善解决得 20 分; B、实施中才发现问题,采 个人工作取措施得到解决得15 分; C、问题已造成损 日记失,事后采取措施补救得 5 分; D、不熟悉设计图 纸和规范,指挥有误,有直接责任得 0 分 本专业质量、 进度、投资、 4 20分安全、文明施 工的控制效果 本专业资料的 5收集整理完整 12 分性、及时性有各项事前、事中、事后的控制手段措施,查阅巡检得以有效实施,使工程处于受控状态。 A 、控记录;走制措施得当,实施有效得 20 分; B、有控制访业主;措施但不完善,控制效果好得15分; C、有是否有各控制措施,但实施效果一般,经常出现控制种投诉不利得 5 分; D、无控制措施,处于失控状况(口头或得 0 分书面) 熟悉本专业的资料体系,能及时正确地办理 各种签证;监理存档资料收集及时,齐全符 合公司规定。 A 、符合要求得12 分; B、存档 查阅巡检及时、不齐全,签证无误得 6 分; C、存档及 记录时、齐全,签证有错误得 3 分; D、存档不及 时、不齐全且有签证错误得 1 分; E、资料混 乱,严重不齐全得 0 分

软件开发工程师绩效考核

软件开发工程师绩效考核-标准化文件发布号:(9556-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

软件开发工程师绩效考核 1、工作完成及时性。按时间评判。10分。 A、杰出:经常提前完成安排的工作。 B、良好:按时完成。 C、正常:基本完成计划内工作,出现可控范围内延期。 D、需改进:经常性出现延期或者延期严重。 2、工作量饱和度即生产率(一般评估标准:代码量/完成的时间)。12分。 A、杰出:工作效率很高,提前完成上级要求,满意度很高。 B、良好:工作效率较高,达到上级的要求,满意度较高,未出现异常问题。 C、正常:工作效率不高,基本达到上级的基本要求,偶现小问题。 D、需改进:工作效率低,经常不能达到上级的要求,经常出现问题。 3、工作主观性(是否会主动推动工作的进行)。评判:每周主动推动且主动协助解决项目问题。5分。 A、杰出:主观能动性很强,时刻主动推动项目进展,不需要领导时刻敦促。 B、良好:主观能动性较强,推动项目进展,不需要领导时刻敦促。 C、正常:主观能动性一般,偶尔推动项目进展,领导需要敦促。 D、需改进:主观能动性较差,需要别人推动项目进展,领导需要时刻敦促。 4、文档质量(需求文档理解质量、测试用例质量、代码注释)。8分。 A、杰出:输出文档清晰、正确、规范,积极参与文档正规化建设,当天报告当天 填写。 B、良好:输出文档完整、正确、规范、满足公司文档要求,当天报告次日填写。

C、正常:输出文档完整、正确,当天报告周末填写。 D、需改进:输出文档不完整、不正确,当天报告拖延时间较长填写。 5、临时任务。5分。 A、杰出:乐意接受突发任务并高效及时完成。 B、良好:接受突发任务并及时完成。 C、正常:不忙时可接受突发任务并及时完成。 D、需改进:不接受突发任务。 6、工作完成质量。研发完成测试后验收时校验(总工期为计划开发时间、测试版本修改bug时间不包含测试时间)。20分 A、杰出:无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug时 间超过总工期10%以内。 B、良好:无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug时 间超过总工期15%以内。 C、正常:无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug时 间超过总工期20%以内。 D、需改进:无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug 时间超过总工期25%以内。 E、不合格:总工期5%以上工作量遗漏或造成总工期5%以上工作量逻辑修改或无 法测试耽误总工期5%以上或者修改bug时间超过总工期25%以上。(项目结束时使用) 7、千行代码率。10分。 A、杰出;

研发测试人员绩效考核奖励细则

研发人员绩效考核奖励细则 一、考核目的 为了更好完善公司各项目管理机制,保障研发项目的按期、高效、高质完成,同时进一步促进研发部门员工自身的发展,结合研发人员的工作特点,特制定本方案。 二、适用范围 公司研发所有员工,具体包括智能硬件产品组、电商组、APP组、大数据组转正员工。(当月 15 日(含当天)前转正本月考核,15 日后转正的次月考核) 三、考核周期:月度考核 四、考核方法与原则 考核方法 采用部门考核的方法(以产品为单位,产品负责人对其下属员工的进度、质量、规范性、工作态度及能力等方面进行评估); 考核原则 采用行为考核与结果考核相结合。 五、考核内容与评分标准(详见附件一文件《研发人员绩效考核表》) 六、考核实施 计划沟通阶段 计划实施阶段

考核阶段 考核者根据被考核者在考核期内的工作表现和考核标准,对被考核者评分,同时被考核者也需根据个人在考核期内的工作表现和考核标准进行自评。 考核者的直接上级及主管领导对考核结果进行审核,并负责处理考核评估过程中所发生的争议。 各部门每月 10 日前组织绩效面谈会议,将上月考核结果反馈给被考核者,并讨论绩效改进的方式和途径。 七、绩效工资与考核结果运用 绩效工资运用 绩效考核结果运用 绩效面谈 考核者每月5日前对被考核者上月度的工作绩效进行总结,填写附件二《绩 效考核面谈表》,并指出被考评者有待改进的地方,从而进行差距分析,确保绩效的持续改进,同时共同制定下月的绩效目标。

相关奖励 1)根据年度 12 个月的平均得分,作为员工薪资调整、职位晋升、岗位培训的决策依据。 2)连续3个月,研发人员的进度考核为满分的,当月在绩效得分中奖励加分 5 分,连续3个月,研发人员的代码质量考核为满分的,当月在绩效得分中奖励奖励 10分。 3)培训:年度绩效考核得分在 85 分(含)以上的员工,有资格享有公司安排的提升培训,年度绩效考核得分在 70 分以下的员工,可以申请相关培训,经人力行政部批准后参加。 相关处罚 1)首次月度考核得分在 59 分(含)以下的,由直属领导进行绩效面谈,对其绩效成绩进行差距分析及进行相应的培训辅导; 2)通过部门培训仍连续 2 个月绩效考核得分在 59 分(含)以下的,公司根据员工实际业绩产出给予相应的调整(降职/降薪/解除劳动合同) 员工的绩效工资发放

软件测试人员绩效考核详细

1、测试团队绩效考核 绩效评估的的客体:是个体成员还是整个团队。 ●Pascerellayer认为,团队绩效评价应以成员个人完成工作的状况为基本依据,理由是激励只能作用于个人而不是群体;技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效,个体的努力得不到充分的肯定,就容易造成社会懒散现象,即个体由于参加团队工作,其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来,不仅会影响组织绩效,还会毒害组织文化。同时,由于绩效考核与薪酬及个人价值的实现相联系,因此,在团队中,能力高的成员倾向于对个人绩效的考核,从而得到更高的认可和报酬。 ●Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效,因为团队的成功很大程度上依赖于团队成员间的团结合作,理解支持,若评估集中于个体层面,会导致个人主义盛行,忽视团队的协作精神,阻碍信息、技能的共享和绩效的提高,降低团队工作的优势。 ●因此在实际操作中,企业往往采取一种折中的方法,即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看,还没有一种很好的办法可以科学地确定这个比例。但是,如果从团队性质的差异、团队所处的阶段等方面来考虑,那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容:结果、行为还是能力。对于绩效内涵存在着三种不同的观点,即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效

定义为“在特定的时间内,由特定的工作职能活动产生的产出记录,工作绩效的总和相当于关键和必要工作职能中等绩效的总和(或平均值)”,这是“绩效是结果”的典型观点。Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来,以能力作为绩效的观点得到了广泛的使用,这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展,绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。?虽然这三种观点相互区别,且都是在否定前者的基础之上产生的,但是,如果不带入特定的环境,特定的组织,及组织发展的特定时期,那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰,基于结果的绩效考核是最容易实施,也最有效;相反,如果目标模糊,无法准确衡量其结果,这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发,最具有激励效果和长期效应,最有利于组织不断发展,但在实际操作中却很难达到效果。因为能力是无形的,它依附于个体,既受主观因素的控制,也受各方面客观因素的影响,很难用标准化的方法衡量个体的能力,即使是方法对组织期望成员所具有的能力和特质作出了解释,但这些解释仍是描述性模糊语言,在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制,由于行为必然是建立在某种能力基础之上的,并且行为比能力更具有外显性和可测性,因此一定程度上,该方法兼顾了组织目标和个人能力。但是,绩效考核中容易出现目标置换的现象,一味对行为测评会导致成员将行为作为目标,进而影响实际目标的实现。因此,无论哪种考核方式,都有其适用的条件和要求,不存在一种绝对好的方法。

软件测试人员绩效考核详细

1 、测试团队绩效考核 绩效评估的的客体:是个体成员还是整个团队。 ●Pascerellayer 认为,团队绩效评价应以成员个人完成工作的状况为基本依据,理由是激励只能作用于个人而不是群体;技能的提高和行为的改进最终必须落实到个人。若仅考 核团队绩效,个体的努力得不到充分的肯定,就容易造成社会懒散现象,即个体由于参加 团队工作,其工作效率比自己单独工作时的效率 反而大大降低。此现象一旦在组织中蔓延开来,不仅会影响组织绩效,还会毒害 组织文化。同时,由于绩效考核与薪酬及个人价值的实现相联系,因此,在团队 中,能力高的成员倾向于对个人绩效的考核,从而得到更高的认可和报酬。 ●Zingheim 和 Schuster 则认为对个人的考评应考虑团队的整体绩效,因为团队的成功很大程度上依赖于团队成员间的团结合作,理解支持,若评估集中于个体层面,会导致个人 主义盛行,忽视团队的协作精神,阻碍信息、技能的共享和绩效的提高,降低团队工作的优势。 ●因此在实际操作中,企业往往采取一种折中的方法,即按一定比例兼顾 团队和个人两个层面的绩效考核。从目前的研究来看,还没有一种很好的办法可以科学地确 定这个比例。但是,如果从团队性质的差异、团队所处的阶段等方面来考虑,那么至少可以 确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容:结果、行为还是能力。对于绩效内涵存在着三种不同的观点,即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效

定义为“在特定的时间内,由特定的工作职能活动产生的产出记录,工作绩效的 总和相当于关键和必要工作职能中等绩效的总和(或平均值)”,这是“绩效是 结果”的典型观点。Murphy 等人将绩效定义为“一套与组织或个体所工作的 组织单位的目标相关的行为”。近年来,以能力作为绩效的观点得到了广泛的使用,这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着 这三种观点的诞生和发展,绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。?虽然这三种观点相互区别,且都是在否定前者的基础 之上产生的,但是,如果不带入特定的环境,特定的组织,及组织发展的特定时期,那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰,基于结果的绩效考核是最容易实施,也最有效;相反,如果目标模糊,无法准确衡量其 结果,这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度 出发,最具有激励效果和长期效应,最有利于组织不断发展,但在实际操作中却 很难达到效果。因为能力是无形的,它依附于个体,既受主观因素的控制,也受 各方面客观因素的影响,很难用标准化的方法衡量个体的能力,即使是方法对组织期望成员所具有的能力和特质作出了解释,但这些解释仍是描述性模糊语言, 在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核 员工为实现既定的结果所必须做出的行为来实现对结果的控制,由于行为必然是建立在某种能力基础之上的,并且行为比能力更具有外显性和可测性,因此一定程度上,该方法兼顾了组织目标和个人能力。但是,绩效考核中容易出现目标置 换的现象,一味对行为测评会导致成员将行为作为目标,进而影响实际目标的实现。因此,无论哪种考核方式,都有其适用的条件和要求,不存在一种绝对好的 方法。

关于测试人员绩效考核的一点儿想法

每一个测试经理都面临这样的问题,如何对测试人员进行绩效考核。因为测试人员参与的工作不单一,需要的技能也各种各样,考核测试人员的绩效似乎不是很容易的事,除了一般需要考核的对工作的态度,工作的责任心,积极性这些方面以外,还有一些其它方面的内容。 要想对测试人员进行考核,就需要开始工作的时侯明确测试人员的职责,对测试人员的期望等,一个团队中不同的测试人员可能职责不同,比如测试负责人,测试设计人员,自动化测试人员,普通测试人员等,那么对这些人的期望也是不同的,进行绩效考核的时候需要根据对测试人员的期望进行考核,而这些职责和期望测试人员也是很明确的。 测试人员可能参与不同的软件开发过程,比如需要参与需求和设计的评审,那么也需要对这些工作进行考核,比如需求评审时可以从测试人员对需求的理解上,测试人员对需求提出的问题的质量上等作出评价。 如果需要测试人员准备测试文档,如测试用例等,那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量,对需求的覆盖程度,可理解和执行等方面来判段一个测试人员的能力。 对于执行测试的测试人员来说,可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的,是隐藏比较深的,还是一些表面的问题。还可以从问题的书写上进行评价,问题的书写是否详细清晰,开发人员可以再现,还是含糊其词,不明所以。或者测试人员书写的问题是否是自己的操作问题,一个问题是否写多遍等。 而对于已经发布的产品,也可以从用户反馈的问题来考核测试人员的绩效,但是这个可能需要的时间比较长。 测试人员的沟通能力也是考核的一个方面,无论是书面的还是口头的,测试人员都应该有较好的沟通能力。 另外测试人员的接受指示,把握细节的能力也应该进行考核,测试经理希望把任务分配给可以按照指示完成的人来完成,如果测试人员自行其事,即使技术能力比较强也对工作无益。 首先我们不能单纯的以测试人员提交的bug数量进行考核,那样的结果可能会导致测试人员为了bug 数量而互相攀比,导致bug质量的下降。 所以我觉得下面这几点可能会更合理一些(仅供讨论): 1:有效bug率用来衡量测试人员发现的,被确认为缺陷的有效缺陷比率,比率越高则测试质量越高。这个比率剔除被开发人员拒绝修改和删除,以及重复的bug之后,剩余缺陷数占缺陷总数的一个比率。 测试人员不能只重视bug的数量,为了让领导感觉测试人员每天都在工作而随意的提交bug,从而导致bug数量很高,但质量很低。造成很多bug都被拒绝修复或者bug不能重现以及bug重复报告等问题。 2:测试覆盖率主要用来衡量测试人员对功能点遗漏测试的情况。我觉得这适合测试组人员较少的公司,每个测试人员要单独负责一个完整的项目,在这种情况下,进行这样的衡量是有必要的。 3:bug描述质量主要衡量测试人员对于bug报告的描述情况。bug报告的描述是否清晰、简洁。开发人员是否能很容易的理解并依据报告描述重现bug。很多情况下开发人员拒绝修改bug是因为bug报告的描述很难理解,并且依据描述不能重现bug等。 4:严重bug率主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷。这有助于让测试人员将注意力集中在关键问题上,减少产品的致命缺陷。 5:市场反馈缺陷率产品正是发布推向市场后,客户在使用产品的过程中发现的缺陷数占缺陷总数的比率。用来总体衡量测试组整体的工作情况。 6:最后一点,让开发人员来评估测试人员的表现。我不太肯定这样做的效果会怎么样?我的想法是:测试最直接的服务对象是开发。开发人员对于测试人员所报告的缺陷进行确认,修改(或者拒绝),对于测试人员的工作表现以及缺陷质量来说,开发人员是最有发言权的。当一个质量很高的bug被报告的开发人员那里,他们是很乐意接受这样的问题,因为你报告的bug有足够充分的理由和足够准确的描述可以说明问题,让开发人员没有借口来为自己辩解。开发人员对于这样的问题会有很好的印象。所以我觉得让开发人员来评估测试人员的表现可以作为考核测试人员的一个重要依据。

软件开发工程师绩效考核

软件开发工程师绩效考核 1、工作完成及时性。按时间评判。10分。 A、杰出:经常提前完成安排的工作。 B、良好:按时完成。 C、正常:基本完成计划内工作,出现可控范围内延期。 D、需改进:经常性出现延期或者延期严重。 2、工作量饱和度即生产率(一般评估标准:代码量/完成的时间)。12分。 A、杰出:工作效率很高,提前完成上级要求,满意度很高。 B、良好:工作效率较高,达到上级的要求,满意度较高,未出现异常问题。 C、正常:工作效率不高,基本达到上级的基本要求,偶现小问题。 D、需改进:工作效率低,经常不能达到上级的要求,经常出现问题。 3、工作主观性(是否会主动推动工作的进行)。评判:每周主动推动且主动协助解决项目问题。5分。 A、杰出:主观能动性很强,时刻主动推动项目进展,不需要领导时刻敦促。 B、良好:主观能动性较强,推动项目进展,不需要领导时刻敦促。 C、正常:主观能动性一般,偶尔推动项目进展,领导需要敦促。 D、需改进:主观能动性较差,需要别人推动项目进展,领导需要时刻敦促。 4、文档质量(需求文档理解质量、测试用例质量、代码注释)。8分。 A、杰出:输出文档清晰、正确、规范,积极参与文档正规化建设,当天报告当天填 写。 B、良好:输出文档完整、正确、规范、满足公司文档要求,当天报告次日填写。 C、正常:输出文档完整、正确,当天报告周末填写。 D、需改进:输出文档不完整、不正确,当天报告拖延时间较长填写。 5、临时任务。5分。 A、杰出:乐意接受突发任务并高效及时完成。 B、良好:接受突发任务并及时完成。 C、正常:不忙时可接受突发任务并及时完成。 D、需改进:不接受突发任务。 6、工作完成质量。研发完成测试后验收时校验(总工期为计划开发时间、测试版本修改bug 时间不包含测试时间)。20分

研发人员绩效考核指标

研发人员绩效考核指标公司内部档案编码:[OPPTR-OPPT28-OPPTL98-OPPNN08]

研发人员绩效考核指标标准的提炼与确定 关键词:研发人员+绩效考核指标 1.研发人员绩效考核指标制定存在的问题及对策 2.怎么制定研发人员绩效考核指标 3.研发人员绩效考核指标怎么设计 4.研发人员绩效考核指标提取方法 5.【研发人员绩效考核指标】研发人员绩效考核指标制定——华恒智信 咨询 文章描述:研发人员作为企业核心部门的成员,在企业发展中起着十分关键的作用。而由于研发人员及其工作的特殊性,企业现有的研发人员绩效考核指标的制定存在诸多问题,影响了研发人员的工作积极性,对研发人员绩效考核指标的设计也成了企业绩效管理的重点和难点。那么研发人员绩效考核指标的制定出现了什么问题,我们又应该如何科学合理的提取研发人员的绩效考核指标呢本文由人力资源专家——华恒智信分析员结合咨询行业的实战经验总结了研发人员绩效考核指标的制定问题,以期大家有所借鉴。 引言: 随着市场需求的不断变化,企业不能再靠做一个产品来获取高额利润,而应把发展重心转到研发。研发人员作为企业核心部门的成员,在企业发展中起着十分关键的作用。而由于研发人员及其工作的特殊性,企业现有的研发人员绩效考核指标的制定存在诸多问题,影响了研发人

员的工作积极性,对研发人员绩效考核指标的设计也成了企业绩效管理的重点和难点。那么研发人员绩效考核指标的制定出现了什么问题,我们又应该如何科学合理的提取研发人员的绩效考核指标呢本文由人力资源专家——华恒智信分析员结合咨询行业的实战经验总结了研发人员绩效考核指标的制定问题,以期大家有所借鉴。 绩效管理是一种对公司的资源进行规划、组织和使用,以达到某个目标并实现顾客期望的过程。企业满足客户的过程一般是通过了解客户需求的前提下,设计研发出符合客户期望和需求的产品或者是提供客户所希望的服务的过程,那么针对提供产品的企业来说,其研发人员就是决定其产品是否具有市场前景和吸引力的核心所在,对其进行有效的约束和激励有助于企业产品与时俱进的更新换代,能够随时满足客户的需求并且提升组织绩效。 诚然,目前企业对研发人员的绩效指标的制定普遍存在一些问题: 1、绩效指标提取困难,由于研发人员工作本身的独特性以及工作成果不宜用时间/产出来衡量,因此难以提炼直观量化的数字性指标; 2、工作内容界定困难,因此导致绩效指标无法清晰确定,一些成果仅仅是证明某种试验或测试方法是否可行,难以在任务下达之前予以明确; 3、定性的考核内容较多,不利于绩效考核的公正性; 综合以上问题的出现,导致其绩效考核过程无法有效的进行,与绩效考核挂钩的薪酬管理、培训开发等随之出现问题,例如:薪酬浮动比

绩效考核表ios开发工程师

考核评分表(月度) 考核期间:年月姓名岗位 任务绩效序 号 考核项目 权 重 指标要求评分等级 得分 自 评 上 级 结 果1 程序设计与开发 1.新功能设计开发: 对新项目或新功能 分析、设计、开发 2.能够根据开发要 求独立完成设计开 发,平均每周工作完 成量100%《=X《=120% 3.对新功能分析、设 计、开发内容偶有偏 差,需要进行细节调 整,平均每周工作量 X<100% 4功能升级及完善: 针对已有功能结合 实际需要从易用性, 安全性,稳定性,高 效性,人性化等方面 进行升级与完善处 理。 7 5-7 1-4 6 2 开发成果提交合 格率 1能实时的对功能进 行全面分析,开发成 果提交合格率100% 2能对功能升级及完 善做简单的分析,开 发成果提交合格率 为95% 3.很难对功能的稳 定性及高效性做把 握,开发成果提交合 格率为90%以下。 10-13 6-9 1-5

3 软件调试与维护1软件安装调试维护 2及时对软件进行调 试及维护,做到高效 性、人性化 3需要督促才能完成 设备的维护 4.数据维护备份 5.及时删除冗余及 错误、虚假数据、定 期、不定期进行数据 备份 6对错误数据的处理 及数据备份有延迟 6 4-6 1-3 7 5-7 1-4 4 代码质量1.BUG处理:及时处 理BUG 2严格遵守代码规 范,平均每一千行 BUG数3个以内 3较好的遵守代码规 范,平均每一千行 BUG数在3至7个 4平均每一千行BUG 数在8至10个 13 10-13 6-9 1-5 5 开发中承担职责 的多寡及轻重 1工作内容多,难度 较大 2工作内容多,难度 一般 3工作内容适中,难 度较大 4工作内容适中,难 度一般 5工作内容少,难度 低 7-8 5-6 3-4 3-4 1-2 6 7 8 加权合计 行为考核序 号 行为指标 权 重 指标说明考核评分 自 评 上 级 结 果1 沟通 1总是能快捷有效的明确意图和需求 2可以通过有效沟通了解开发意图 3需要多次沟通和说明才能了解意图 4经常误解开发理念并缺少主动沟通 8-10 5-7 3-4 1-2

(研发管理)亲身体验怎样对研发人员进行绩效考核

怎样对研发人员进行绩效考核 随着市场竞争的日趋激烈,公司对研发活动越来越重视。对研发人员实施科学、合理、公正的考核,已成为绩效考核工作的一个重点。但是由于研发人员的工作与一般的生产工人、操作人员相比具有复杂性、创造性,因而在考核实施上存在一定的难度,使得对研发人员的绩效评估、考核成为当时困扰我们人力资源部的一大难题。如何解决这一难题,我们当时对此进行初步探讨,找到了比较理想的解决方案。 一、研发人员绩效考核的原则 研发人员是企业技术创新的主体,他们的工作成果直接影响着企业的效益和竞争力。对于研发人员的绩效考核应遵循以下原则:结果考核与行为考核相结合,以结果考核为主 对于研发人员来说,在考核中如果过于强调对行为的考核,会带来一系列的错误导向。因为如果过于强调行为,员工会更关心做事的方式,而不是做事的结果。在现实中,我们经常碰到这样的情况:一个不准时开会、从不加班加点、不注意搞好人际关系的研发人员却能够为企业设计新的工艺,为企业节省巨额资金、取得数项专利、在很有声望的杂志上发表论文、被特邀做学术报告等;另一个研发人员与他相反,行为上循规蹈矩,完全符合考核的要求,但没有什么实际的贡献。假如过于重视行为评价,后者的得分会高于前者,你觉得合

理吗?当然,行为指标也是需要考虑的考核指标,但对于研发的整体业绩来说就不那么重要了。 (二)外评与内评相结合,以外评为主 内部评价,包括进度、预算等评估是必要的,但过分强调内部评价是很危险的,因为内评很可能不太关心研发对企业的实际价值。内部评价作为企业内部的质量控制工具是很重要的。但是,评价的目的应该强调外评。外评非常重要,作用比较大,比如说用新工艺设计带来的收益来衡量研发的效果。 (三)价值评估与产出评估相结合,以价值评估为主 只对研发产出进行评估是不够的,必须对研发为企业带来的价值进行评估,即研发效果的评价。赢利性是企业的本质特征,企业不会容许研发经理只用如下指标进行考核:拟订了多少研究方案、发表了多少论文、做了多少设计、设计出了多少产品、做了多少次展示、获得了多少专利、完成了多少项目……研发的效果更重要地体现在新产品的开发、成本降低、销售量上升、产品改进、市场占有率等方面。 (四)评价系统要尽量客观 在评价研发业绩时,数量是非常客观的指标,但是,质量和成本数据往往是十分主观的。尽管不可能用十分客观的方式测评质量,但在设计评价过程时可以尽量减少主观性。一个比较简单的方法

相关文档
最新文档