软件开发人员的绩效考核
序号标准说明评分标准
1 错误率
每千行程序20个错误以下（包含20个）5
每千行程序21-25个错误4
每千行程序26-30个错误3
每千行程序31-35个错误2
每千行程序36个错误以上（包含36个）1
2 新技术使用情况
大量使用新技术，并且解决了传统技术无法解决的问题；5
大量使用新技术，解决了传统技术难以解决的问题，大大提高了工作效率；4
使用部分新技术，替代了部分传统技术，一定程度上提高了工作效率；3
使用了少量的新技术，替代了了少量的传统技术；2
没有使用任何新技术，仍然用传统技术解决问题；1
3 程序编码的规范性
编码非常规范，无可挑剔，同时又对公司制度规范提出了改进意见；5
编码非常规范，无可挑剔； 4
编码规范，不符合规范之处很少；3
编码基本规范，但不影响对程序的理解；2
编码存在较大的不规范性，并且对程序理解造成了比较严重理解误差；1
4 文档编写的规范性
文档书写按照公司的相关模板，规范、美观，无可挑剔；5
文档书写按照公司的相关模板，规范，但美观性上有待改进；4
文档书写基本规范，但美观性上有待改进；3
文档书写的规范性、美观性上都有待改进；2
文档书写的规范性、美观性上都存在很大的改进空间；1
5 及时性
能够在预定时间的80%内完成；5
能够在预定时间的90%内完成；4
能够在预定的时间内完成； 3
超过预定时间的10%才完成计划；2
超过预定时间的20%才完成计划；1
6 编码注释的完整性
编码注解完整、清楚、容易被人理解，不会造成理解方面的偏差；5
编码注解完整、清楚、比较容易被人理解，但会引起少量的理解偏差；4
编码注解完整，比较清楚，但会引起部分理解的偏差；3
编码注解比较完整，但有部分代码没有注解；2
编码注释不完整，大量的编码没有注释，让人难以理解；1
软件服务型企业，其核心竞争力在软件。软件开发人员是此类企业人员中的精华，他们应具有较强的事业心、责任感，较深厚的基础理论知识，并不断提出新的思想和观念，为创造新产品、新技术创造条件。
对于软件开发人员的业绩考核与公司其他人员（如管理、销售、工人等）都有很大的不同。是否准时上下班、着装是否符合要求等对一般员工的要求对软件开发人员当然可以大大放松。而且由于一个比较大的软件系统所需要的开发时间都比较长，对于软件人员的考核周期也可以比一般人员的考核周期放宽：一般人员如果一个月就要考核一次，软件人员可能要3个月、半年、甚至一年才考核一次，基本上是按照这个项目的周期来安排。
目标考核法
目标考核法是根据员工完成工作目标的情况来进行考核的一种绩效考核方法。对软件人员比较合适。1954年，德鲁克提出了一个具有划时代意义的概念——目标管理（Management By Objectives，简称为MBO），它是德鲁克所发明的最重要、最有影响的概念，并已成为当代管理体系的重要组成部分。
在开始一个软件项目之前，公司领导要与该项目主管对需要完成的工作内容、时间期限、考核的标准达成一致。项目主管把任务进行分解，把每个软件开发人员所需要完成的部分的内容、期限、考核标准也要达成一致，特别是各个模块之间的接口。并形成一份完整的文档“任务说明书”。在期限结束时，主管根据每个开发人员的工作状况及原先制定的考核标准来进行考核。为了避免到最后才发现问题过多、难以收拾，可以在开发期间设置几个考核点，设置相应的阶段性目标，根据完成目标情况给出考评的分数。
根据客户关注点确定考核指标
工作内容可以划分为几个独立的模块，在每个模块中用明确的语言描述工作需要达到的标准，可以分为几个等级选项，如“优、良、合格、不合格”。软件产品的质量特性按ISO/IEC 9126的定义，包括六个一级特性和分解之后的21个子特性。六个一级特性分别是：功能性、可靠性、易使用性、高效性、可维护性、可移植性。
在以上六大类21个子特性中，客户往往只关心几个重要的指标，只要把这几个重要指标解决了，客户满意就有保证，而不需要在软件开发时耗费大量的资源在客户并不是很关心的特性指标上。比如“易使用性”中的“易学习”子特性，如果把它作为一个重要特性指标看待，则意味着软件开发需要在操作界面的帮助功能以及误操作提示处理上下很大工夫。如果该软件的使用对象具有很高的计算机专业技能、使用人员固定，则该软件的学习使用可以通过集中培训来解决，而不需要像微软的office 软件一样提供很强的在线帮助。再如电信企业的客户，均很关心可靠性中的成熟性、容错性、可恢复性等指标，对于其他特性的关注则轻得多。如果不理解这一点，即便提供再多的功能，操作再方便，维护成本再低，都不可能使客户满意。
所以在制定软件人员的考核指标时，要紧密结合该项目的顾客关注的指标，顾客重视的内容作为考核的重点内容，其他作为辅助考核指标。
程序的规范程度是考核的重要因素
印度的软件之所以发达，与他们产品的规范是有很大关系的。虽然编程员的水平不要求多高，但大家都受过严格的训练，一切都模式化了，程序的可读性好，便于“兵团作战”。而我们的程序员可能水平很高，但不愿意接受严格的规范，懒得写注释，自己写的程序只有自己懂，难以保证质量的连续性，也无助于树立软件公司的形象。规范化管理就要将操作流程固定下来，将所有好的做法在组织内共享，通过制度的力量影响结果的质量。
为了驱动软件人员向规范化管理靠拢，考核时就要采取细化尺度。如关于软件技术文档的编写水平，就可以定为以下几个级别：
1.编写非常规范，非常及时，随时都可以查阅任意相关文档；
2.编写非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内；
3.编写较规范，较及时，一般可以查阅近期文档，文档编写滞后3-6天；
4.编写较规范，但不及时，常常难以查阅，文档编写滞后6天以上；
5.编写不规范，不及时，常常难以查阅，甚至没有编写相关文档。
客户参与考核
一个软件系统项目，是否能满足客户的应用要求，不可能通过一次测试验收就能作出结论；客户关心的质量特性指标并不能在短时间内遍历。为了鼓励软件人员提升知识和技能，可以在考核时让客户参与进来。这样既可以在过程中体现公司对客户的重视，也可以使软件人员的成果与客户的想法直接进行碰撞，根据反馈改进软件产品。客户的参与不是单方的要求，而是双方的共同需要。“闭合”不是等价于一个圆的形成——在每个项目完成后进行客户沟通和项目总结，并反馈到市场营销——而是存在着多个圆，需要在与客户的各个接口界面上都进行双向的沟通。
一个项目完成并交给客户后，不要把该项目的奖金一下子全放下去。可以留下30-40%待一年后发放，给客户一年的时间发现问题。软件公司则根据问题的大小从余下奖金中相应扣除。通过这样做，就使软件人员更加明确：“客户满意度”是企业所追求的一项重要目标。
其他可以考核的指标
除了以上要考虑的因素外，企业还可以根据自身的战略目标、鼓励的企业文化，设置其他需要考核的指标。但由于软件人员主要以结果为导向，这些其他因素所占的比重不能过大
