今天一個朋友問我程序員應該怎麼考覈。我想了想，總結了下我理解中一般開發人員的績效考覈。
考覈的意義
首先一個前提是，考覈是手段不是目的。我一直覺得對一個團隊來講，有兩個基本目標：一個是完成自己承擔的工作任務，一個是提升整個團隊的能力。這兩個目標相互促進，進而實現螺旋式的上升發展。考覈只是爲了更好的瞭解工作情況和團隊情況、更清晰更準確的認識剖析自我，爲改進和提升做準備的技術手段。
所以開發人員的考覈對團隊來說，有兩層意義：既是團隊成員的績效獎金榮譽的一個數據支持，也是團隊整體建設進一步發展的依據。
對個人來說，也有兩個意義：橫向可以與團隊內其他成員做對比看到差距繼續努力，縱向也可以跟自己的不同時間段做對比看到進步的足跡。
從設計上講，考覈應該跟公司的職級職位序列和績效獎金等制度掛鉤，不同的層次、不同的崗位，應該有一些不同的要求和考覈方式，最終把考覈的結果通過某些獎懲形式實施下來。沒有獎懲激勵的考覈，只是紙上談兵的空洞形式。
考覈的原則
程序員的考覈一般可以從研發管理過程、項目與部門效益、公司考勤制度、主觀考覈評價指標等組成。因爲程序員經常無償加班（沒辦法，難道不是事實麼？），公司考勤之類的制度應該不怎麼用得到程序員的頭上，剩下的主要也就是過程、效益和評價了。
考覈的原則我覺得有如下幾個：
1. 主客觀相結合
一般來說，我們希望可靠本身越客觀越好。但是制定指標收集客觀數據，分析整理，對於IT研發過程來說，都是很複雜的事情。特別是研發本身不規範，技術能力差，不成熟的團隊，變數大、流程不標準，很多事情難以度量。主觀的一些東西就不可避免。但是，主觀的考覈應該儘量少，避免出現團隊中任人唯親之類的影響團隊整體的現象。
2. 合理量化
對於研發過程中的可以度量的數據，應該儘量合理的量化。度量的過粗，大家都差不多，效果不明顯；度量的過細，對收集指標數據要求比較高，甚至對研發本身會產生一定的影響。所以，指標的量化應該結合實際的研發流程，做出比較經濟的選擇。
3. 雙向和多向評價
對於上級對下級可以直接給予評價的行爲，下級應該也能集體給上級打分。對於主觀考覈部分，應該做到360度測評，對某個開發人員的評價，可以先由開發人員自己給自己的主觀評價部分打分，再由主管、團隊內同事review評價，綜合確定最終評價。
4. 要研發過程還是業務結果？
考覈程序員的側重點應該放在過程上，而不是業務的結果上。業務的結果應該由管理業務的人負責。簡單的說，誰拍板誰負責（或誰受益誰負責）。所以，我一直覺得苦逼的程序員應該對自己的勞動本身負責。程序員在自己的一畝三分地做好工作，寫得好代碼，改得快bug，產出多，質量高，就是一個好程序員。當然對技術leader、architect的要求要放高一些。當然，業務的好壞一般關聯到公司和部門的performance，這可是獎金和績效的來源，理所當然跟程序員有關係，但不應該是考覈的核心。對一個好的馬龍（一般程序員，不上升到某種所謂的高度）來說，研發的本職工作纔是作爲一個程序員的核心價值。這也正是前面說到的不同的職位不同序列應該有不同的要求和考覈方式。
5. 發展階段與側重點
當然，公司或團隊本身的發展階段，也決定了對程序員考覈的側重點不同。
對於一個能力一般偏下、經常延期、積累差、不規範、處以還沒有實現溫飽的團隊，考覈的重點應該是提升團隊研發能力，按時完成任務。
對於一個馬馬虎虎按時完成任務，但是不規範、沒合作精神、沒動力的團隊，考覈的重點應該是引導其行爲，走向規範化，實現團隊協作性的整體提升。
對於一個有一定的積累，相對能力還不錯，已經能很好的完成工作任何的團隊，考覈的重點應該是如何進一步的提高研發水平和質量，實現標準化和流程化…….
指標的制定
具體怎麼制定考覈指標，我就只說說思路吧。
1、 研發過程
參與了多少項目，寫了多少代碼和文檔，多少測試代碼，完成多少模塊和用例，解決了多少問題，bug率多少，reopen的bug率多少，多少次工作交付延期，多少次工作失誤，內部做了多少次技術交流分享。。。等等在研發過程中的工作度量
2、 業務結果
參與的項目給公司帶來多少收益，個人工作部分分別佔總任務量的比重，計算出來個人給公司帶來多少收入。。。參考部門的績效和平均每人的績效水平
3、 制度考勤
遲到早退啦，請假曠工啦，等等
4、 主觀評價
同級的同事對其評價，上級領導的評價，工作態度，團隊精神，技術水平，創新精神，主動性，責任心等等。
類似這些，結合你們的實際情況看哪些數據可以作爲考覈的指標。然後再分別量化到一定的粒度。接着確定每個指標的比重，怎麼統計彙總。最後做一個考覈制度文檔。
考覈的執行
有了考覈標準和方式以後，就剩下執行了。執行的力度決定了考覈制度是不是能起到作用。如果執行得好的話，可以邊執行，邊收集數據，改進考覈方式。沒有強有力的推動，不斷的收集數據、check && review，考覈就會僅僅流於形式了。