技术人员应对「考核」的一些思考

来这个公司实习已经半年多了，在年前经历了一次年终考核，最终对我的工作的评级是 C（及格-符合当前职位的工作），让我不禁思考自己在项目中的一些工作的问题，为什么我是C？是我做的不够好吗？或者说在哪里做的不够好？

从考核流程来看，基本上是 CTO 与 Team Leader 对团队成员的「年终总结与次年工作计划」进行Rank，个人狭义的认为「考核」的主要支持材料就是这个总结了。

他山之石

其他公司是怎么考核的呢？说实话我也不太清楚，刚入行，只能通过搜索了解，在网上了解到有以下几种：发精品博客、发论文、开源项目、出书、技术分享大会、技术公众号/微博/知乎 等，这一类绩效方式是通过推广自己的技术来提升公司在行业中声望。如Element、Qcon等。

其他类型的我就没看到了，很明显，这类考核仅适合大公司或者高层次技术人员的考核，或者说，我自己是不具备相关条件的。

对于我个人，由于是实习生，很多知识点还不算熟练，半年来也就是「积极完成产品的需求，以及1~2天一次的高频率的发布，跟进线上日志，平时会整理一些项目的文档，和其他部门的人沟通一些业务等」，看上去平平淡淡，中庸到我自己都会给自己打 「C Rank」了，但是这也就是一个技术人员的真实工作情况，我 leader 也在感叹如何获取更好的绩效，毕竟我参加的项目是一个已经运行了 8~9 年的一个老项目了，平时的工作要求也真的只是完成产品的需求，不容易产生「突出」的工作成果，那么我该怎么去做来打破这一困局呢？

考核量化？

反对对技术人员的过分量化管理，为了“指标”容易脱离产品，不利于开发效率，也不利于真正提升产品质量。比如：为了追求低异常率，而花费大量的时间资源进行测试，会降低项目迭代速度，最终影响项目进度，而某些产品正需要快速迭代。

考核的缺陷

首先来思考一下这样考核的缺陷

对技术人员的考核一般是体现就是在他的产品上，相较于研发部门，业务开发的部门的程序员可能更不容易突出自己的工作，举个例子来说，业务开发人员的工作内容可能就只有一种「完成A需求，B需求，C需求……」。而研发部门更容易突出自己的成果，如「 反垃圾、对XX进行深度学习、精准推荐……」 ,并且即使业务开发人员说他完成了XX等功能模块的开发，但考核时并不会把这一项归功到程序员上，而是会把这个工作更多的归功到设计这一功能的产品身上，所以对于纯粹做业务开发的程序员来说，并不容易在整个产品技术部门的考核中占据优势。

对程序员考核其他可能的偏差因素：

• 是否为公司新项目，是否为重点项目

        新项目或重点项目更加容易得到公司高层的关注，如腾讯的 英雄联盟 和 微信，相较于什么“QQ音乐”肯定是更加受关注的，对业务程序员来讲，基础需求开发的工程都是差不多的，本来应该是产品性质决定的两者性质不同，但管理层在实际考核中会更偏袒于新项目或者重点项目。

• 销售额、毛利率、产品估价等外因影响项目的评价

        某些产品受大环境影响比较大，可能有的项目这一年的开发量或工作量不是很多，改进也不大，但随着政策或大环境的发展成为一大热点，PV 或销售额上升，此类为外因导致的产品绩效提升，如 “各类娱乐圈事件在微博上发酵提升了产品活跃度”这一背景可能会让新浪对 微博开发部门 的评价整体提高。

• 行业领域的发展

        在这段时间尤为火爆的前端，「Vue.js 」与「 微信小程序」 在技术圈还是比较吸引眼球的， 阿尔法狗的人工智能或深度学习也是吸引了大家的眼球，不可否认新技术的使用是绩效的一大加分项，也是对技术人员的挑战，但与iOS 、Android 、Java、PHP 相比，后者在技术圈几乎没什么波澜了，特别是服务器端的开发很难出现像 「小程序」 这样的IP，相较于前端部门，移动端/服务器端部门在今年的评价的确是比前端低。

• 其他因素

        是否准时上班、考勤打卡、加班、是否在上班时间浏览微博新闻等，这里不过多阐述。

以上因素可能不能从程序员自身得到解决，也就是说：相同的程序员在不同的项目的最终评分会因为这类因素导致不一样。

我眼中的技术人员的考核的目的

对于公司和个人来说是出于人事薪资管理的目的

对项目来说目的是「希望技术人员能运用技术手段让项目更加好」

所以，技术人员如何使产品更加完善呢

站在销售角度：提升毛利率 ≈ 降低人工成本 + 销售额度提升

销售这一块我没想到什么好的技术人员可以辅助的手段

在降低人工成本方面：

• 多信息导入流程中，将手动填写表单转为用户使用Excel批量导入信息，降低客户的编写成本
• 使用反垃圾技术提升社区网站垃圾的信息的屏蔽速度（参考 ：知乎的悟空系统）
• 自动化/辅助运营，如EDM

站在Boss角度：面向关键指标(KPI)的提升

可以先想象一个场景：

「  程序员向非技术出身的Boss作工作汇报（错误的方式）」

Boss: 小K，你来汇报一下这个月的工作吧！

小  K：这个月完成了对项目的老的 Spring 框架的升级，升级之后项目就可以用新特性进行开发了，而且更安全，以及摒弃了某数据对XML的依赖，改为使用数据库进行此类数据的管理，这样操作效率更高，修复了许多线上的异常，解决了N个慢查询的SQL,同时完成了A\B\C\D\E\F\G等功能特性的开发……

Boss：好！（？？？听的一脸懵逼，但还是要保持微笑）

小 K ：谢谢老板。

其实越对于高层的人员，其实是越脱离项目的业务逻辑的，他们可能关心你所在的项目，但不关心你的项目细节，他们更希望听到的是产品在你手里有什么提升的地方。其实在上面那个场景已经说到了几点 「提升速度」、「安全性」、「稳定性」等，这些可以被称作技术人员的项目的关键指标，既然是要汇报工作，建议使用数据说话，用通俗的语言来描述自己的工作。

如：

    给首页添加一套缓存机制，以前首页需要1s，现在只需要0.4s就能打开，且能保证数据更新，提升了60%速度！

标准格式：技术名称+应用场景+以前+现在+改善多少

再举一个例子：

    对搜索项目今年改为双机部署，之前线上单机的时候线上有一定的失败率，导致用户搜索不到结果，每天这个情况约发生2000+次，双机部署后，状况良好，几乎不再出现这种情况了。

其实这些数据获取也非常方便，直接ssh到服务器上，然后用 grep命令统计特定关键词，一分钟不到就能可以统计到的事。

例：可以需统计的数字

• 发布次数、补发次数->发布成功率  （稳定性）
• 需求量 / 开发人数 = 效率 
• 解决慢查询的次数 并 估计可以提升的页面访问效率 （访问速度提升）
• 对搜索接口作缓存处理/双机处理，避免无法使用（稳定性）
• 线上异常数量，并做好统计，并以这个数据来设计一套 「项目健康度」，且有利于技术人员了解项目健康程度
• 内存使用降低多少。
• 自我渗透测试解决XX漏洞（没有QA部门的可以试试）

这些其实都是做业务开发的人员的工作，但有数据支持，特别是提升的方面的数据支持其实能给自己绩效增添不少分，因为言语够通俗，且你在项目中发挥的作用很明显，不再是「完成XXX等重点业务开发」这样的话了。如果能用图表表现的话可能会更加直观。

站在产品角度：技术人员可以尝试对竞品进行分析

举个例子来说，开启开发者工具，打开Network选项，然后打开某站，整套工作流程走下来，粗略的看中间的请求头与请求内容，哪些是Ajax，为什么这个是使用Ajax的，是否采用了restful的接口设计，他是如何规避CSRF，是否存在XSS、越权等，他的字段设计是怎么样的，表间关系大概是怎么样的，页面相应时间是否比我项目的快，可能可以通过缓存来优化相应速度的地方有哪些，他的SEO策略有哪些，站点是否有反爬虫机制。

还有一个例子是Word导出的方法，这个我也是调研了十几个产品的同类功能，最终总结出5个方法的，分别都有哪些优缺点什么的，然后根据自己产品的实际情况技术选型，然后完成开发，目前感觉效果还不错。这个过程也不错

这个过程不仅好玩，还能通过对比其他产品来提升自己的产品，还能提升自己开发过程中的安全意识，比如说我在调研竞品的时候发现了它的越权漏洞，于是我就开始排查自己业务中的漏洞，而且真的排查出来了。(不过我不是白帽子，也不知道咋报告，毕竟是竞品就让bug留在那把😋)

站在听众的角度：重点变动的前后对比截图存档

这一条实际对个人成长没什么提升，但对绩效考核作为工作的证明是非常直观的，如 「站点首页的改版」 这类工作，一句话可能说不清楚改了什么，但如果有一个前后对比图可以让leader看到两个是彻头彻尾的不一样，而且是在你的改版下网站变的不一样了。

同理，上面说的一些效率的提升的比率也可以用柱形图来进行对比，图片毕竟比文字直观。

其他方面

团队管理与人员培养、提升开发效率、打铁还需自身硬，保持学习、项目总结、技术积累、技术分享、人员招聘、制度完善、代码规范、项目管理工具的引入、良好格式的年终总结……

这些都是工作中可以提升的地方，就不一一举例了。

结语

半年的实习生活是愉快且富有挑战的，虽然以 C Rank 结尾，但学到的东西是远远不是这个绩效能衡量的，希望下次考核能得到 B 以上甚至 A 的绩效，此文为实习生半年来对自己第一次绩效考核做的一次思考，也希望有前辈能指出不足或不对之处，谢谢。