图片来源@视觉中国


(资料图)

文| 穆胜

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

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

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

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

01 “造轮子”是什么?

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

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

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

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

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

“每天都在重复造轮子,卷没有意义的东西。”

“感觉即使造轮子都没诚意,还都在互相抄,而且都没做好。”

“不然呢?不自己重复造轮子,不都得失业吗?”

……

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

02 大厂如何进行绩效考核?

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

周期(何时考)——四个大厂都是每半年一次绩效考核,而字节在此基础上还有双月OKR管理,即每两个月调整一次OKR。

指标(考什么)——四个大厂基本都考核工作量、计划的按时完成情况、交付内容的质量、工作成果、团队贡献等。

主体(谁来考)——基本都是上级评价。字节是项目条线的Leader单线直接打绩效,足见其是相对“项目化”的灵活组织。而阿里、腾讯和美团采用双线评价,具体做法上,项目条线的Leader负责排名,然后职能条线的主管再根据排名顺序最后打绩效。

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

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

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

资料来源:穆胜咨询,注:数据为概算数字,具体局部案例里会有变化,此处仅作参考。

等级(分几级)——字节颗粒度最细,分为八级;阿里和美团分为五级;腾讯最近由五级精简为三级。而且,四个大厂都采取了强制分布,形式基本为361,腾讯稍微不同,为271(如图1)。

图1:一线互联网大厂绩效考核等级及其分布图,,资料来源:穆胜咨询

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

应用(定什么)——这个部分规则相似,几乎已经成为互联网企业的“行规”。一次低绩效,即图1中深灰色部分,会影响年终奖和晋升,而连续两次低绩效的员工会被纳入PIP(绩效提升计划),面临被辞退的风险。

03 大厂为何都在“造轮子”?

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

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

字节——在研发周期内会适当考核研发的成果和进展,从而体现在360环评中,如果最终未研发成功,大概率是低绩效。但结果不是决定性的,绩效的等级最终取决于项目Leader,如果Leader要奖励苦劳,也是可以的。这导致了在字节,因为项目Leader的这种导向,“造轮子”的现象较为严重,对研发结果的关注反而被分散了。

阿里——若遇到研发周期长的项目,可将项目分解写入OKR。但为了绩效,内部设置了大量“造轮子”的任务 。而且,很多是造完轮子后并不进行维护,进一步浪费资源。

腾讯——绩效考核时不会看研发过程,研发中期视作无产出,这是四大厂之中最特殊的一家。但员工并没有因此放弃“造轮子”,反而是用轮子来保护自己,强调自己产生了过程绩效。所以,腾讯的卷是“自来卷”。

美团——研发周期长,OKR考核要求写明阶段性产出,列出两三个重点工作,讲清背景、过程和结果,与阿里类似。这同样会形成大量的“造轮子”任务。

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

一是别人的轮子不好用。开源产品的不少“轮子”已经具备,但是往往存在仅满足80%-90%的需求的情况,为了10%造一个“轮子”的情况,大有人在。这可能是研发人员某种不太理性的“专业执着”。

二是跨部门沟通成本高。由于部门墙的存在,跨部门沟通的成本往往比自己“造轮子”还高。或者说,金字塔组织的结构天然阻碍信息流通,导致知识成果不能被共享。

三是研发中期产出过小。研发周期长于考核周期时,虽然能够将项目工作拆解写入OKR,但目标过小,OKR很难被Leader通过。所以,把很多“造轮子”的任务写入OKR,能够使得工作任务看起来更加丰富。

四是晋升和加薪的工具。研发人员本身业务的好坏彰显不出技术深度,并不能作为绩效考核的主要指标,只有通过技改重复“造轮子”,才有好绩效、才能晋升,程序员称其为“以能定级,以轮定能”。

五是绩效考核内卷产物。即使自己不“造轮子”,别人也会去“造轮子”,最后只能自己背低绩效,卷就是现状。于是,不同部门间重复“造轮子”,同部门的不同团队重复“造轮子”,同组的不同成员也在重复“造轮子”……

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

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

04 研发岗到底该如何考核?

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

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

图2:研发部门三层组织架构,资料来源:穆胜咨询

基石层——搭建底层工具。基于企业全局,形成研发框架,搭建底层工具。这确保所有的研发人员在一个体系里思考和沟通,确保了Lesson Learn等活动能够有效沉淀出能被共享的“轮子”。

夹心层——形成应用产品。基于底层工具,对接每类客户场景,形成可交付的应用产品。有了底层工具提供的“轮子”,这个层面只需要关注场景化应用,其效率会高很多。

BP层——负责落地交付。研发类中台需要向前台业务团队派出BP(业务伙伴),这些BP进入前线后,有了更准确的业务视角,可以更好地让应用产品落地,也能更好地调动身后的研发力量。

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

对基石层和夹心层,考核研发效能。他们负责将研发资源转化为工具和产品,理应考核效能(投产比),否则就会出现为了“刷产出”而“造轮子”的无谓投入。对于这两个层级来说,工具和产品的调用量是他们的产出,人力和财务两个口径是资源的投入。一方面,调用量不会因为“轮子”造得多而提升,好工具和产品会成为爆款;另一方面,如果要重复“造轮子”,投入会被放大,从而降低了研发效能。

对BP层,考核经营结果。即将研发BP纳入前台经营单元,让他们与经营单元其他成员一起为经营结果负责,共同劣后。这种市场化的考核和激励方式能够极大地调动研发人员的积极性,切实做到“为了客户而研发,而非为了研发而研发。”

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

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

推荐内容