程序員考核的五大死因(上)
程序員作為企業開發力量的最核心資產,無疑得到公司從上至下的一致關注。開發是個智力密集型產業,程序開發的特點是,付出相同時間的情況下,兩個開發者之間的產能會相差十幾甚至幾十倍。軟件開發人員向來以“不容易考核、工作不容易被量化”而著稱。本期,我們重點分析程序員考核的“死因”及對策。
典型的程序員考核的產生
分析考核死因之前,我們先看下它是如何出生的。某天,公司老板突然想到件事——我不懂研發,而研發對我公司這么重要,怎么辦?念一及此,老板不禁有些緊張,馬上叫來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%及格線了,但是種樹這個任務卻沒有完成。所以對于只以事件為核心的考核來說,不僅讓程序員感覺不到團隊,而且程序員也不會為團隊考慮。在這種情況下,考核就要調整為既包含個人要完成的事件,也要體現個人對團隊全局的理解。
程序員考核的五大死因(下)
上次談到《程序員考核的五大死因(上)》今天我們繼續。
考核標準的一相情愿
第二個導致考核死亡的原因是,相關方法的制定、標準的出臺都只以公司角度為惟一視角,一切服從項目需要、服從公司需要,絕少考核其它因素。所有考核指標都由公司來定,不讓程序員參與意見。我就見過這樣的開發計劃:項目組成員工作12小時兩班倒,7*24小時、持續長達3個月、沒有Buffer。按這樣的項目計劃考核,除了能直接導致人員流失之外,沒看出來有其它功用。
很多程序員是在被扣工資之后才被相關人員告知自己的考核指標,之前根本沒有人通知。考核時的閉門造車的情況并不少見。
專家支招:
張大志(Leo):加強溝通,讓程序員在考核開始之前了解自己的指標,是惟一克服此種死法的工具。公司怕與程序員就考核指標進行后,指標有貫徹不下去的風險。但考核失敗的代價要遠遠大于對考核指標進行合理修改的代價。程序員如果離職,那很多事情都要重新來過。
胡爭輝:在制訂考核指標時,要始終貫穿考核的杠桿作用,也就是通過給員工制訂影響切身利益的考核指標,讓員工重視這些考核點,進而推動項目的完成,保障公司的利益。既然考核起到用小利益推動大利益這樣一個杠桿作用,那么就不僅要讓員工理解考核的指標,更要讓員工在開始工作之前就要對能不能完成考核指標給出反饋。
考核制度的不合理性
很多考核刻板而沒有彈性,讓人感覺只是為了扣工資而制定的。常能開到程序員通宵加班,第二天凌晨離開公司回家睡覺,中午到公司繼續工作。發工資的時候發現,扣了半天的錢,因為有半天不在公司。程序員會想:“那我通宵也沒給加班費啊!太不公平了!”
考核制度沒有彈性只能傷害程序員的積極性。
專家支招:
張大志(Leo):如同公司市場政策僵化會導致公司的失敗,考核制度的僵化會導致制度本身的名存實亡。永遠記住我們考核的是人而非機會,保持適當的彈性。
?胡爭輝:考核制度不僅有引導員工完成公司既定目標的職能,而且還有體現企業文化的職能,在企業文化中對一件事情只有一種觀念,而不會有互相沖突的兩種觀念。例如提倡加班的公司就不會提倡按時上下班,反之亦然。但是企業文化中也不會在提倡一個觀念的同時,明確的反對另一個觀念。比如說公司提倡按時上下班的時候,不會明確反對加班。所以考核制度難免和企業文化有沖突,這種情況在公司的HR新上任的時候尤為突出,因此HR在上任伊始,不僅要學習企業文化中提倡的觀念,也要理解企業文化沒有明確反對的那些觀念,進而通過考核制度體現出來,讓考核制度成為落實企業文化的有力工具。
考核制度的虛無性
國人常講“王子犯法與庶民同罪”,但程序員考核面前大多數情況下卻很難做到人人平等。評分者看好的,往往考核松些;無門無派的考核相對客觀,與評分者關系緊張的一般都是最低分。意思很明,就是為了擠兌你走呢。考核于是成了政治斗爭的工具,成了打壓異己的手段。
專家支招:
張大志(Leo):有效設立方監督機制、360度考評、輪換考評者是解決以上問題,避免考核成為斗爭工具的方法。也許有人的地方就有斗爭,但是程序員考核仍然應以客觀、公正為標準。
胡爭輝:為了避免考核的主觀和隨意,應當建立自評分與考評分相結合的制度,不僅要由考評者打分,也要由被考核的員工自己打分,對于這兩個打分有顯著差異的時候建立復審制度,由更高級的管理人員對考評結果組織仲裁,仲裁小組應當包括高級管理人員、HR以及在考核周期內與被考核的員工有工作關聯的其他員工組成,通過這樣的流程不僅可以避免考核的主觀和隨意,還可以籍此改進考核制度。
考核中HR常勝不敗
考核要有監督機制,但并不需要一個婆婆式的人物在背后指手劃腳。很多程序員考核中HR都充當著這類不光彩的角色。不了解研發的HR制定出來的考核制度,可行性必然不高。與此同時,一旦有程序員因為滿考核而離職,HR會馬上拋出自己的理論:“此程序員不適合我們的企業文化,他還不擅長溝通。”即使走的是項目骨干,HR還是拿出這套說詞,很讓人汗顏。
一個非理性的群體里很難容下理性的程序員,離開可能是最好的方法。
專家支招:
張大志(Leo):開放的心態是做好HR的前提,考核的時候人力資源部的同事不應該把自己當神,這里不需要神,而應該把自己的角色定位于用心理解程序員的朋友。
胡爭輝:作為一個完善的考核制度而言,不僅應當由HR部門組織對員工的考核,也應當有對HR部門的“考核制度”的考核。這種考核應當以員工滿意度為指標。比如說一項考核指標遭遇大部分員工表示不滿的時候,就需要對此進行調整。不合理的考核如果長期得不到改善,會有越來越多的員工抱者“法不責眾”的心理對待這項考核,長期以往,還會影響到考核制度的嚴肅性。
以上,就是程序員考核的五種常見死法和對策。下次,我們來談談“如何讓程序員渴望被考核”。