一線互聯網大廠的一舉一動永遠備受關注，在互聯網經濟風風火火的若干年里，其管理模式也一度被奉為圭臬。而在企業管理領域，關于中后臺應該如何考核的問題，似乎已經成為千古難題，其中，以專業性強、項目周期長、過程難量化等特點著稱的研發部門更是考核難題中的“頂峰”。

那么，一線互聯網大廠是否真的已經解決了這個問題？

為此，穆勝咨詢選取了四個市值/估值最高的國內一線互聯網大廠——BATM（字節跳動、阿里巴巴、騰訊、美團）作為樣本，對其研發人員的考核方式進行對比分析。

我們得到的答案可能讓人失望——從研發職能看，一線互聯網大廠并沒有解決中后臺考核問題，反而進入了很尷尬的狀態。

01、“造輪子”是什么？

“造輪子”這個詞在程序員之間并不陌生，它更加確切的翻譯是“重復發明輪子”，即，圓形車輪已經是大家公認最好的了，而你非要自己發明另一種形狀的輪子。

帶入IT行業，就是明明有現成的框架庫、工具等，明知道自己做得不可能更好，卻堅持要做，還號稱自己做出了新東西。簡單來說，“造輪子”就是研發人員投入精力重復做些大同小異、功能差不多的工具出來。

例如，A業務做了個工具，B業務卻不用A業務的工具，自己從0到1做了個差不多的工具出來。

這看上去是極度低效的行為，不僅對公司經營起不到任何推動作用，還浪費了大量資源，嚴重拖低企業效率。進一步看，這也讓有才華的研發人員陷入了完全無意義的內卷，浪費了他們的青春。

在國內某知名職場社交平臺上，研發人員自己的吐槽聲不絕于耳：

“每天都在重復造輪子，卷沒有意義的東西。”

“感覺即使造輪子都沒誠意，還都在互相抄，而且都沒做好。”

“不然呢？不自己重復造輪子，不都得失業嗎？”

……

平心而論，大廠的管理層不可能不知道研發人員在重復“造輪子”，但為什么這個現象還一直存在呢？

02、大廠如何進行績效考核？

這里就要說到大廠的績效考核制度了。通過調研四個大廠的績效考核制度，我們對其研發崗位的考核進行簡單的對比分析：

周期（何時考）——四個大廠都是每半年一次績效考核，而字節在此基礎上還有雙月OKR管理，即每兩個月調整一次OKR。

指標（考什么）——四個大廠基本都考核工作量、計劃的按時完成情況、交付內容的質量、工作成果、團隊貢獻等。

主體（誰來考）——基本都是上級評價。字節是項目條線的Leader單線直接打績效，足見其是相對“項目化”的靈活組織。而阿里、騰訊和美團采用雙線評價，具體做法上，項目條線的Leader負責排名，然后職能條線的主管再根據排名順序最后打績效。

另外，四家企業依然都沿用幾乎已經被專業人士摒棄的“自評”， 但并未為其設置權重。最初的設想是為了獲得一個實施考核的參照物，但實踐中，這種效果并沒有實現，還變成了形式主義的負擔。

員工評價：“怎么打都一樣，領導提前一個月就打好績效了。”“隨便填，反正組長有100%決定權。”

等級（分幾級）——字節顆粒度最細，分為八級；阿里和美團分為五級；騰訊最近由五級精簡為三級。而且，四個大廠都采取了強制分布，形式基本為361，騰訊稍微不同，為271。

注：等級之間的對應關系根據實際的激勵分配推算得出，僅作參考。

應用（定什么）——這個部分規則相似，幾乎已經成為互聯網企業的“行規”。一次低績效，即圖1中深灰色部分，會影響年終獎和晉升，而連續兩次低績效的員工會被納入PIP（績效提升計劃），面臨被辭退的風險。

03、大廠為何都在“造輪子”？

客觀來說，大廠績效考核都有很明確的制度，除了某些局部因為歷史原因（如自評）形成的問題，制度框架沒有太大的BUG。

但決定這些制度有效性的，應該是其面對難題時的表現，即項目研發中期的考核。我們對樣本企業進行了調研，卻發現了制度理想和執行現實之間的巨大差距：

字節——在研發周期內會適當考核研發的成果和進展，從而體現在360環評中，如果最終未研發成功，大概率是低績效。但結果不是決定性的，績效的等級最終取決于項目Leader，如果Leader要獎勵苦勞，也是可以的。這導致了在字節，因為項目Leader的這種導向，“造輪子”的現象較為嚴重，對研發結果的關注反而被分散了。

阿里——若遇到研發周期長的項目，可將項目分解寫入OKR。但為了績效，內部設置了大量“造輪子”的任務 。而且，很多是造完輪子后并不進行維護，進一步浪費資源。

騰訊——績效考核時不會看研發過程，研發中期視作無產出，這是四大廠之中最特殊的一家。但員工并沒有因此放棄“造輪子”，反而是用輪子來保護自己，強調自己產生了過程績效。所以，騰訊的卷是“自來卷”。

美團——研發周期長，OKR考核要求寫明階段性產出，列出兩三個重點工作，講清背景、過程和結果，與阿里類似。這同樣會形成大量的“造輪子”任務。

可見，無論是哪種制度差異，最終都導致了大廠研發們集體走向“造輪子”。我們也對研發人員進行了調研，從他們的直觀反饋來看，“造輪子”主要有以下幾個原因：

一是別人的輪子不好用。開源產品的不少“輪子”已經具備，但是往往存在僅滿足80%-90%的需求的情況，為了10%造一個“輪子”的情況，大有人在。這可能是研發人員某種不太理性的“專業執著”。

二是跨部門溝通成本高。由于部門墻的存在，跨部門溝通的成本往往比自己“造輪子”還高。或者說，金字塔組織的結構天然阻礙信息流通，導致知識成果不能被共享。

三是研發中期產出過小。研發周期長于考核周期時，雖然能夠將項目工作拆解寫入OKR，但目標過小，OKR很難被Leader通過。所以，把很多“造輪子”的任務寫入OKR，能夠使得工作任務看起來更加豐富。

四是晉升和加薪的工具。研發人員本身業務的好壞彰顯不出技術深度，并不能作為績效考核的主要指標，只有通過技改重復“造輪子”，才有好績效、才能晉升，程序員稱其為“以能定級，以輪定能”。

五是績效考核內卷產物。即使自己不“造輪子”，別人也會去“造輪子”，最后只能自己背低績效，卷就是現狀。于是，不同部門間重復“造輪子”，同部門的不同團隊重復“造輪子”，同組的不同成員也在重復“造輪子”……

但究其本質，“造輪子”還是由大廠的績效考核制度導致的。現如今，大廠采用的是以過程為導向的績效考核制度，更注重過程中節點的考核。研發崗的專業性決定了，其研發過程類似于“黑箱”，考核者無法清晰的評估進度。

此外，由于基本采用單線評價，Leader或行政上級有超強的考核權。這些都導致研發為了獲得高績效評價而定向“演戲”，“輪子”自然就成為了最佳“道具”。

04、研發崗到底該如何考核？

那么，究竟如何客觀對研發崗位進行考核、客觀評價其貢獻呢？穆勝咨詢創始人、北京大學光華管理學院博士后穆勝給出了兩個方向的建議：

建議1——重塑研發團隊的組織架構，形成三層分工。

基石層——搭建底層工具。基于企業全局，形成研發框架，搭建底層工具。這確保所有的研發人員在一個體系里思考和溝通，確保了Lesson Learn等活動能夠有效沉淀出能被共享的“輪子”。

夾心層——形成應用產品。基于底層工具，對接每類客戶場景，形成可交付的應用產品。有了底層工具提供的“輪子”，這個層面只需要關注場景化應用，其效率會高很多。

BP層——負責落地交付。研發類中臺需要向前臺業務團隊派出BP（業務伙伴），這些BP進入前線后，有了更準確的業務視角，可以更好地讓應用產品落地，也能更好地調動身后的研發力量。

建議2——分層考核，關注真實的價值創造。

對基石層和夾心層，考核研發效能。他們負責將研發資源轉化為工具和產品，理應考核效能（投產比），否則就會出現為了“刷產出”而“造輪子”的無謂投入。對于這兩個層級來說，工具和產品的調用量是他們的產出，人力和財務兩個口徑是資源的投入。一方面，調用量不會因為“輪子”造得多而提升，好工具和產品會成為爆款；另一方面，如果要重復“造輪子”，投入會被放大，從而降低了研發效能。

對BP層，考核經營結果。即將研發BP納入前臺經營單元，讓他們與經營單元其他成員一起為經營結果負責，共同劣后。這種市場化的考核和激勵方式能夠極大地調動研發人員的積極性，切實做到“為了客戶而研發，而非為了研發而研發。”

根據穆勝咨詢的觀察，在商業環境迅速降溫的今天，曾經高歌猛進的互聯網大廠幾乎都開始“向組織要紅利”，在這樣的背景下，他們突破研發這個曾經的“效率黑洞”的決心似乎異常堅定。

當前，少數先鋒企業已經開始了行動，“快魚吃慢魚”，也許，留給大廠的時間不多了。

來源：穆勝咨詢研究院