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

文章插图
图1：一线互联网大厂绩效考核等级及其分布图，，资料来源：穆胜咨询
注：等级之间的对应关系根据实际的激励分配推算得出，仅作参考。

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

03 大厂为何都在“造轮子”？客观来说，大厂绩效考核都有很明确的制度，除了某些局部因为历史原因（如自评）形成的问题，制度框架没有太大的BUG 。
但决定这些制度有效性的，应该是其面对难题时的表现，即项目研发中期的考核。我们对样本企业进行了调研，却发现了制度理想和执行现实之间的巨大差距：

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

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

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

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

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

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

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

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

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

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

但究其本质，“造轮子”还是由大厂的绩效考核制度导致的。现如今，大厂采用的是以过程为导向的绩效考核制度，更注重过程中节点的考核。研发岗的专业性决定了，其研发过程类似于“黑箱”，考核者无法清晰的评估进度。
此外，由于基本采用单线评价，Leader或行政上级有超强的考核权。这些都导致研发为了获得高绩效评价而定向“演戏”，“轮子”自然就成为了最佳“道具” 。

04 研发岗到底该如何考核？那么，究竟如何客观对研发岗位进行考核、客观评价其贡献呢？穆胜咨询创始人、北京大学光华管理学院博士后穆胜给出了两个方向的建议：
建议1——重塑研发团队的组织架构，形成三层分工（如图2）。