绩效考核之我见，我的一些想法，请各位大牛、小牛、小鸟们给点意见我公司是个小公司，技术部程序员加美工也就10
绩效考核之我见，我的一些想法，请各位大牛、小牛、小鸟们给点意见
我公司是个小公司，技术部程序员加美工也就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) UserActionTest8) UserFormActionTest9) 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. 代码设计 首先引用【重构改善既有代码设计艺术 美：Martin Fowier 著 侯捷 熊杰 译】中的一段话：作为一个程序员，任谁都有看不顺眼手上代码的情况，代码来自你邻桌的那个菜鸟，或三个月前的自己...
代码设计到底怎么样才是好的设计？这是一个牵涉面很广的领域，有很多经典的巨著，如上面提到的“重构改善既有代码设计艺术”与“设计模式”。人不同于机器每个人都有自己的想法，每个人的水平和经验也不同，不能一概而论，因此很难有一个客观的评分标准。但根据我以往的开发经验我认为最重要的是要做到以下几点。
1) 抽取重复的代码片段（这是我在带领团队后发现得最多的问题）
2) 合并重复的条件片段
3) 引入参数对象
4) 以异常取代错误代码
5) 以测试取代异常
这里如果检查时被发现，首先记录历史和提醒3次，如果超过扣当月质量分x分。
3. 创新（20%） 简而言之就是我们目前没有的东西，谁先引入进来就算谁的创新，前提条件是引入进来的技术或工具必须是成熟和稳定的。
评分标准，每创新1次视具体的作用程度，记录历史并加当月创新分x分。
4. 季度总结 每季度评出一个技术之星，评分标准，3个月中考核总分最高者
5. 年度总结 给予评过技术之星的人提高基本工资
这样能做到一个良性循环
13 楼 amonlei 2009-11-25 绩效考核是项目管理一个很有用的工具，能够在一定程度上对员工进行一定的奖惩，但是一定要公平公正，不一定要公开（最好最差的不定期公开）。 14 楼 yuchangsheng 2009-11-25 应该谁牛谁涨工资,别想着扣 15 楼 yiding_he 2009-11-26 小公司因为不稳定，所以非常需要人性化（人情味）的管理来加强凝聚力。哪怕是 100 人以上的公司，都不应该轻易放弃以人际关系作为主要管理手段。 16 楼 七月十五 2009-11-27 千万不要做绩效考核，这样会引起反感的。
绩效应该是管理的，是一个不折不扣的激励机制，而且是一个沟通的过程。绩效管理跟企业的方向、目标、组织架构、岗位设置、职责和KPI等等密切挂勾。
单纯做考核，走入企业管理的误区了。 17 楼 282912533 2009-11-28 一些公司里面开发人员又兼职产品维护 , 或许可以让专人来维护产品 , 但这样对维护人员的要求也很高 , 代码上,业务上
产品版本升级 , 客户一个电话就陷入问题查找的工作中 , 这样在现在大多公司还是存在的 .
外包公司绩效好弄点 , 加班就是涨绩效 , 但一般公司绩效就真不怎么好弄了 18 楼 JavaLanguageFun 2009-11-29 raojl 写道最讨厌这种公司，没有给于员工最好福利，却想像自己的员工是最好的！往往适得其反！
我认为最好的绩效可以学习下‘学校’的方式，绝对不能从员工利益下手,应该从激励，效益，文化方面入手！特别是小公司。
我赞成你的说法~~！
19 楼 javadaydayup 2009-11-30 我们也是每天都要写日志，很恶心，稍不好还要扣工资 20 楼 yuyue618 2009-12-01 我的绩效一般都是100% 不扣也不加 21 楼 yuyue618 2009-12-01 javadaydayup 写道我们也是每天都要写日志，很恶心，稍不好还要扣工资
上一家公司也是这样. 我自己感觉日志不应该是强制. 是应该是种良性的总结. 一个我自完善的过程. 不应计入绩效 22 楼 lmxbitihero 2009-12-02 我呆过5家公司了，每家公司都或多或少在做绩效考核，但有这么一个规律：绩效考核做的粗的，发展还不错，做的细的，都接近倒闭。按绩效发奖金的，发展还不错，扣工资的，都接近关张。
市场经济运行了这么多年，我们每个人在绝大多数时候都是花钱的上帝，是上帝就要求花钱清楚明白，买的东西结实耐用。就像买个机器，一定要物有所值，买来以后让机器24小时运转不停，赚回本钱。老板花钱雇人，也把自己当成了员工的上帝了。要求对雇拥的员工工作效率做到最大化，不准偷懒。希望员工24小时连轴转，赚回本钱。
一切看起来似乎都理由充分，可是，员工可不是机器。谁也不希望在摄像头下工作，都是成人了，管的太严谁都会反感，一旦有反感情绪，考核带来的一点点积极作用反而不如消极情绪带来的反作用那么大。所以，最好的考核方式就是不考核，通过文化上的感染，来团结员工，让员工发挥合力。每当有项目的时候，先跟员工说好，按时完成发多少奖金，员工自然就有积极性了。 23 楼 andyu2008 2009-12-02 太理想主义，理想的我耐着性子都没看完 24 楼 Jwind 2009-12-02 这还是工作吗？
这样的公司迟早把人逼疯，太不现实了。 25 楼 transist 2009-12-03 太复杂的管理是泥潭 26 楼 photon 2009-12-03 我觉得楼主如果多花时间和同事们谈天、唠嗑，多在一起打怪，做任务（广义上的），和周围的人关系更近些而不是更远些，效果可能会更好些。 27 楼 daisky 2009-12-04 可行性不是很高.
跟踪项目里程碑就可以了.
按时完成里程碑就是好,不按时完成且有合理理由就是中,不按时完成且没有合理理由就是差. 28 楼 七月十五 2009-12-06 没有理解绩效管理的真谛的都认为绩效管理就是绩效考核，其实这是个严重的误区。 29 楼 dyuan 2009-12-07 lmxbitihero 写道 我呆过5家公司了，每家公司都或多或少在做绩效考核，但有这么一个规律：绩效考核做的粗的，发展还不错，做的细的，都接近倒闭。按绩效发奖金的，发展还不错，扣工资的，都接近关张。
市场经济运行了这么多年，我们每个人在绝大多数时候都是花钱的上帝，是上帝就要求花钱清楚明白，买的东西结实耐用。就像买个机器，一定要物有所值，买来以后让机器24小时运转不停，赚回本钱。老板花钱雇人，也把自己当成了员工的上帝了。要求对雇拥的员工工作效率做到最大化，不准偷懒。希望员工24小时连轴转，赚回本钱。
一切看起来似乎都理由充分，可是，员工可不是机器。谁也不希望在摄像头下工作，都是成人了，管的太严谁都会反感，一旦有反感情绪，考核带来的一点点积极作用反而不如消极情绪带来的反作用那么大。所以，最好的考核方式就是不考核，通过文化上的感染，来团结员工，让员工发挥合力。每当有项目的时候，先跟员工说好，按时完成发多少奖金，员工自然就有积极性了。
赞同这个仁兄的观点，搞开发的要量化基本上很难，不太可能量化，人员的水平都不一样，一个任务，以什么标准来衡量呢。。难。。粗粒度的考核就可以了。。我们公司现在主张的就是粗粒度考核 30 楼 weihairui 2009-12-28 这种考核制度不好，应该只要按时完成就可以了。而不是按时完成只能是及格。 31 楼 lelong 2009-12-29 很快，你会发现内耗很严重 32 楼 ccxw1983 2010-09-22 282912533 写道一些公司里面开发人员又兼职产品维护 , 或许可以让专人来维护产品 , 但这样对维护人员的要求也很高 , 代码上,业务上
产品版本升级 , 客户一个电话就陷入问题查找的工作中 , 这样在现在大多公司还是存在的 .
外包公司绩效好弄点 , 加班就是涨绩效 , 但一般公司绩效就真不怎么好弄了
我的上一家公司就是这样的，所以我们一般没年终奖，发就都发自己一个月工资。
