3-高级售前工程师绩效考核表
售前工程师绩效考核表（高级）
研发人员的绩效考核
研发人员的绩效考核 作者：李子明 很多企业的绩效考核工作常常会面临这样的问题：相对其他部门，研发部门的考核指标提取、考核方式确定都有一定的难度。这也是人力资源专业人员和研发部门管理者困惑的难题。曾经有企业试图对研发人员实行完全的定量考核，甚至提出以编写软件代码的行数作为一个重要考核指标，结果员工开始将一个命令可以解决的问题，拆分为几个命令，于是“大家都很忙，疲于写程序，工作结果完全超过了预期目标，但是软件的功能却没有实现”，完全背离了绩效考核设计的初衷，考核不得不紧急叫停。虽然这种方式停止了，但如何公正客观地评价研发人员工作业绩的问题却依然摆在管理者面前。 研发人员考核难在哪里 研发人员考核的困难主要集中于以下几点： ■ 绩效指标提取困难，由于研发人员工作本身的独特性以及工作成果不易衡量，因此难以提炼直观量化的数字性指标； ■ 工作内容界定困难，特别是预研人员，一些成果仅仅是证明某种试验或测试方法可行与否，证实与证伪具有同样的价值，难以在任务下达之前予以明确； ■ 定性内容较多，影响考核的公正性； ■ 考核方式的选取问题，很多企业的研发管理者为了回避考核的难题，而采取背后打分、不沟通的方式。 面临如此多的问题，如何对研发人员进行业绩评价呢其实，考核中最为关键的是指标和评价方式，这两者是员工工作的向导和公司的价值取向，出不得偏差，否则就可能事倍功半，甚至劳而无功了。这里，我们也从这两点出发，分析研发人员的指标提炼和评价方式。 怎样提炼绩效指标 任何一项工作的展开必然是这样的思路：“正确的行为，沿着正确的道路，达成正确的结果”，提炼绩效指标也需要沿着这样的逻辑关系，从研发成果向前推出成功的路径以及正确的行为要求，具体见下图。 研发人员的考核指标可以界定为两个方面：一个是效益指标，一个是效率指标。效益指标是研发的成果在市场中产生的价值反映，如产品销售额、市场占有率等。效率指标则是指公司内部的研发效率和阶段成果完成情况，包括路径指标和行为指标，具体如产品开发周期、研发费用、产品规划符合度、批次整改率、单板/整机直通率、产品数据准确率等等。绩效指标提炼的过程实际上就是管理程序和工作流程的分析过程： 路径指标 路径指标是衡量研发过程是否符合总体研发规划的过程检测指标。 从研发的整体流程环节看，虽然研发的成果不同，但是他们所遵循的程序是一致的，明确每一环节的关键监控点，也就可以形成考核的路径指标。这些路径指标的达成保证了最终结果的实现。 产品开发周期、研发费用等指标比较易于理解，产品规划符合度指标虽然不多见，却非常重要，下面是某公司对此的界定（见表一）。
测试人员绩效考核详细
绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易 造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在 组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ?Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的 共享和绩效的提高，降低团队工作的优势。 ?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方 面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。 Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。 基于项目团队生命周期的绩效考核: ?孵化诞生期: 这是指团队形成前到团队正式形成的一个阶段，是选择合适的项目成员组成团队的时期。 ?考核的客体是个人。团队的首要任务是筛选项目组成员，根据项目目标的要求，选择最为合适的人选组成团 队，所以考核的对象是个人。 ?考核的重点是能力。从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因 此对成员的知识技能要求较高，需要成员具有较高的技术水平和知识储备以及不断学习和创新的能力。同时， 成立项目团队，意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持， 所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成员工作任务的认识、口头交流、个人成 长、问题解决、责任承担、领导技能等等。因此，在选择项目团队成员的时候，通过对被选者专业技能、基 本素质当然也包括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。 ?成长期:这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开始通过个人努力和彼此的合作共同在所研究
总监理工程师绩效考核表(修改)
总监理工程师目标设定与绩效考核表被考核人：考核月份：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 负责推广实施软件开发文档规范化工作，管理研发产品相关文档； 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 分
研发测试人员绩效考核奖励细则
研发人员绩效考核奖励细则 一、考核目的 为了更好完善公司各项目管理机制，保障研发项目的按期、高效、高质完成，同时进一步促进研发部门员工自身的发展，结合研发人员的工作特点，特制定本方案。 二、适用范围 公司研发所有员工，具体包括智能硬件产品组、电商组、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分 A、杰出：无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug时 间超过总工期10%以内。 B、良好：无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug时 间超过总工期15%以内。 C、正常：无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug时 间超过总工期20%以内。 D、需改进：无工作量遗漏且无逻辑遗漏且按时交付测试版本且测试版本修改bug 时间超过总工期25%以内。 E、不合格：总工期5%以上工作量遗漏或造成总工期5%以上工作量逻辑修改或无法 测试耽误总工期5%以上或者修改bug时间超过总工期25%以上。(项目结束时使 用)? 7、千行代码率。10分。 A、杰出;?代码非常清晰，逻辑性很强，运行很流畅? B、良好;??代码比较清晰，逻辑性中等，运行流畅
研发人员绩效考核指标
研发人员绩效考核指标公司内部档案编码：[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
总、专业监理工程师绩效考核表
总、专业监理工程师绩效考核表
专业监理工程师绩效考核表 项目：岗位：姓名： 日期： 序 号 考核内容分值考核标准考核方法得分备注 1 熟悉监理业 务、明确岗位 职责 5分 清楚熟悉项目全过程的监理业务内容，明确本 专业监理工程师职责。A、熟悉、明确得5分； B、不全面得3分； C、不熟悉得0分 询问 2 编制或执行监 理细则 5分 在总监领导下熟悉项目情况，清楚本专业监理 的特点和要求，能在实施前1个月编制切实可 行的监理细则或遵照执行。A、编制内容符合 要求，并且执行效果好得5分；B、能编制但 操作性不强，执行有效果得3分；C、不能编 制，但引用能遵照执行有效果得2分；D、无 监理细则得0分 查阅细 则、巡检 记录 3 熟悉设计图纸 及相关规范， 有解决问题能 力 20分 要求监理工程师熟悉设计图纸，掌握相关规 范，能提早发现设计和施工中存在的问题或隐 患，提出处理意见和措施报总监理工程师，并 且跟踪督促落实，有书面通知和记录。A、能 及早发现问题，提出意见并得以妥善解决得20 分；B、实施中才发现问题，采取措施得到解 决得15分；C、问题已造成损失，事后采取措 施补救得5分；D、不熟悉设计图纸和规范， 指挥有误，有直接责任得0分 查阅监理 日志、监 理通知和 个人工作 日记 4 本专业质量、 进度、投资、 安全、文明施 工的控制效果 20分 有各项事前、事中、事后的控制手段措施，得 以有效实施，使工程处于受控状态。A、控制 措施得当，实施有效得20分；B、有控制措施 但不完善，控制效果好得15分；C、有控制措 施，但实施效果一般，经常出现控制不利得5 分；D、无控制措施，处于失控状况得0分 查阅巡检 记录；走 访业主； 是否有各 种投诉 （口头或 书面） 5 本专业资料的 收集整理完整 性、及时性 12分 熟悉本专业的资料体系，能及时正确地办理各 种签证；监理存档资料收集及时，齐全符合公 司规定。A、符合要求得12分；B、存档及时、 不齐全，签证无误得6分；C、存档及时、齐 全，签证有错误得3分；D、存档不及时、不 齐全且有签证错误得1分；E、资料混乱，严 重不齐全得0分 查阅巡检 记录
技术开发人员绩效考核表.docx
2018年月绩效考核表 被考核人部门技术开发部职位考评得分 自 分管 直接 考核项目考核指标权重考评标准 上级 评领导 各功能模块的开发/ 10未按时完成各项任务，扣 2 分 / 周 修改 / 升级实施进度 因开发的模块影响程序运行速度或造成其它不可预见性问题，扣 模块开发质量10 2 分 / 次 程序运行稳定性10程序出现不能正常运行的情况，扣 2 分 / 次 KPI（60%） 程序运行问题处理8未及时处理程序运行问题，扣 2 分 / 次 Bug处理及时性8程序运行中出现的遗漏未及时修正扣 2 分 / 次 程序编写合格采纳率8因程序问题未通过审核，扣 1 分 / 次 领导安排的临时事项6未按时保质保量完成每项工作扣 2 分 / 次，不服从安排扣 4 分 / 次 加权合计 对本岗位专业知识掌握很好得满分，良好得 4 分，较好得 3 分， 专业知识5 一般得 2 分，合格得 1 分，较差得 0 分 完全胜任本职工作得满分，较好胜任得 4 分，可以胜任得 3 分， 工作技能5 基本胜任得 2 分，合格得 1 分，难以胜任得 0 分 工作能力 （ 20%） 工作有很强的计划性得满分，良好得 4 分，较好得 3 分，一般得 计划能力5 2 分，合格得 1 分，较差得0 分 能很好地协调与他人的关系得满分，良好得 4 分，较好得 3 分， 沟通协调能力5 一般得 2 分，合格得 1 分，较差得 0 分
加权合计 严格遵守考勤和各项制度，全勤和无违纪现象得满分，如有迟到、 考勤纪律4早退、漏打卡、漏日报、周报、月报、病假、事假和其它违纪现 象等，每项扣 1 分 / 次，旷工一次扣完 主观能动性和结果导自发积极主动完成领导安排和分内工作，如每发现不能按时完成 4 向工作，扣 2 分 / 次 工作态度 积极配合团队工作和公司活动得满分，不够积极配合工作，扣2 （ 20%）团队协作能力4 分 / 次；如给团队工作造成严重影响，损害公司利益，一次扣完 对工作很认真负责细心、不敷衍了事得 4 分，较好得 3 分，一般 责任心4得 2 分，合格得 1 分，很差得 0 分；不能对自己的过失承担责任， 逃避责任扣 2 分 / 次，泄露商业信息一次扣完 积极心态4心态积极，无乐捐行为得满分，有1次乐捐（或未执行）扣 1 分加权合计 加权总计加权总计 =KPI 考评得分 +工作态度考评得分+工作能力考评得分 考核得分总计由综合部计算 考核结果被考核人直接上级分管领导确认签字签字签字 综合部 调整原因调整分 考核调整 最终考评得分分考评等级级
测试文档 测试人员激励方案
测试人员绩效评价标准及激励方案 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据，其它考核的标准参照研发管理中心考核目标，该标准仅作为整体考核标准中的综合考核的一部分,对于参与PDT团队的测试成员，其PDT经理考核的绩效也是测试人员绩效的一部分。 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)*25 B*(1+加权系统)/(A+B+C+D)*25 C*(1+加权系统)/(A+B+C+D)*25 D*(1+加权系统)/(A+B+C+D)*25 5 测试激励与奖惩制度 1、表扬和奖励 表扬和奖励仍然是激励测试人员最主要的一种形式甚至采用积极的方式去帮助测试人员改正缺点，而不用批评或责备方式。表扬的形式多种，每个奖项均可得到通报表扬和（现金和等价值券）荣誉奖券（从部门经费中抽取）。对于连续三个季度获得通报表扬的员工,本年度考核为A,其他季度奖项为： · 发现bug最多的人员被授予"BUG王"。 · 最具价值的bug(MVB)。 · 优秀测试计划。 · 最有价值测试用例或者测试点。 · 季度优秀员工。 · 季度优秀新员工。