来这个公司实习已经半年多了，在年前经历了一次年终考核，最终对我的工作的评级是 C（及格-符合当前职位的工作），让我不禁思考自己在项目中的一些工作的问题，为什么我是C？是我做的不够好吗？或者说在哪里做的不够好？
从考核流程来看，基本上是 CTO 与 Team Leader 对团队成员的「年终总结与次年工作计划」进行Rank，个人狭义的认为「考核」的主要支持材料就是这个总结了。
他山之石
其他公司是怎么考核的呢？说实话我也不太清楚，刚入行，只能通过搜索了解，在网上了解到有以下几种：发精品博客、发论文、开源项目、出书、技术分享大会、技术公众号/微博/知乎 等，这一类绩效方式是通过推广自己的技术来提升公司在行业中声望。如Element、Qcon等。
其他类型的我就没看到了，很明显，这类考核仅适合大公司或者高层次技术人员的考核，或者说，我自己是不具备相关条件的。
对于我个人，由于是实习生，很多知识点还不算熟练，半年来也就是「积极完成产品的需求，以及1~2天一次的高频率的发布，跟进线上日志，平时会整理一些项目的文档，和其他部门的人沟通一些业务等」，看上去平平淡淡，中庸到我自己都会给自己打 「C Rank」了，但是这也就是一个技术人员的真实工作情况，我 leader 也在感叹如何获取更好的绩效，毕竟我参加的项目是一个已经运行了 8~9 年的一个老项目了，平时的工作要求也真的只是完成产品的需求，不容易产生「突出」的工作成果，那么我该怎么去做来打破这一困局呢？
考核量化？
反对对技术人员的过分量化管理，为了“指标”容易脱离产品，不利于开发效率，也不利于真正提升产品质量。比如：为了追求低异常率，而花费大量的时间资源进行测试，会降低项目迭代速度，最终影响项目进度，而某些产品正需要快速迭代。
考核的缺陷
首先来思考一下这样考核的缺陷
对技术人员的考核一般是体现就是在他的产品上，相较于研发部门，业务开发的部门的程序员可能更不容易突出自己的工作，举个例子来说，业务开发人员的工作内容可能就只有一种「完成A需求，B需求，C需求……」。而研发部门更容易突出自己的成果，如「 反垃圾、对XX进行深度学习、精准推荐……」 ,并且即使业务开发人员说他完成了XX等功能模块的开发，但考核时并不会把这一项归功到程序员上，而是会把这个工作更多的归功到设计这一功能的产品身上，所以对于纯粹做业务开发的程序员来说，并不容易在整个产品技术部门的考核中占据优势。
