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

   我公司是个小公司,技术部程序员加美工也就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. 代码设计
   首先引用【重构改善既有代码设计艺术 美:Martin Fowier 著 侯捷 熊杰 译】中的一段话:作为一个程序员,任谁都有看不顺眼手上代码的情况,代码来自你邻桌的那个菜鸟,或三个月前的自己...

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

   1) 抽取重复的代码片段(这是我在带领团队后发现得最多的问题)
   2) 合并重复的条件片段
   3) 引入参数对象
   4) 以异常取代错误代码
   5) 以测试取代异常

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

3. 创新(20%)
   简而言之就是我们目前没有的东西,谁先引入进来就算谁的创新,前提条件是引入进来的技术或工具必须是成熟和稳定的。
   评分标准,每创新1次视具体的作用程度,记录历史并加当月创新分x分。

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

5. 年度总结
   给予评过技术之星的人提高基本工资


这样能做到一个良性循环

猜你喜欢

转载自linliuwei.iteye.com/blog/517722