前言
这几天陆续开工了，收益不好的公司，没有年会，没有年终奖，没有开工红包，没有团建，也没有聚餐，唯一有的可能是降薪裁员...
收益好的公司开了年会，年终奖加倍...
接下来就来聊聊关于技术人的绩效评审以及年终奖那些事儿
以下基于个人经历展开讨论和思考，如果有不同的观点，欢迎交流探讨
关于年终奖
一般来讲，只要公司收益好，一般是多少都会发点年终奖的，例如13、4、5、6，7薪，过节费，项目奖，年终奖，xx绩效奖，部门xx奖等等
公司要是效益不好的话，可能就是这些各种发钱的项目就没有了，可能会有一点过节费，如果效益差到工资社保都拖欠的话，可能就是考虑能不能年底也发点工资的情况了
总的来说年终奖主要和公司收益挂钩，公司收益好，多少有点，收益不好，无
如果发年终奖的话，在相关制度下总量可能就那么多，发到个人这边一般就是和绩效挂钩了，绩效评级高，同类型岗位情况下发的多点，绩效低，发的少，那么公司是怎么对技术人进行绩效评审呢
微小型公司可能不需要绩效，发钱基本老板一个人就决定了
特殊情况的公司或者部门各种特殊的情况也有
这里分享一下我司今年出的年终奖方案
以下半年部门净收入目标完成率作为基础指标，实现目标销售净额的，按3%计提奖金池，未完成目标的，按3%×目标完成率计提奖金池，超过目标的，超过部分按10%增加奖金池。由分管领导与部门沟通后参照员工年终评估结果出具分配方案（年终评估为D或E员工无奖金）
负责人，其他前台部门等年终奖的计算方式是另外的方式，有兴趣的可以留言讨论，这里先不展开了
员工评估 D, E 是有硬指标的，具体占比百分之几咱也不知道，每年的评审结果都是只有领导知道
由于公司业务效益不行，净收入为负，亏损状态，所以我们这个部门的员工年终奖——无
关于绩效评审
先来看看我司对技术人员工的评估方式
第一步：直系领导直接打分，提交对应的表到人力部门
第二步：人力部门根据任务系统中的个人任务情况，以及考勤情况打分
第三步：人力总监最终决定给xxx员工涨薪，发奖金
日常任务由直系领导安排发放，包括任务工时评估，注意了，这里任务工时不是开发者评估的，大部分都是负责人直接评好写到周任务表上去的，有的任务用时会和开发者咨询协商
人力部门看的那个任务系统中的任务，一般是业务线负责人不忙的时候根据腾讯文档周任务表中的任务后期补上去的
日常的很多临时工作在周任务表上体现不出来的，然后很多周任务表中的任务没有写到任务系统中，任务系统中的任务只是创建，开始，完成状态，没有工时的体现
由于任务系统是人力部门单独推动的，最终的情况就是实际工作内容和任务系统记录其实是脱节状态，为了建任务而建任务
不同业务线的直系领导角色也不一样，有的是纯管理，有的是半后端开发半管理，有的是产品
总结一下就是直系领导决定主要的打分情况，人力部门根据基于一线负责人的打分结合考勤和任务情况，决定要不要涨薪，发多少奖金
以上就是我司绩效评审的一些情况，这也是相当一部分比例公司（部门/团队）的常规操作
从客观数据角度来看，基本没有体现岗位产出方面客观可量化的指标，唯一能量化的指标就是一个考勤了，两三个人的主观评价就决定了一个技术人的升职、加薪、辞退、奖金发放的问题
万物都有存在的道理，毕竟，大部分公司都是草台班子，甚至更水
从客观数据角度思考对于技术人的工作评审
先来看看技术人的实际工作都有哪些？
我们拿技术人中的开发人员来举例，从一个任务安排到工作完成提交都有哪些常见步骤：
参加需求评审会，了解需求，设计实现方案，代码编写，提交代码，线上测试，修复bug，输出文档，技术分享等等
开发人员工作产出一般通俗点讲就是开发了多少需求，功能，解决了多少bug等等
在技术圈内一般讨论一个开发人员是否大佬，是否能力出众的标准一般是：
- 解决问题的快慢程度（不局限于技术问题）
- 掌握技术栈的深度和广度
- 是否能和其他不同的工种、部门良好协作
- 技术方案执行落地能够良好取舍
- 定期更新技术栈，使用相对合适的技术解决业务问题
- 提交功能的bug数量
- 代码可读性是否良好
- 代码是否足够简洁优雅
- 开发的功能是否健壮
- 其他人接手可维护性是否容易
- 输出的文档是否专业，格式简洁明了
- ...
相对来讲，开发人员工作产出基本都是可以量化的，关于工作量化的问题，鲁迅说: 任何岗位的工作都是可以量化的
为了评审量化产出，也不能为了量化而量化，那样没任何意义了，浪费团队大把时间扯皮，还影响工作
关于量化产出激励团队方面，我个人比较喜欢敏捷开发那种模式，相对公正，公开
例如：在敏捷开发里面是日常工作是按照评估的人天，人时等方式
任务评估为了保证相对公平性是有这么一个前提的，团队岗位不是一个人评估
例如前端开发岗位，至少俩个人，一个人评估1人天，一个人评估10人天，这显然是有明显差距的，这种情况下一般 master 角色和团队其他成员参与讨论决定，master 也就是项目经理或者项目负责人的角色进行一定的把控
任务是个人根据需求池中的任务自己拉到个人任务表里，而不是单纯的分配，这种机制有个很不错的方式，就是优秀的人在一起会激发更强大的创造力
这里推荐看下美剧 《硅谷》 中 Dinesh 和 Gilfoyle 敏捷开发时的竞争桥段
还有就是不同的开发任务难易程度不一样，举个例子，有两个小任务，同样都是2人天，第一个任务需要大量的尝试新方案，进行相应的测试，并编写一定数据量的代码；第二个任务是使用现有方案，直接写一定量的代码，如常见的业务需求
这种情况的任务如果在项目工期相对紧张的情况，任务是自我选择的话绝大多数都会选择第二个任务，虽然量大，没有风险，不会出现研究过程某个地方卡壳导致任务延期（延期也有对应的处理机制，这里先不讨论）
但是这样很可能会出现难度高的任务会放到最后，没人做了，所以要有人为把控优先级，并且进行合理安排进行一定的调整
同样都是2天的任务，接受度是不一样的，这种任务一般会增加一个难度系数，也有的是进行难度分类，例如：难，一般，容易
最终任务产出统计时，工时还需要乘以难度系数
理想情况下以上的操作基本能实现大部分开发工作产出的量化，对于年终的工作评审结果相对公平客观
注意！！！
这里有个点，敏捷的机制是激励那些那些高效率高产出的人，是一种公开透明的激励机制
良好落地敏捷也是需要一定条件的，如团队需要有一定规模，并且要进行培训和认同这种机制，而且岗位对应人员至少是一个人，级别不能相差太大等等
每一种机制都是基于特定人群设计的，如果用错了人群可能机制流程就变成了纯形式化了
基于客观数据的评审方式
简单分析了一下后，基于客观数据相对公正的评审方式可看如下例子
日常任务得分 * 权重系数 + 直系领导打分 * 权重系数 + 部门领导/CXO 打分 * 权重系统 + 人事考勤得分 * 权重系数 + 其他得分
日常任务得分权重 > 领导打分权重 > ...
单纯衡量技术人的工作的话，应该主要以产出为主，其他环节占比相对小一点
相对来讲这种方式各方都有参与环节，基于数据数据说话是比较客观公正的
以上都是理想状态，一个公司的做事风格和方式和创始人有着直接关系，最终落地后的是个什么东西还得看公司老板和高管是如何做的
写在最后
这个世界没有绝对的公平合理
欢迎大家讨论交流，如果喜欢本文章或感觉文章有用，动动你那发财的小手点赞、收藏、关注再走呗
^_^
网友评论