程序員作為企業開發力量的最核心資產，無疑得到公司從上至下的一致關注。開發是個智力密集型產業，程序開發的特點是，付出相同時間的情況下，兩個開發者之間的產能會相差十幾甚至幾十倍。軟件開發人員向來以“不容易考核、工作不容易被量化”而著稱。本期，我們重點分析程序員考核的“死因”及對策。

典型的程序員考核的產生

分析考核死因之前，我們先看下它是如何出生的。某天，公司老板突然想到件事——我不懂研發，而研發對我公司這么重要，怎么辦？念一及此，老板不禁有些緊張，馬上叫來HR開會，安排本月人力資源部分的工作重點，那就是“研發人員考核”，務必貫徹到位、立即執行。深諳老板意圖的HR，回工位立刻上網賣書，從如何考核、KPI實務到平穩計分卡策略一應俱全，書到手之后連夜“抄書”趕制考核體系，整理出“研發人員考核方法”。第二天，HR把此考核方法交給研發總監并告知“老板要考核你們，這是考核辦法。具體指標和KPI請部門自己制定，本周未之前報給人力資源部。我們會匯報給總裁。”研發總監拿著連撰寫制度的人都沒明白的“辦法”找到項目經理：“老板要考核我們，這是考核辦法。你團隊成員具體指標和KPI你自己定，明天下班之前匯總給我。”項目經理找到了程序員：“老板要考核你，這是考核辦法。你自己的指標和KPI你自己定，今天中午之前給我。”程序員迷惑地問：“目標不是公司制定的嗎？”

很多考核就這么荒唐的開始了……

很快考核變成了每月項目經理給組里的程序員打次分。

于是，老板很滿意：“我終于可以放松了，以后我們靠考核制度管理研發人員。我們從此擺脫了‘人治’時代！”

HR也很滿意：“我不用明白研發是什么，更不必了解程序。我只要他們知道，我可以扣他們的錢就行了，還是用他們自己制定的指標。”

其他人都不太滿意……

不久之后，公司就會發生程序員離職率升高的現象。被考核者，諸如：程序員、項目經理、研發總監都走光之后，考核就這么死了！

?

接下來，談談程序員考核的五種死因及對策。

考核只以事件為核心

公司沒有利潤就不能生存，研發項目的進度很多時候決定著公司的利潤。所以很多考核是把項目無限拆分到程序員層面，這樣的考核只以事件為中心，關注事件是否做成，而不關注人和人的發展。只以事為中心的考核把程序員當成了生產線上的機器，有投入（高工資）就要有產出（高質量的代碼），程序員被當成了標準件，即沒必要有太多成長（因為做的都是相對重復的工作），也不能時常發生故障（經常加班也不能請假）。

有些程序員自號“IT民工”與這種考核體系的存在有很大關系。

這種考核體系可以維持短期內的高效率，長期執行會導致整個系統的崩潰。很多公司人員不斷更替，根本無穩定可言，一部分原因是執行了或者實質上執行了只以事件為核心的考核。

專家支招：

張大志（Leo）：承認程序員也是人，尊重人的個性是考核的基礎。注重培訓，在項目壓力大時側重結果，在有Buffer的情況下關注程序員技能的提高和個人的發展是解決此類似問題的核心方法。在項目周期的不同階段對考核方法進行調整的復合式考核方式，更能讓企業向目標前進，也能保持程序員的熱情。

胡爭輝：換個角度從結果考慮，舉一個最常見的例子，四個人合作種樹，A挖坑，B種樹，C填土，D澆水。如果考核只以事件為核心的話，那么當B沒有種樹時，C依舊填土，D依舊澆水。從考核來說A、C、D三個人都得了滿分，就算B得了0分，平均分也該有75%，超過60%及格線了，但是種樹這個任務卻沒有完成。所以對于只以事件為核心的考核來說，不僅讓程序員感覺不到團隊，而且程序員也不會為團隊考慮。在這種情況下，考核就要調整為既包含個人要完成的事件，也要體現個人對團隊全局的理解。

（本文刊登于2009年9月號《程序員》雜志）

總結

以上是生活随笔為你收集整理的程序员考核的五大死因（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。