Categories
程式開發

要么“被離職”要么幾十萬年終獎,程序員的年度績效怎樣做才公正?


年底了,各企業年度績效都做完了,未來還能撐得下去的企業都開始發年終獎了。

前些天,騰訊發年度終獎的消息爆屏了。先是騰訊雲的陽光普照獎,人手一台iPhone 11 Pro,總獎金超過三千萬。

而後據稱微信支付團隊拿到了騰訊2019年的公司創始人獎,獎勵微信支付團隊2億,按照一千人算,一人20萬。這2億還不算是年終獎,有消息稱微信支付團隊的年終獎都是10個月工資起算。

要么“被離職”要么幾十萬年終獎,程序員的年度績效怎樣做才公正? 1

(這是一張老闆們不想看到的截圖)

互聯網企業的年終獎

互聯網頭部企業錢多,年終獎往往豐厚得讓人秒變檸檬精。

阿里今年在香港再次上市,不知道獎金是否會變多,據阿里員工反映,他們還在走績效流程。按照慣例,會在4月份發放年終獎。普通程序員一般可拿到4-9個月的獎金,那麼稅前至少是10-25萬。

今年是百度成立20年,但主打的AI佈局也很需要現金流的支撐,目前還沒有拿多少年終獎的確切消息。百度在2019年改為全年15薪,脈脈上有人反映今年拿了4個月的年終獎,按照百度工資計算,這個數比起其他大廠略少。

華為的年終獎最豐厚,據華為內部人說,華為人的收入三分之一靠工資,三分之一靠股票,三分之一靠年終獎。其中股票和年終獎,各級領導的話語權比較大。一般員工年終獎都能拿到2、30萬。

要么“被離職”要么幾十萬年終獎,程序員的年度績效怎樣做才公正? 2

不過華為雖然獎金多,但是個體差別也很大。這位內部人士舉例:“比如前些年18級左右的員工,如果績效打A會給60萬;如果績效打B就只有一半,30萬,相差會有小幾十萬;績效拿C的話,一年就白乾了“。真真正正的用“薪”激勵啊。

以低績效為名的“裁員”

除了根據績效來發年終獎,還有企業根據績效結果來“裁員”。我們看到有一則求助:

某BAT頭部企業的老員工了,今天跟HR聊了,HR總體意思是:你的績效不是很符合預期,這個是你個人能力有問題,你必須相信這一點。你抓緊時間找工作吧,我們可以推薦獵頭,我們沒有裁員,不會有賠償。好慌,求助。

被離職不賠償,這可以解讀為以績效為名被PUA了嗎?

BAT和華為等幾家公司的績效管理都有個特點,就是都有10%左右的最低檔績效,還有的是要求強制分佈

對於中基層的員工,百度和騰訊都是按照五檔打分,都會有10%在最低檔。阿里的中基層員工整體打分按照3-6-1比例進行強制分佈,即30%為“最好”,60%為“一般”,10%為“較差”。特別的是“價值觀”導向,價值觀佔據50%。阿里2019年推出“新六脈神劍”,價值觀方面有20個選項,績效考核更為複雜。

華為的年終績效考評,分為A、B+、B、C幾個檔次,80%的人都是B或B+,C檔最低,比例為5%-10%且要求強制分佈。他們的考核最為獨特,要根據投票來評定。比如CT(績效評定團隊)投票,一般三票左右,直接主管佔據一票,評定完了後交由AT(行政管理團隊)复核。

雖然在很多企業裡,背最低檔不意味著“必須離職”,但是也免不了有企業會拿業績之外的東西去評定一些員工,進行“人員淘汰”。

當我看到某HR 這樣說一名老員工——“他今天要不自己離開,未來一年也一定會因為績效問題被公司開了”的時候,我感到了在這HR 考評背後一股非常強的暗流和不可見的力量讓她幹出了這樣一件匪夷所思的事。

——技術人的“績效考核” 陳皓(左耳朵耗子)

程序員的績效怎麼考核

要么”被裁員“要么獎金相差小幾十萬,這些都要靠年終績效來決定。那麼如何用績效來評斷程序員的工作呢?尤其是如果這家公司還是一家小公司,是不是就更難了?

在InfoQ的一次活動上,有人提出這樣的問題:”我目前帶40 人的研發團隊,正在考慮考核問題,我分了三部分:第一部分仍然保持主觀打分,第二部分是量化的東西(Bug ),第三部分是額外的工作。請問這種量化是正確的嗎?“

在考評中加入可量化的指標來考核一名程序員確實是可以做到更公平公正,但是以Bug數來評定,這就有些”狗血“了吧。歷史上我們也是見證過好幾種“程序員工作成績”衡量指標的,比如Bug、代碼行、提交次數等等,這些科學嗎?

以代碼行為例,代碼行大約有 70% 是噪音,比如空行、評論等。而且編程語言之間的差異也大,比如在 CSS 文件中編寫的一行代碼與在 Java 文件中編寫的一行代碼的工作量有很大的不同。因此,根據這個指標,“最有價值的開發人員”往往是添加最多 CSS、空白和第三方庫的人。

再說提交計數。從概念上講,提交只不過是開發人員工作過程中的一個“保存點”。程序員多久會保存一次他們的工作要看個人喜好。如果你使用“提交計數”作為指標來考核開發人員,那麼你實際上是鼓勵他們培養一種個人偏好,寫完一行代碼就提交。

偏差較小的衡量應該是將多個指標放到一起使用:

  • 需求交付時間(Lead time]:從創意到交付軟件需要多長時間。
  • 週期時間(cycle time):對軟件系統進行更改並將該更改投入生產環境需要多長時間。
  • 團隊速率(team velocity):團隊通常在一個迭代(或叫做Sprint)中,完成多少個“單位”數量的軟件。
  • 缺陷開/閉率(Open/Close ):在特定時間段內,報告和關閉的生產問題數量。總體趨勢比具體數字更重要。
  • 應用的崩潰率(application crash rate):應用程序崩潰的次數除以使用次數。

留住老程序員

G是一位老程序員,經歷過十幾次的績效評估。對於這些評估,他吐槽說很大一部分感覺結果並不公平,也數次因為不滿績效考核而選擇離職。評判經驗豐富的老程序員的工作,更要讓大家“心服口服”。

對軟件工作進行評估難免在某些部分會產生偏差。消除偏差的方式,可以利用複核評議,用面談進行解決。面談之前雙方需要收集足夠多的信息,用來糾正“遺漏”或“片面”的評價:

  • 1 v 1會議記錄。
  • 程序員在參與的項目中負責了哪些功能,難度如何?
  • 產生的輸出:代碼,文檔,電子郵件。
  • 收到的反饋:同行反饋,通過電子郵件或其他方式收到的感謝,以及能找到的其他反饋。
  • 給出的反饋:代碼審查、計劃文檔審查、與他人的交互。

此外复核評議也是保持兩者之間信任的關鍵。特別被打”低績效“或面臨“被離職”時候的面談,這一環節也最容易出事兒或“上新聞”,如果公司的”解釋權“使用不恰當的話。

“如果事情有可能變壞,它就遲早會變壞。”——墨菲定律

墨菲定律總是給我們無情的打擊。軟件研發的績效管理是如此之難,其副作用是如此之多,以至於很多時候為了處理問題我們已經耗費了大多數精力。怎麼在這種複雜環境中應用好績效管理,避免副作用,讓績效管理真正能激發員工激情,推動組織創新,成為公司績效的發動機?這是值得深思的問題。

結束語

作為程序員的你,今年的年終獎發了嗎?獎金高的話說出來讓大家酸一酸?

你有沒有因為什麼Bug使你的績效受到影響?

你認為你的年終績效結果,老闆打的分數合適嗎?不合適也歡迎在評論區留言吐槽!