來這個公司實習已經(jīng)半年多了，在年前經(jīng)歷了一次年終考核，最終對我的工作的評級是 C（及格-符合當前職位的工作），讓我不禁思考自己在項目中的一些工作的問題，為什么我是C？是我做的不夠好嗎？或者說在哪里做的不夠好？
從考核流程來看，基本上是 CTO 與 Team Leader 對團隊成員的「年終總結與次年工作計劃」進行Rank，個人狹義的認為「考核」的主要支持材料就是這個總結了。
他山之石
其他公司是怎么考核的呢？說實話我也不太清楚，剛入行，只能通過搜索了解，在網(wǎng)上了解到有以下幾種：發(fā)精品博客、發(fā)論文、開源項目、出書、技術分享大會、技術公眾號/微博/知乎 等，這一類績效方式是通過推廣自己的技術來提升公司在行業(yè)中聲望。如Element、Qcon等。
其他類型的我就沒看到了，很明顯，這類考核僅適合大公司或者高層次技術人員的考核，或者說，我自己是不具備相關條件的。
對于我個人，由于是實習生，很多知識點還不算熟練，半年來也就是「積極完成產(chǎn)品的需求，以及1~2天一次的高頻率的發(fā)布，跟進線上日志，平時會整理一些項目的文檔，和其他部門的人溝通一些業(yè)務等」，看上去平平淡淡，中庸到我自己都會給自己打 「C Rank」了，但是這也就是一個技術人員的真實工作情況，我 leader 也在感嘆如何獲取更好的績效，畢竟我參加的項目是一個已經(jīng)運行了 8~9 年的一個老項目了，平時的工作要求也真的只是完成產(chǎn)品的需求，不容易產(chǎn)生「突出」的工作成果，那么我該怎么去做來打破這一困局呢？
考核量化？
反對對技術人員的過分量化管理，為了“指標”容易脫離產(chǎn)品，不利于開發(fā)效率，也不利于真正提升產(chǎn)品質(zhì)量。比如：為了追求低異常率，而花費大量的時間資源進行測試，會降低項目迭代速度，最終影響項目進度，而某些產(chǎn)品正需要快速迭代。
考核的缺陷
首先來思考一下這樣考核的缺陷
對技術人員的考核一般是體現(xiàn)就是在他的產(chǎn)品上，相較于研發(fā)部門，業(yè)務開發(fā)的部門的程序員可能更不容易突出自己的工作，舉個例子來說，業(yè)務開發(fā)人員的工作內(nèi)容可能就只有一種「完成A需求，B需求，C需求……」。而研發(fā)部門更容易突出自己的成果，如「 反垃圾、對XX進行深度學習、精準推薦……」 ,并且即使業(yè)務開發(fā)人員說他完成了XX等功能模塊的開發(fā)，但考核時并不會把這一項歸功到程序員上，而是會把這個工作更多的歸功到設計這一功能的產(chǎn)品身上，所以對于純粹做業(yè)務開發(fā)的程序員來說，并不容易在整個產(chǎn)品技術部門的考核中占據(jù)優(yōu)勢。
