今天要寫這篇文章，來自最近有兩個點觸動了我。第一個觸動點是奈飛(netflix)做出了一個巨大動作《“不搞職級、人人平等” 25 年后行不通了？Netflix 破天荒引入細分職級：氣走老員工》，開始進行職級劃分; 第二個觸動點是「DevOps 研發效能群里」討論的效能度量與績效考核。兩者之間的本質都是要給員工分出個三六九等，無論是招聘的時候（職級）還是考核的時候（職級）。我想把我觀察到的一些現象分享給大家。

奈飛(Netflix)職級劃分的根因

首先講講奈飛的職級劃分。當初奈飛為啥沒職級呢？以前 Netfilx 自己錢多舍得給員工。當然招聘的門檻也高，大家的技術水平有保障，平級都正常。現在為啥要進行有職級了呢？要縮減預算，要多招應屆生和資歷經驗較淺的員工降低成本。《奈飛文化手冊》重點強調了“提高人才密度”，現在要改變了么？是的，人力成本太高，迫切希望「新人」加入。2022年注定是不平凡的一年（好像最近幾年都不平凡）。

員工職級、權力與義務

員工職級一旦確定就意味著權力與義務的固定。也就是說，因為公司給予了你「高職級」（薪資待遇福利職位權力），那么具有高職級的人在各個方面都應當起到高職級人員應該承擔的責任。同樣，對于職級比較低的人員，也應當起到「低職級」人員應該承擔的責任。實際工作中，一旦職級劃定，尤其是職級級別較多時，低級別人員的「積極主動」性都會受到打擊，因為每次自己想做得更好的時候，好像都會有一個「高職級不干活」的影子在那里嘲笑你。

一個特別有感觸的場景就是開會，大家「肩膀」一般齊的時候，紛紛各抒己見建言獻策；突然進來兩個大佬，尤其是級別高很多(+2)的時候，大家就會不自覺地保持沉默，直到兩個大佬在那講完有了結論，積極主動的小伙伴無關痛癢的提個問題然后散會，其它人基本全程沉默。他們都覺得他倆職級高水平肯定高決策肯定也好，當然責任也他們來背，我為啥要發言？我不行的（我不背鍋），職級(薪資待遇）不允許我發言。

另外一個特別有感觸的場景是合作。A團隊和B團隊合作一件事，沒有職級的時候，A負責人都是直接找B負責人，倆人聊完確認要合作后，一般都會指定兩個團隊下面的人實際執行。當有了職級，A團隊負責人和B團隊負責人差很多的時候，這時候兩個團隊想合作，一般A團隊都會把自己這條線和B團隊負責人對等的領導拉進來，也許是+1級別，也許是+2級別，或者+3級別。在溝通群里就會發現兩個干活的你一言我一語在討論，N多領導保持沉默。步兵需要炮火支援先去呼喚排長、連長、營長、團長、師長、軍長，再轉到炮司，炮營，炮連。整個過程看似沒毛病，人人都在為過程負責，但沒有一個人愿意為結果負責，都不愿意去承擔后果，結果就是聽得到炮火的人死去，陣地丟失。讓聽得見炮聲的人呼喚炮火，讓炮火直接被聽得見炮聲的人呼喚。

研發效能度量、OKR與績效考核

最近經常和一些業內大佬聊，大佬們很頭疼的問題就是，老板拍板了要做研發效能度量，目標是衡量每個人的產出，研發效能度量的結果要在績效考核上有所體現，即度量效果不好的扣工資。度量效果不好扣工資，OKR沒超預期扣工資，KPI不達標扣工資，好像扣工資是我們激發員工努力工作的唯一途徑。

「年終獎」與「年中獎」

工資是公司根據與員工之間的約定，以貨幣形式對員工的勞動所支付的報酬。一旦很隨意的克扣工資，員工的積極性就會受到打擊，產出就會更受影響。所以現在互聯網公司都是「低月薪+高年終獎」的模式。一般組成為12個月薪，外加2-5個月工資左右的年終獎。月薪不會克扣，但是年終獎會浮動變化。因為年終獎在收入中占比很大，所以大家都在努力工作，爭取年終有個好收成。有的公司制定政策的人腦袋抽了開始擔心拿了年終獎又跑路，所以把「年終獎」變成了「年中獎」。年中來發「年終獎」，錯過了求職黃金季。

「OKR」與績效考核

在互聯網公司，我們一般使用OKR來規劃目標。目標的達成與否與績效考核相關么？至少公司政策那幫人說是不相關的。而績效除了考核達成的結果(這部分和OKR的目標是重合的），還要有價值觀的考核。一個人的工作除了OKR中列的目標，日常還會有很多工作要做。而能在研發效能指標中體現出來的僅僅是其中一小部分。所以用研發效能度量來直接和績效考核掛鉤是相當不好的。

  

三者是有聯系的，但不是完全包含。如果我們一定「硬要」建立聯系，可能就會變成下面這個樣子。這是我們需要的么？

 

研發度量與績效考核

雖然很多公司不承認，但是的確是上圖這個樣子，比如千行代碼缺陷率高于多少就扣錢。這誰敢承認？一旦承認了通過一些研發效能指標來扣工資，員工都跑了，HR 也招不到人了。

目前國內 OKR 存在的最大的問題就是 OKR 鼓勵大家設置有挑戰性的目標追求卓越；但是這些挑戰性的目標和追求卓越的良心和衡量自己工資的績效考核是兩碼事。你把自己的OKR目標設置的很高，最后成了給自己加戲。你目標設置得再完美最后還是一句話的事且很難改變。然后又有人說如果員工把的所有工作都和績效進行關聯，行不行？這里也有很多問題。

• 1）首先把每天的日常工作都和績效目標關聯是一項非常耗時的工作。本來工作很多還要把一部分精力用在關聯。相當于效率沒提高還降低了。

• 2）并不是所有的工作都可以量化。有很多行政類，協調類工作，不容易評估

• 3）如果統一，那么OKR也就是KPI了。軟件研發搞成 KPI 就成了看錢寫代碼。KPI低了大家都滿意；KPI 高了很多人就走了。OKR變味。

• 4）把日常工作和績效關聯的這件事也需要平臺支撐。目前還沒有比較好的產品，只能自研。

• 5）如果都關聯好了，后期績效結果不如員工預期，會對員工和上級、HR都是挑戰。

舉個例子：

如果員工設置好了OKR，雙方都確認了，衡量結果也顯示都完成了，結果老板最后給的績效不行咋辦？

這就會對整個考核體系造成挑戰。

 

看錢寫代碼也會對效能產生各種反作用。

舉個例子：

軟件是一個完全非標品，無法準確度量。一個產品的登錄頁面，A用了標準組件，花費了幾分鐘10行代碼解決問題零缺陷；B自己手工擼了一遍，耗時兩天幾百行代碼，一測試各種問題。我們能說B比A強么？

所以不能簡單地靠代碼量來衡量效能，更不能來做績效考核的標準。

初心難守

員工職級、OKR和績效評審都是很難做的事情。想通過研發效能度量做績效考核的想法是非常不靠譜的。奉勸那些想通過研發效能度量扣工資的人還是省省吧，做個人吧。人人皆把「不忘初心」放在嘴邊，可是「初心」如果那么容易堅守，也不至于都要把「不忘」放在前邊提醒世人。

曾經在某一家公司，13薪都是陽歷12月底隨著工資一起發放。結果那一年公司的財務經理發了一個公告，考慮到大家圣誕節有消費的沖動，我們今年的13薪會在圣誕夜一起發放。提前祝大家圣誕快樂。我到現在都依然記得那個財務經理的名字。