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

来这个公司实习已经半年多了，在年前经历了一次年终考核，最终对个人工做的评级是 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 的绩效，此文为实习生半年来对本身第一次绩效考核作的一次思考，也但愿有前辈能指出不足或不对之处，谢谢。