图片来源@视觉中国
(资料图)
文| 穆胜
一线互联网大厂的一举一动永远备受关注，在互联网经济风风火火的若干年里，其管理模式也一度被奉为圭臬。而在企业管理领域，关于中后台应该如何考核的问题，似乎已经成为千古难题，其中，以专业性强、项目周期长、过程难量化等特点著称的研发部门更是考核难题中的“顶峰”。
那么，一线互联网大厂是否真的已经解决了这个问题？
为此，穆胜咨询选取了四个市值/估值最高的国内一线互联网大厂——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纳入前台经营单元，让他们与经营单元其他成员一起为经营结果负责，共同劣后。这种市场化的考核和激励方式能够极大地调动研发人员的积极性，切实做到“为了客户而研发，而非为了研发而研发。”
根据穆胜咨询的观察，在商业环境迅速降温的今天，曾经高歌猛进的互联网大厂几乎都开始“向组织要红利”，在这样的背景下，他们突破研发这个曾经的“效率黑洞”的决心似乎异常坚定。
当前，少数先锋企业已经开始了行动，“快鱼吃慢鱼”，也许，留给大厂的时间不多了。
