据江边望海了解很多互联网公司都会执行Kpi考核。一线的开发人员的Kpi工作量化不仅困扰这公司的HR也困扰着开发人员自己。月底的时候如何通过有效的数据分析每个开发人员的工作内容是一个很头疼的问题。所以，很多开发人员的Kpi绩效考核是直接领导凭借感觉打出来的。

很多网络公司每年都会有职位晋升的机会。但是，开发人员在准备填写晋升表的时候发现能拿出手的数据少之又少。天天在忙，却忙的没有结果。

1.基础篇

1.1.产品线思路

开发人员是网络公司的基础资源，类似大厨手中的食材。很多时候都是在相应产品经理、公司业务的需求。每个开发人员既隶属于行政划分的智能部门有隶属于虚拟划分的产品线。所以，每个开发人员至少与一个产品线有关联。

第一步：明确任务数：

产品线的工作量就是开发人员的工作量。比如。某个产品线在迭代的第一个周期，产品经理输出了30个需求。而这30个需求又被项目经理（一般由开发主管担任）分解成了90个任务。假设这个产品线一共有5个开发人员。你自己领取的和领导指派给你的任务是20个。

第二步：明确工时：

每个任务的处理都需要码农（开发人员）在下面不停的码代码。码完之后需要把工时记录下来。很多码农会质疑，我怎么能清楚的算出我完成任务所花费的时间呢？答案是，一开始肯定不精确，但是随着你和团队逐渐在意工时这个参数了，也就以为着这个数值会越来越准。

第三步：明确BUG：

有任务就肯定会产生BUG。指派给你的20个任务不可能不出现BUG，如果没有出现恭喜你，你已经成为『任务君』啦。BUG量越少越能体现任务执行的质量。

综述：任务数+工时+BUG是考核开发人员重点。

PS:很多时候，新入职的开发人员处理的是前任开发人员遗留的BUG。这个时候就可以将这个BUG理解成任务。当开发人员处理这个任务的时候再出现BUG的时候就需要这个开发人员产生的BUG啦。也符合上述的考核逻辑。

1.2.技术点思路

第一步：单元测试

很多开发人员没有写过单元测试，究其原因是团队太小，没有完整的开发流程，看得是结果，中间过程能省的就省了。殊不知，编写单元测试不仅有利于你理解产品的需求而且方便今后的代码维护。所以，单元测试编写的覆盖率可以作为考虑一个开发人员是否有良好编写规范的一个重要指标。

第二步：代码质量

提交代码多的程序猿不一定是一个好的程序猿，但是提交代码量少的一定不是好的程序猿。他的提交代码量跟任务量是有关联的。可以根据他一个迭代周期『代码量/提交次数』来分析出代码质量。当然，这是一个粗略的数值。最终加上研发组组长的定期Review可以很好的来衡量他的代码质量。

2.晋级篇

2.1.专利

其实，很多程序猿很苦逼的。有一大部分是在十几或者几十人的小的互联网公司。说是互联网公司，可能就是当地的一家做网络平台的代理商而已。根本没有什么研发能力的，公司层面也只是为了赚钱，并没有把企业的软实力作为一种核心竞争力来打造。不过，对于北上广的网络公司而言，是比较注重专利的申请。

开发人员跳槽往往最有价值的是工作经验。但是，这个并不会让你的职业生涯有质的变化，在这家是开发人员到了那家还是开发人员，可能薪水比那家拿的多了一些。如果有『专利发明人』的头衔那就不一样了。第一：他是可量化的；第二：它是开发人员的职业里程碑。开发人员往往只关注如何做事儿，却很少思考如何做成一件事儿。而专利其实就是开发人员职业上升的一个重要标志。所以，在做好8小时工作外，要思考如何从工作中提取专利技术。这个将来对你做技术管理岗位还是架构师都有非常大的帮助。

2.2.发布文章

一个好的开发人员不仅天天在网上查找资料，也会将自己的开发经验分享出去。现在很多公司都在使用开源软件。所以，很多研发团队都有开源精神。博客是一种非常好的分享方式，但是这并不能让一个开发人员有更好的成就感。所以，可以选择一些权威的杂志或者专栏投稿。已经采用这对于你来说是一个非常了不得的成就。两条路：1.要不坚持写博客，写多了整理成书；2.要不就向权威的杂志投稿。

本文出自：http://blog.jiangbianwanghai.com/2016/02/23/how-to-solve-the-problem-of-unable-to-quantify-in-developers-work/