居然有62%的HR不約而同的提到了一個問題：研發部門的績效考核該怎麼搞定！？
想要回答這個問題難度不小， 但畢竟是用戶的需求與心聲，
1、如果期待這一篇文章解決你們公司所有的考核難題， 那出門請左轉；
2、別人花幾百萬做諮詢項目， 你想免費拿一套走的話， 那參照第一條；
3、本文結合個人在企業的經歷， 有一定個人色彩， 如有不同的看法， 歡迎在評論區指正。
績效考核不適用研發類職位？
鄉親們， 醒醒吧！
每次一看到有人鼓吹幹掉、罷免、取代績效考核， 我總想和他們坐下來好好聊（si）聊（bi）， 能秉持這個觀點的理由到底是啥？
換位思考一下：如果你去開家公司， 就拍著腦袋給員工發獎金麼？還是用人人平等大鍋飯？抑或是你壓根就不發？
說句難聽的， 拍腦袋弄的結果， 那也是績效考核， 只是效果比你瞧不起的那些績效方式方法更差而已；
錯誤觀點一：高科技行業不適合績效考核！
有人會認為， 高科技行業就沒法考核， 績效考核會扼殺創新；那我就問一句：你就算去到美國當教授， 你也得拿出能反映出你水準的教學成果和科研成績吧， 難道這不是績效考核麼？
錯誤觀點二：研發的開發週期太長， 不適合績效考核
還有人認為：研發是一條長線， 可能需要半年或者一年才做才的出來， 所以月度季度的績效考核並不合適。
那我問你：就不能搞點里程碑的成果出來？就不能分解出 一些階段性的成果出來？就算你做的東西實在難度太大， 但總得有個東西能讓大家看到你在進步是不是？如果公司一點都不考核， 就坐那等著幾個人在那裡毫無進展的憋大招， 這種公司你敢進？
觀點三：績效考核是上司擠兌人的工具
有人評價說， 績效考核就是你的領導：說你行你就行， 說你不行行也不行。
確實， 這是一個弊端， 但這個問題貌似在領導本身評價不客觀， 而並不是績效考核本身的問題啊。
沒有規矩， 不成方圓。 讓辛勤工作的貢獻大的員工獲得更多的回報， 讓組織有機制去剔除破壞團隊戰鬥力的不合適的人員，
相比於無法精確量化工作而造成的一些困擾；一個無序的管理環境， 一個你今天幹了活都不知道明天會不會被認可的失控的狀態， 才是真正可怕的東西。
OKR是研發人員的福音和解藥？
這TM就尷尬了
大家仔細回憶一下， 我們這幾年身邊的流行的管理工具， 是不是都在經歷：爭相傳送、大幹快上、淺嘗輒止、偃旗息鼓， 這四個過程。
之前是KPI， 現在輪到了OKR。
作為績效管理界的新寵， OKR的名頭卻非常響亮， 聽起來似乎要勇奪績效考核第一工具的桂冠， 但作為HR， 我們問一下自己， 你所瞭解有哪些企業正在普及OKR？恐怕能說出3-5家已經非常難得了吧。
為何像BAT、華為、聯想、海爾等優質的高科技公司都沒有普及OKR呢， 是他們不知道OKR麼？答案顯然並不是，我想那些優質的企業都沒有普及OKR，有一重要的原因就是：OKR的評價結果不和個人利益直接掛鉤啊。
誰都知道，衡量一家公司好不好，最重要的指標是業績；衡量一個人的價值，最重要的指標是績效考核的結果。這兩者都和金錢有關，但現在OKR卻告訴你不能和金錢相掛鉤。業績做的好不好與我們的的收入都沒什麼影響，那請問老闆圖啥？員工圖啥？難道圖一個老闆畫過的虛無縹緲的餅？
小匯不是想全盤推翻OKR，但是你有沒有發現，OKR這東西其實挺詭異的。
比如說我說今年研發效率提升50%，看上去特別的可度量，但是實際統計口徑最後是我自己出的。換句話說，在OKR考核下，我要做的事其實是“吹個牛逼讓老闆覺得牛逼，並且最後證明我做到了或者做不到”。
所以說，OKR適合是極為自律、自我驅動力極強的團隊。但看看普遍的管理環境，我就TMD尷尬了。
研發類職位的考核
江湖上盛傳的3大流派
關於研發人員的績效考核，經過那麼多企業的試驗、試錯、打臉、實踐、完善，基本可以分為了3大流派，這3大流派並非孤立存在，他們經常交叉與合作，只是3大流派一直在爭奪江湖第一霸主的位置。
一、業績導向派：
這一派人多勢眾，是研發江湖第一大門派。
他們認為研發的產出就是業務結果，業務結果衡量的主要標準就是規模和收入（產品佔有率，產品銷售額），這個流派優點是只看結果，比較受投資人/公司高管的認可。
2、過程導向派：
這一派最近幾年也是發展迅速，他們很大一部分成員是從業績導向派投靠而來。
3、產品至上派：
這一派供奉約伯斯為祖師爺，目前在三大派中人數最少，但大多都有情懷。
這一派的產出這塊的判斷往往憑藉主觀感受，但也因為有著強烈個人審美和產品感覺，一旦方向走對了，就甩前兩大幫派一條街，這個門派裡的長老就變得至關重要。
3大流派各有優劣，江湖人士紛爭不休。
不管怎麼爭論，3種流派都有一個致命的缺陷，也是研發考核的致命缺陷是：一旦完全嚴格量化考核，聰明的開發人員都會找到各種方法來規避指標體系本身的漏洞。
所以說，沒有一個考核流派是完美的，我們只能取當中最適合自己的。
3大門派進行指標設計
容易遺忘哪些重要指標
談到研發類指標設計，HR都是一臉的愁容，常規的研發人員績效考核的指標HR都懂。
小匯來總結一下那些不怎麼被重視，卻很重要的指標：
一：要保證有品質地產出，去支撐業務需求的指標
研發部門要回應業務的需求，在回應的過程中，回應的品質是至關重要的，如果回應後做出來的是辣雞，那回應有個P用！？
快速保證品質地支撐業務需求，研發品質指標就很關鍵，比如：
業務需求響度
系統可用性
開發關鍵流程完成度
需求影響度：結合月度計畫與月度計畫的完成度，看研發的產出是否與業務是直行對齊的（或是落後的）。
系統可用性：挑選業務流程的關鍵路徑，涉及影響這裡的故障的都算作影響系統可用性。
開發關鍵流程完成度：通過資料度量來反推關鍵流程的執行品質， 例如：轉測試，發佈回退這些；
有了這三點，才能說研發人員的的產出是支撐了業務的發展，否則研發部門就等於是關上門自己自嗨。
二：要有預見及應付變化的指標項
在考核過程中，很多企業都選擇依據過往經驗判斷所設定的，結果性指標。
但實際隨著業務快速發展，團隊成員也需要成長，所以每年都需要一些有預見性能夠應付未來變化的考核項。這樣以便於團隊成員更快更好的成長。
這類指標大致可分為：
1、新技術研究引用：主要通過業務需求多少使用新技術占比度量
2、突破創新型優化，主要通過產品功能的突破與創新，來節省公司成本
3、模組重構，性能優化形專案、可以通過單機壓測值來度量
三：大型跨部門專案的完成度
大型專案需要跨組聯調的很多，但如果不在各自KPI項目裡面，其實有時候會比較難推動，所以HR在設計指標的時候，需要增加這麼一向。
對於大型專案，Review的過程也可以發現KPI目標的制定是否有可度量的方式，如果不行，那需要再次細化KPI，避免出現最後核算的時候，確認不了是否能完成。
所以說，在給研發團隊做指標的時候，千萬不要只是跟著產品走，還要看回應、看品質、看發展、看合作。
研發類職位考核最大坑
強行量化！
研發人員量化難度大，所以很多小夥伴會選擇強行去量化，這樣做其實對研發人員非常不友好，研發人員會認為HR故意找茬。
研發人員的品質考核分為以下三部分：
代碼品質：代碼本身的品質決定了對後續開發的友好程度
研發品質：研發階段產生的bug
運維品質：產品上線以後的故障情況和資源消耗情況
第一類，很難量化，小匯的建議是不要去量化，一旦量化內部撕逼會很嚴重，這一項可以只作為努力提高的方向和主觀考核依據。
第二類，做研發的小夥都知道，很難用bug數量來衡量研發品質，建議讓研發人員給HR列一張Bug等級表，嚴重Bug當然要扣分，無關緊要的Bug你扣分就過分了。
第三類，這是可以完全量化的，通過線上伺服器消耗、故障恢復時長等來做考核，這種考核的優點同樣是投資人和老闆看得見，不需要擔心指定的KPI偏離了大方向。
總之，小匯給研發人員做過考核的經驗就一句話：寧肯用主觀評價，也不要引入錯誤的量化指標。
Q＆A：
1、研發人員績效考核要不要引入態度考核？
答：很有必要，工作態度和責任心，思維能力這些可能更加難以量化，但是對於研發人員考核卻很重要。開發團隊強調的是自我主動，自我管理，完全強過程下得規範和約束往往並不能發揮團隊最大效率。
2、我們公司規模不大，要不要參考大公司的的考核模式？
答：求你了，別給自己自找麻煩
3、研發人員績效考核方面如果推薦一本書，你會推薦哪一本？
答：還是大師德魯克的《人與績效》
4、我想系統學習績效管理，有沒有推薦的課程？
答：有，《績效設計關鍵實踐》，好評超過98%，超高人氣的課程，課後送工具、送書籍，送課程。
近期安排：2017年7月07-08日，座標上海；2017年9月22-23日，座標成都。
索要課件及相關資料，↙點擊閱讀原文
是他們不知道OKR麼？答案顯然並不是，我想那些優質的企業都沒有普及OKR，有一重要的原因就是：OKR的評價結果不和個人利益直接掛鉤啊。誰都知道，衡量一家公司好不好，最重要的指標是業績；衡量一個人的價值，最重要的指標是績效考核的結果。這兩者都和金錢有關，但現在OKR卻告訴你不能和金錢相掛鉤。業績做的好不好與我們的的收入都沒什麼影響，那請問老闆圖啥？員工圖啥？難道圖一個老闆畫過的虛無縹緲的餅？
小匯不是想全盤推翻OKR，但是你有沒有發現，OKR這東西其實挺詭異的。
比如說我說今年研發效率提升50%，看上去特別的可度量，但是實際統計口徑最後是我自己出的。換句話說，在OKR考核下，我要做的事其實是“吹個牛逼讓老闆覺得牛逼，並且最後證明我做到了或者做不到”。
所以說，OKR適合是極為自律、自我驅動力極強的團隊。但看看普遍的管理環境，我就TMD尷尬了。
研發類職位的考核
江湖上盛傳的3大流派
關於研發人員的績效考核，經過那麼多企業的試驗、試錯、打臉、實踐、完善，基本可以分為了3大流派，這3大流派並非孤立存在，他們經常交叉與合作，只是3大流派一直在爭奪江湖第一霸主的位置。
一、業績導向派：
這一派人多勢眾，是研發江湖第一大門派。
他們認為研發的產出就是業務結果，業務結果衡量的主要標準就是規模和收入（產品佔有率，產品銷售額），這個流派優點是只看結果，比較受投資人/公司高管的認可。
2、過程導向派：
這一派最近幾年也是發展迅速，他們很大一部分成員是從業績導向派投靠而來。
3、產品至上派：
這一派供奉約伯斯為祖師爺，目前在三大派中人數最少，但大多都有情懷。
這一派的產出這塊的判斷往往憑藉主觀感受，但也因為有著強烈個人審美和產品感覺，一旦方向走對了，就甩前兩大幫派一條街，這個門派裡的長老就變得至關重要。
3大流派各有優劣，江湖人士紛爭不休。
不管怎麼爭論，3種流派都有一個致命的缺陷，也是研發考核的致命缺陷是：一旦完全嚴格量化考核，聰明的開發人員都會找到各種方法來規避指標體系本身的漏洞。
所以說，沒有一個考核流派是完美的，我們只能取當中最適合自己的。
3大門派進行指標設計
容易遺忘哪些重要指標
談到研發類指標設計，HR都是一臉的愁容，常規的研發人員績效考核的指標HR都懂。
小匯來總結一下那些不怎麼被重視，卻很重要的指標：
一：要保證有品質地產出，去支撐業務需求的指標
研發部門要回應業務的需求，在回應的過程中，回應的品質是至關重要的，如果回應後做出來的是辣雞，那回應有個P用！？
快速保證品質地支撐業務需求，研發品質指標就很關鍵，比如：
業務需求響度
系統可用性
開發關鍵流程完成度
需求影響度：結合月度計畫與月度計畫的完成度，看研發的產出是否與業務是直行對齊的（或是落後的）。
系統可用性：挑選業務流程的關鍵路徑，涉及影響這裡的故障的都算作影響系統可用性。
開發關鍵流程完成度：通過資料度量來反推關鍵流程的執行品質， 例如：轉測試，發佈回退這些；
有了這三點，才能說研發人員的的產出是支撐了業務的發展，否則研發部門就等於是關上門自己自嗨。
二：要有預見及應付變化的指標項
在考核過程中，很多企業都選擇依據過往經驗判斷所設定的，結果性指標。
但實際隨著業務快速發展，團隊成員也需要成長，所以每年都需要一些有預見性能夠應付未來變化的考核項。這樣以便於團隊成員更快更好的成長。
這類指標大致可分為：
1、新技術研究引用：主要通過業務需求多少使用新技術占比度量
2、突破創新型優化，主要通過產品功能的突破與創新，來節省公司成本
3、模組重構，性能優化形專案、可以通過單機壓測值來度量
三：大型跨部門專案的完成度
大型專案需要跨組聯調的很多，但如果不在各自KPI項目裡面，其實有時候會比較難推動，所以HR在設計指標的時候，需要增加這麼一向。
對於大型專案，Review的過程也可以發現KPI目標的制定是否有可度量的方式，如果不行，那需要再次細化KPI，避免出現最後核算的時候，確認不了是否能完成。
所以說，在給研發團隊做指標的時候，千萬不要只是跟著產品走，還要看回應、看品質、看發展、看合作。
研發類職位考核最大坑
強行量化！
研發人員量化難度大，所以很多小夥伴會選擇強行去量化，這樣做其實對研發人員非常不友好，研發人員會認為HR故意找茬。
研發人員的品質考核分為以下三部分：
代碼品質：代碼本身的品質決定了對後續開發的友好程度
研發品質：研發階段產生的bug
運維品質：產品上線以後的故障情況和資源消耗情況
第一類，很難量化，小匯的建議是不要去量化，一旦量化內部撕逼會很嚴重，這一項可以只作為努力提高的方向和主觀考核依據。
第二類，做研發的小夥都知道，很難用bug數量來衡量研發品質，建議讓研發人員給HR列一張Bug等級表，嚴重Bug當然要扣分，無關緊要的Bug你扣分就過分了。
第三類，這是可以完全量化的，通過線上伺服器消耗、故障恢復時長等來做考核，這種考核的優點同樣是投資人和老闆看得見，不需要擔心指定的KPI偏離了大方向。
總之，小匯給研發人員做過考核的經驗就一句話：寧肯用主觀評價，也不要引入錯誤的量化指標。
Q＆A：
1、研發人員績效考核要不要引入態度考核？
答：很有必要，工作態度和責任心，思維能力這些可能更加難以量化，但是對於研發人員考核卻很重要。開發團隊強調的是自我主動，自我管理，完全強過程下得規範和約束往往並不能發揮團隊最大效率。
2、我們公司規模不大，要不要參考大公司的的考核模式？
答：求你了，別給自己自找麻煩
3、研發人員績效考核方面如果推薦一本書，你會推薦哪一本？
答：還是大師德魯克的《人與績效》
4、我想系統學習績效管理，有沒有推薦的課程？
答：有，《績效設計關鍵實踐》，好評超過98%，超高人氣的課程，課後送工具、送書籍，送課程。
近期安排：2017年7月07-08日，座標上海；2017年9月22-23日，座標成都。
索要課件及相關資料，↙點擊閱讀原文