大厂 | 深度扒皮，一线互联网大厂研发都在“造轮子”？

作者|穆胜咨询研究院 来源|穆胜咨询(ID：hrm-yun)

一线互联网大厂的一举一动永远备受关注，在互联网经济风风火火的若干年里，其管理模式也一度被奉为圭臬。而在企业管理领域，关于中后台应该如何考核的问题，似乎已经成为千古难题，其中，以专业性强、项目周期长、过程难量化等特点著称的研发部门更是考核难题中的“顶峰”。

那么，一线互联网大厂是否真的已经解决了这个问题？

为此，穆胜咨询选取了四个市值/估值最高的国内一线互联网大厂——BATM（字节跳动、阿里巴巴、腾讯、美团）作为样本，对其研发人员的考核方式进行对比分析。

我们得到的答案可能让人失望——从研发职能看，一线互联网大厂并没有解决中后台考核问题，反而进入了很尴尬的状态。

01

“造轮子”是什么？

“造轮子”这个词在程序员之间并不陌生，它更加确切的翻译是“重复发明轮子”，即，圆形车轮已经是大家公认最好的了，而你非要自己发明另一种形状的轮子。

带入IT行业，就是明明有现成的框架库、工具等，明知道自己做得不可能更好，却坚持要做，还号称自己做出了新东西。简单来说，“造轮子”就是研发人员投入精力重复做些大同小异、功能差不多的工具出来。

例如，A业务做了个工具，B业务却不用A业务的工具，自己从0到1做了个差不多的工具出来。

这看上去是极度低效的行为，不仅对公司经营起不到任何推动作用，还浪费了大量资源，严重拖低企业效率。进一步看，这也让有才华的研发人员陷入了完全无意义的内卷，浪费了他们的青春。

在国内某知名职场社交平台上，研发人员自己的吐槽声不绝于耳：

平心而论，大厂的管理层不可能不知道研发人员在重复“造轮子”，但为什么这个现象还一直存在呢？

02

大厂如何进行绩效考核？

这里就要说到大厂的绩效考核制度了。通过调研四个大厂的绩效考核制度，我们对其研发岗位的考核进行简单的对比分析：

另外，四家企业依然都沿用几乎已经被专业人士摒弃的“自评”， 但并未为其设置权重。最初的设想是为了获得一个实施考核的参照物，但实践中，这种效果并没有实现，还变成了形式主义的负担。

员工评价：“怎么打都一样，领导提前一个月就打好绩效了。”“随便填，反正组长有100%决定权。”

表：一线互联网大厂考核主体考核逻辑

资料来源：穆胜咨询

注：数据为概算数字，具体局部案例里会有变化，此处仅作参考。

图1：一线互联网大厂绩效考核等级及其分布图

资料来源：穆胜咨询

注：等级之间的对应关系根据实际的激励分配推算得出，仅作参考。

03

大厂为何都在“造轮子”？

客观来说，大厂绩效考核都有很明确的制度，除了某些局部因为历史原因（如自评）形成的问题，制度框架没有太大的BUG。

但决定这些制度有效性的，应该是其面对难题时的表现，即项目研发中期的考核。我们对样本企业进行了调研，却发现了制度理想和执行现实之间的巨大差距：

可见，无论是哪种制度差异，最终都导致了大厂研发们集体走向“造轮子”。我们也对研发人员进行了调研，从他们的直观反馈来看，“造轮子”主要有以下几个原因：

但究其本质，“造轮子”还是由大厂的绩效考核制度导致的。现如今，大厂采用的是以过程为导向的绩效考核制度，更注重过程中节点的考核。研发岗的专业性决定了，其研发过程类似于“黑箱”，考核者无法清晰的评估进度。

此外，由于基本采用单线评价，Leader或行政上级有超强的考核权。这些都导致研发为了获得高绩效评价而定向“演戏”，“轮子”自然就成为了最佳“道具”。

04

研发岗到底该如何考核？

那么，究竟如何客观对研发岗位进行考核、客观评价其贡献呢？穆胜咨询创始人、北京大学光华管理学院博士后穆胜给出了两个方向的建议：

建议1——重塑研发团队的组织架构，形成三层分工（如图2）。

图2:研发部门三层组织架构

资料来源：穆胜咨询

建议2——分层考核，关注真实的价值创造。

根据穆胜咨询的观察，在商业环境迅速降温的今天，曾经高歌猛进的互联网大厂几乎都开始“向组织要红利”，在这样的背景下，他们突破研发这个曾经的“效率黑洞”的决心似乎异常坚定。

当前，少数先锋企业已经开始了行动，“快鱼吃慢鱼”，也许，留给大厂的时间不多了。

编者按：本文转载自微信公众号：穆胜咨询(ID：hrm-yun)，作者：穆胜咨询研究院