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

穆胜事务所

1

作者|穆胜咨询研究院 来源|穆胜咨询(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),作者:穆胜咨询研究院

可行性研究报告

广告、内容合作请点这里:寻求合作

咨询·服务

相关阅读

精彩推荐