绩效考核之我见，我的一些想法，请各位大牛、小牛、小鸟们给点意见
我公司是个小公司，技术部程序员加美工也就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.年度总结
给予评过技术之星的人提高基本工资
这样能做到一个良性循环