1. 程式人生 > >程式設計師考核的五大死因(上)

程式設計師考核的五大死因(上)

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

典型的程式設計師考核的產生

分析考核死因之前,我們先看下它是如何出生的。某天,公司老闆突然想到件事——我不懂研發,而研發對我公司這麼重要,怎麼辦?念一及此,老闆不禁有些緊張,馬上叫來HR開會,安排本月人力資源部分的工作重點,那就是研發人員考核,務必貫徹到位、立即執行。深諳老闆意圖的HR,回工位立刻上網賣書,從如何考核、

KPI實務到平穩計分卡策略一應俱全,書到手之後連夜抄書趕製考核體系,整理出研發人員考核方法。第二天,HR把此考核方法交給研發總監並告知老闆要考核你們,這是考核辦法。具體指標和KPI請部門自己制定,本週未之前報給人力資源部。我們會彙報給總裁。研發總監拿著連撰寫制度的人都沒明白的辦法找到專案經理:老闆要考核我們,這是考核辦法。你團隊成員具體指標和KPI你自己定,明天下班之前彙總給我。專案經理找到了程式設計師:老闆要考核你,這是考核辦法。你自己的指標和KPI你自己定,今天中午之前給我。程式設計師迷惑地問:目標不是公司制定的嗎?

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

很快考核變成了每月專案經理給組裡的程式設計師打次分。

於是,老闆很滿意:我終於可以放鬆了,以後我們靠考核制度管理研發人員。我們從此擺脫了人治時代!

HR也很滿意:我不用明白研發是什麼,更不必瞭解程式。我只要他們知道,我可以扣他們的錢就行了,還是用他們自己制定的指標。

其他人都不太滿意……

不久之後,公司就會發生程式設計師離職率升高的現象。被考核者,諸如:程式設計師、專案經理、研發總監都走光之後,考核就這麼死了!

接下來,談談程式設計師考核的五種死因及對策。

考核只以事件為核心

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

有些程式設計師自號“IT民工與這種考核體系的存在有很大關係。

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

專家支招:

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

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

(本文刊登於20099月號《程式設計師》雜誌)

Leo(張大志)

QQ:121685828