软件研发人员考核的基本原则.docx

软件研发人员考核的基本原则.docx

《软件研发人员考核的基本原则.docx》由会员分享，可在线阅读，更多相关《软件研发人员考核的基本原则.docx（8页珍藏版）》请在冰豆网上搜索。

软件研发人员考核的基本原则

软件研发人员的考核一直是软件企业管理的难点，总结了进行软件研发人员考核的一些基本原则，整理出来与大家共享：

Ø 要体现公司的价值观 

公司的价值观体现了公司认可什么类型的人员？

要挽留哪些人？

提倡做什么？

对这些人员的认可可以通过具体的考核办法落实下来。

比如企业鼓励在某一个业务领域内积累丰富的领域经验，鼓励在某个技术方向上进行深入钻研等，对于提倡的这些行为，要有具体的奖励措施。

所以在定义考核办法时，需要首先考虑清楚要体现企业的哪些价值观。

Ø 要体现多劳多得，质与量并重 

不能让那些完成了大量艰苦工作的人员吃亏，否则就会打击真正努力工作的人员的积极性。

多劳多得原则的实现，基于对工作量的计算。

规范的管理都是“以人为本、以过程为核心、以度量为基础”的。

要做到多劳多得就需要做好对工作量的度量，如果仅仅注重工作量而不关注工作质量，显然是不对的，而对于质量的考核，可以通过多个渠道来获得数据，如发现的缺陷个数、客户的反馈等等。

当然多劳多得的前提是团队的目标达成了，如果目标未完成，多劳未必多得。

Ø 要鼓励创新与规范管理 

管理与创新是软件企业发展的2个轮子，通过规范管理可以确保企业的常规发展，通过创新实现企业的跳跃式发展，管理为创新提供了转化为生产力的基础，创新可以快速地提高企业的竞争能力，因此在考核办法中要体现出来对这2者的认可。

有的企业设立了创新基金，专门用来奖励那些技术创新、管理创新等，有的企业在研发人员的考核指标中加入了对过程改进工作的支持等指标。

Ø 要鼓励技术复用 

成功的软件企业必须在人员、技术、过程三个方面加大投入。

软件复用是目前软件公司提高软件生产率的最有效的手段之一，为了在企业内建立组织级的技术复用体系，首先就要鼓励大家主动去提取可复用的各种构件，主动贡献可复用的构件。

对于这种提取可复用构件的行为，应根据其可能带来的收益，适当给予奖励。

Ø 要因时而变，但要尽可能保持连续性 

考核办法的制定都有一定的针对性，具有一定时限性，随着公司内外部环境的变化，随着公司文化的逐步稳定，对考核办法要逐步调整，在改变考核办法时，要注意保持考核办法的连续性，不要变化太大，否则就会让被考核人无所适从，产生观望的心态，或者在研究考核办法上花费很多时间，造成不必要的生产效率的下降。

Ø 要量化与非量化结合 

如果没有量化的考核指标，全靠非量化的指标，对于开发人员来讲，很难体现多劳多得的原则，很容易走向“吃大锅饭”的模式，无法调动开发人员的积极性。

如果全量化也很难，在开发过程中，有很多工作难以量化，比如需求开发的工作，就很难定量的计算工作量。

因此在考核时，在尽可能量化的基础上，也允许有一些非量化的指标的存在。

至于2者的比重，可以根据当前企业的管理水平来确定。

对于管理比较规范的企业，成熟度比较高的企业，可以采用量化的指标多一些，量化的比重大一些。

Ø 要区分不同的岗位，不能一刀切 

对于项目经理、需求分析人员、设计人员、程序员、测试人员、质量管理人员等，工作性质、能力要求、绩效表现的特征都有比较大的差别，因此要区别对待。

这样便于体现考核办法的内部公平性与外部公平性。

比如对于质量管理人员，大部分是日常的事务性的工作，其工作业绩的体现是长期的，他们的工作重心是预防缺陷的产生，采用量化的数据就比较困难，可以考虑采用改进率等指标来考核，而程序员的主要工作是实现设计，任务的规模与他们的工作效率、质量是可以量化的，这2种类型的考核办法就应该是不同的。

Ø 要保证被考核人的及时知情权 

事先要将考核办法告知被考核人，考核结果要及时通知被考核人。

考核的目的是为了发现改进工作业绩的方法，激励员工更加努力地工作，考核办法也代表了公司的价值观，因此要让被考核人对考核办法很清楚，让他们知道什么是应该努力去做好的，这样才能起到激励作用。

考核的结果应及时通知被考核人，这样能够给他们一个及时的肯定或者否定的刺激信号。

Ø 不以被考核人自己提供的数据为考核依据 

如果以被考核人自己提供的数据作为考核依据，则会造成数据的失真。

在软件企业中推行开发人员的个人日志时，遇到的最大的问题就是日志的失真问题，为什么呢？

因为开发人员担心自己填写的日志会成为自己的考核依据，会成为评价自己的工作努力程度的依据，因此本能地会倾向于满负荷地填写自己的工作量。

Ø 考核指标要和被考核人直接相关，被考核人对考核指标的达成能发挥重要的作用 

在很多软件公司中，经常发现员工的考核与公司的利润、部门的利润或者项目的利润挂钩，对于销售部门、事业部或者其他直接与市场相关部门，这种考核是有激励作用的，对于研发人员来讲，这种办法的激励作用就不那么明显了。

利润的形成有多方面的原因，可能大部分原因不是开发人员所能决定的，将不由开发人员所决定的因素与其考核挂钩，是不合理的，即使开发人员再努力，也不能对利润的形成起到实质性的帮助作用，为什么要和利润挂钩呢？

古人云：

知易行难。

道理很简单，落实时却涉及了企业的方方面面，有历史的原因，有现实的问题，有未来的不确定性，但是这些都不应该成为逃避考核问题的理由，必须去尝试，才有可能解决这个问题！

如何量化考核软件开发人员绩效

软件人员管理，一向被认为是一件难题。

尤其是年中年底的评价问题，涉及到加工资，发奖金，稍有差池，就会民怨沸腾，来年是该走的不走，不该走的全走了。

在开始一个软件项目之前，公司领导要与该项目主管对需要完成的工作内容、时间期限、考核的标准达成一致。

项目主管把任务进行分解，和每个软件开发人员对各自所需完成的工作内容、期限和考核标准达成一致，特别是各个模块之间的接口，并形成一份完整的“任务说明书”。

在期限结束时，主管根据每个开发人员的工作状况及原先制定的考核标准来进行考核。

为了避免到最后才发现问题过多、难以收拾，可以在开发期间设置几个考核点，设置相应的阶段性目标，根据完成目标情况给出考评的分数。

开发人员应具有较强的事业心、责任感和较深厚的基础理论知识，并不断提出新的思想和观念，为创造新产品和新技术提供条件。

通常研发一个软件项目所需的时间较长，我认为按项目的里程碑或项目来安排对软件人员的考核，若项目周期超长也可在年中和年末进行考核，以目标管理（ManagementByObjectives，简称为MBO）为原则设定KPI（KeyPerformanceIndex），考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。

根据客户关注点确定考核指标，同时将客户的满意度与做为考核的衡量标准，一个项目完成后，公司不要把该项目的奖金一下子全发给软件人员，可以留下30%～40%待一年后发放，给客户一年的时间发现问题，软件公司可根据问题的大小从余下奖金中相应扣除。

用下面的七项指标对开发人员进行绩效考核评定：

1.工作态度

2.软件质量（bug的等级和个数，回归次数，重要模块系数）

3.工作难易度（功能性，可靠性，易使用性，高效性，可维护性和可移植性，功能点数，复杂度）

4.工作效率/能力（完成百分比，工作经验）

5.主动性

6.沟通能力

7.程序规范程度

 1）非常及时，随时都可以查阅任意相关文档； 

 2）非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内； 

 3）较规范，较及时，一般可以查阅近期文档，文档编写滞后3～6天； 

 4）较规范，但不及时，常常难以查阅，文档编写滞后6天以上； 

 5）不规范，不及时，常常难以查阅，甚至没有编写相关文档。

代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。

每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。

微软公司对软件人员的绩效考核每半年进行一次，先由员工自己为这半年来的业绩做一个评估，打一个分数，然后放到网上，等待部门经理签字、打分。

没有经过部门经理打分、签字的信息呈红色;经理打完分后，如果员工认为经理的评价比较符合事实，再进行最后的确认，确认后信息变为绿色，业绩考核的过程就完了。

此外，部门经理打分的同时还要为每位员工制定下个半年的目标。

如果员工对经理的评价存有异议，便可以拒绝确认，更高层经理及人力资源部的人员看到后，会与员工沟通，直至查到员工拒签的原因。

也有些知名的IT公司已将软件开发人员的绩效评估建立形成了一个体系，每年有年度的绩效考核，开发部门有开发成本考核。

从每年12月开始到第二年1月份的两个月期间，公司上上下下都认真地做绩效考核，因为晋升调薪需要这个依据。

考核完后，经理要跟员工面谈，将考核结果告诉他。

考核的关键是评估后的沟通，这比评估更重要。

让员工知道他的不足在哪里，优势在哪里，员工自己要提出想法。

考核后排在后5％的员工要内部下岗，实际上是降工资，留岗观察。

公司软件开发人员绩效评价标准

总则：

   通过量化的指标准确的评定软件开发人员的绩效，从而对薪酬分配提供可靠的依据。

 基本说明：

   绩效评价，包括业绩考核和能力评定。

对软件开发人员的绩效评定，每一项问答表现优秀加一分，表现不佳扣一分，表现平平不得分，最后计算总分。

业绩考核：

   此项考核主要考核在一定时间内软件开发人员的任务完成情况。

主要包括有以下指标：

目标的完成度、难易度、贡献度。

  目标完成度 

●完成情况：

   能否总是在规定期限内完成工作？

或者尚能在规定的时限内完成工作，还是经常需要上级的催促才能按时完成工作，或者一贯拖延工作期限，即便在上级的催促下也不能按时完成工作？

   在困难或者环境变化的情况下，是否也完成了计划的工作？

   是否很快、很迅速、高标准、高质量、创造性的完成交给的工作？

   是否在完成工作的同时，又能很好地控制成本？

   如果工作没有完成是由于环境的变化还是个人能力的问题？

或者是工作太多了，根本无法完成？

   在工作中是仅仅要求完成任务还是主动进行工作流程的改进，高效运用相关资源来解决工作中出现的问题？

   上级人员交给其工作时是否放心？

●完成质量：

   提交的程序是否经常出现很多BUG？

是否经常需要修正或调整？

编码是否严格遵守代码规范性？

用户对其开发的软件是否满意？

●完成时间：

   总是提前完成任务，还是总是强调客观原因而无法准时完成任务？

是否经常需要有人催促才能完成工作？

难易度 

   所完成的工作是否是一般人不愿意干的工作？

或者是很烦很累枯燥无味的工作？

   所完成的工作是一般程序员都可以充分达成的目标，还是不易达成的挑战性目标？

   如果本人不在，本部门或本小组是否有替代的人？

贡献度 

   其所作的工作对公司创造了多少直接效益？

多少间接效益？

或者降低了多少成本？

   工作完成后的成本情况如何？

是否有效地控制成本？

   是否在圆满完成本职工作以外，还积极主动地从事其它相关事情？

   是否尽力为公司创造最大利益，在各方面尽了最大努力并取得了一定的成果？

能力评定：

   能力评定是通过对员工的日常工作的工作表现，观察、分析、评价其所具备的工作能力。

对其开发人员的能力评定，主要包括以下几项：

技术能力、理解力、沟通能力、主动性、团队精神、领导能力。

领导能力用于项目经理评价。

技术能力 

●业务知识：

   上级交待工作时是迅速、准确地抓住工作的关键还是反应迟钝，迟迟不能理解？

   是否在一个月内就迅速熟悉了新岗位的工作？

还是在新岗位工作超过三个月了还对许多业务流程不很熟悉，从