据江边望海了解很多互联网公司都会执行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.技术点思路
第一步：单元测试
1.3.待定
预留
2.晋级篇
2.1.专利
预留
2.2.发布文章
预留