從業近8年，從最開始的coding到teamleader，一路走來，見識了各種績效考覈，也經歷了很多沒有對技術團隊進行考覈的公司，一直在思考技術開發這種很難量化的工種如何客觀、可執行有激勵的進行績效考覈，也做了一些嘗試，可謂各種辛酸冷暖自知。
下面將之前一個技術團隊在工作中只爲業務開發服務，只關注功能而忽略業務功能之外的性能，項目任務緊成了代碼潦草結構隨意和混亂的藉口等諸多問題，從而制定了更具有針對性的考覈辦法，以考覈促改變，針對考覈結果出臺相應的獎罰措施。
首先對良好的代碼結構和規範進行培訓，讓大家瞭解什麼樣的代碼纔是優秀的，工作中應該怎麼改良等。爲此將程序性能指標寫進考覈辦法，主要包括:
1、按照請求響應的耗時制定規則要求，要求執行耗時在3秒以上的請求扣分處理；
2、線上程序的嚴重bug導致宕機崩潰扣分處理；
3、代碼結構嚴謹、條理清晰等加分處理(先培訓，給出範例)；
4、主動進行技術分享加分處理；
5、程序算法優化性能改良加分處理，反之則扣分；
並且在制度上將codeReview寫進去，定期組織大家進行review自己的代碼。
當然出現此等問題，除了在制度考覈上做更要針對性的要求之外，在公司層面上要對技術更加重視，不能只關注業務需求而忽略性能要求，在項目進度緊張的時候也要嚴格要求自己。同時結合OKR的思想，給大家指出努力和改進的方向。
當然這樣的考覈是針對特定時期特定的團隊而進行的，試行4個月有改進，但也存在明顯的不足，如對創新的鼓勵不足，因爲限制的太具體而顯死板，大家只關注了這些顯性的約束和要求，而對其他更有利於團隊和個人發展的東西關注度不夠，經過一段時間之後侷限性也顯現了出來。所以經過反覆思考， 沒有完全完美無缺的考覈機制，任何一種機制都是針對特定時期特定的團隊來靈活制定，吸納優秀的思想，如OKR，但是也不能照搬一模一樣的去做，能引導團隊往前走、激勵和引導爲主，適合自己團隊的考覈機制纔是好機制。