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