绩效考核之我见，我的一些想法，请各位大牛、小牛、小鸟们给点意见

我公司是个小公司，技术部程序员加美工也就10来个人，最近因为某些原因要进行一些改革，首先从绩效考核开始，因为大家都知道的开发这项工作不同于销售很难进行量化，因此我的想法是绩效考核应从效率、质量、创新等几方面进行评估，下面是我的想法不知道可不可行，请各位大牛，小牛，小鸟们给点意见

1.效率（40%）

以类和页面做为工作的最小单位，在不区分web前端和后端的情况下，以实例子帐号管理模块说明，它有列表、添加、修改和删除4个功能，根据详细设计文档可以得出此模块由以下8个类、2个页面和几个配置文件组成。

1) QueryParams			查询参数对象
2) User				数据实体对象
3) UserDAO			数据访问对象
       findUserList()
       findUser()
       findEmail()
       addUser()
       update()
       delete()
4) UserService			业务逻辑对象
       getUserList()
       getUserAdd()
       getUserEdit()
       checkEmail()
       updateUser()
       deleteUser()
5) UserAction			逻辑控制对象
       user_list()
       user_add()
       user_edit()
       user_delete()
       check_email()
6) UserFormAction			逻辑控制对象
       user_add_submit()
       user_edit_submit()
       validateUser_add_submit()
       validateUser_edit_submit()
7) UserActionTest			
8) UserFormActionTest		
9) user_list.jsp			列表页面
10) user_form.jsp			添加/修改表单页面

根据经验一个好的编码流程可以大大提高效率

第1步：分析设计文档建立好所需要的类、页面和配置文件（1个工作日内）

第2步：定义Action、Service和DAO中需要的方法，再编写单元测试（半个工作日内）

第3步：编写Action、Service和DAO的具体实现，然后执行单元测试（按方法的数量及逻辑复杂度来估计时间，比如这里的UserDAO应该1个小时能搞定。UserService牵涉的东西多半个工作日，Action有表单验证2个小时，合起来保守估计1个半工作日）

第4步：编写页面及调式（保守估计1个半工作日）

因此此模块需要4+2个工作日。因为根据以往的开发情况来看，主要拉长时间的都属于web前端这一块，特别是表单页面，所以保守估计预留2个工作日应付这种情况以及其他突发情况。

评分标准

在指定时间内完成，合格分

提前时间10%-20%左右，良好分

提前时间20%-30%左右，优秀分

提前时间40%以上，出色分

未在指定时间内完成，不及格分

超过指定时间20%以上，差

超过指定时间40%以上，很差

超过指定时间60%以上，非常差

补充说明：

1)完成的定义，是指你交付给项目负责人检查时，没有被检查出bug存在

2)未完成如果是因为特殊原因造成，比如中途有其他任务插入或者请假之类的，给予增加相应的时间

3)这里的估计是在假设具体负责人了解模块业务流程，并且熟练掌握各种需要的技术及工具的情况下。所以如果你业务流程不了解，或是需要的技术及工具不熟悉，这就需要你平常主动去学习和掌握它。

2.质量（40%）

2.1.编码规范

主要就是3点：命名、注释、排版

详见svn://192.168.1.250/docs/B2B文档V3.0/开发/Java编码规范.doc与网页设计规范.doc

评分标准

命名：符合设计文档的要求

注释：说明类、方法要完成的功能，每个输入参数的描述，返回值是什么

排版：如果是Java文件那就简单，就是调用eclipse的格式化功能，可以说是一种习惯问题。其他的诸如html、jsp、php等文件可能就需要手动调整

这些问题由项目负责人检查，发现问题后首先记录在当月的考核报表中，然后再提醒具体负责人修正，如果提醒超过3次以上，每超过1次扣当月质量分x分。

2.2.单元测试条件覆盖率

评分标准

查询方法：

1)默认的查询（所有参数都是默认值的查询）

2)所有参数的查询

3)个别参数的查询

更新方法：要被更新的字段是否都存在

添加方法：所有需要的字段是否都存在

删除方法：结合添加方法测试，也就是说先调用添加，然后再删除，也就是说只有添加和删除都存在时才需要测试

这里如果检查时被发现，直接记录历史并扣当月质量分x分。

2.3.代码设计

首先引用【重构改善既有代码设计艺术美：MartinFowier著侯捷熊杰译】中的一段话：作为一个程序员，任谁都有看不顺眼手上代码的情况，代码来自你邻桌的那个菜鸟，或三个月前的自己...

代码设计到底怎么样才是好的设计？这是一个牵涉面很广的领域，有很多经典的巨著，如上面提到的“重构改善既有代码设计艺术”与“设计模式”。人不同于机器每个人都有自己的想法，每个人的水平和经验也不同，不能一概而论，因此很难有一个客观的评分标准。但根据我以往的开发经验我认为最重要的是要做到以下几点。

1)抽取重复的代码片段（这是我在带领团队后发现得最多的问题）

2)合并重复的条件片段

3)引入参数对象

4)以异常取代错误代码

5)以测试取代异常

这里如果检查时被发现，首先记录历史和提醒3次，如果超过扣当月质量分x分。

3.创新（20%）

简而言之就是我们目前没有的东西，谁先引入进来就算谁的创新，前提条件是引入进来的技术或工具必须是成熟和稳定的。

评分标准，每创新1次视具体的作用程度，记录历史并加当月创新分x分。

4.季度总结

每季度评出一个技术之星，评分标准，3个月中考核总分最高者

5.年度总结

给予评过技术之星的人提高基本工资

这样能做到一个良性循环