关于devops:互联网公司员工职级研发效能度量OKR与绩效考核

最近有两个点触动了我。第一个触动点是奈飞 (netflix) 做出了一个微小动作开始进行职级划分; 第二个触动点是「DevOps 研发效力群里」探讨的效力度量与绩效考核。两者之间的实质都是要给员工分出个三六九等，无论是招聘的时候还是考核的时候。我想把我察看到的一些景象分享给大家。

奈飞 (Netflix) 职级划分的根因

首先讲讲奈飞的职级划分。当初奈飞为啥没职级呢？以前 Netfilx 本人钱多舍得给员工。当然招聘的门槛也高，大家的技术水平有保障，平级都失常。当初为啥要进行有职级了呢？要缩减估算，要多招应届生和资格教训较浅的员工降低成本。《奈飞文化手册》重点强调了“进步人才密度”，当初要扭转了么？是的，人力老本太高，迫切希望「新人」退出。2022 年注定是不平庸的一年（如同最近几年都不平庸）。

员工职级、势力与任务

员工职级一旦确定就意味着势力与任务的固定。也就是说，因为公司给予了你「高职级」（薪资待遇福利职位势力），那么具备高职级的人在各个方面都该当起到高职级人员应该承当的责任。同样，对于职级比拟低的人员，也该当起到「低职级」人员应该承当的责任。理论工作中，一旦职级划定，尤其是职级级别较多时，低级别人员的「积极主动」性都会受到打击，因为每次本人想做得更好的时候，如同都会有一个「高职级不干活」的影子在那里讥笑你。

一个特地有感触的场景就是散会，大家「肩膀」个别齐的时候，纷纷畅所欲言建言献策；忽然进来两个大佬，尤其是级别高很多 (+2) 的时候，大家就会不盲目地保持沉默，直到两个大佬在那讲完有了论断，积极主动的小伙伴无关痛痒的提个问题而后散会，其它人根本全程缄默。他们都感觉他俩职级高水平必定高决策必定也好，当然责任也他们来背，我为啥要发言？我不行的（我不背锅），职级(薪资待遇）不容许我发言。

另外一个特地有感触的场景是单干。A 团队和 B 团队单干一件事，没有职级的时候，A 负责人都是间接找 B 负责人，俩人聊完确认要单干后，个别都会指定两个团队上面的人理论执行。当有了职级，A 团队负责人和 B 团队负责人差很多的时候，这时候两个团队想单干，个别 A 团队都会把本人这条线和 B 团队负责人对等的领导拉进来，兴许是 + 1 级别，兴许是 + 2 级别，或者 + 3 级别。在沟通群里就会发现两个干活的你一言我一语在探讨，N 多领导保持沉默。步兵须要炮火声援先去召唤排长、连长、营长、团长、师长、军长，再转到炮司，炮营，炮连。整个过程看似没故障，人人都在为过程负责，但没有一个人违心为后果负责，都不违心去承当结果，后果就是听失去炮火的人死去，阵地失落。让听得见炮声的人召唤炮火，让炮火间接被听得见炮声的人召唤。

研发效力度量、OKR 与绩效考核

最近常常和一些业内大佬聊，大佬们很头疼的问题就是，老板拍板了要做研发效力度量，指标是掂量每个人的产出，研发效力度量的后果要在绩效考核上有所体现，即度量成果不好的扣工资。度量成果不好扣工资，OKR 没超预期扣工资，KPI 不达标扣工资，如同扣工资是咱们激发员工致力工作的惟一路径。

「年终奖」与「年中奖」

工资是公司依据与员工之间的约定，以货币模式对员工的劳动所领取的报酬。一旦很随便的克扣工资，员工的积极性就会受到打击，产出就会更受影响。所以当初互联网公司都是「低月薪 + 高年终奖」的模式。个别组成为 12 个月薪，外加 2 - 5 个月工资左右的年终奖。月薪不会克扣，然而年终奖会浮动变动。因为年终奖在支出中占比很大，所以大家都在致力工作，争取年初有个好收成。有的公司制订政策的人脑袋抽了开始放心拿了年终奖又跑路，所以把「年终奖」变成了「年中奖」。年中来发「年终奖」，错过了求职黄金季。

「OKR」与绩效考核

在互联网公司，咱们个别应用 OKR 来布局指标。指标的达成与否与绩效考核相干么？至多公司政策那帮人说是不相干的。而绩效除了考核达成的后果(这部分和 OKR 的指标是重合的），还要有价值观的考核。一个人的工作除了 OKR 中列的指标，日常还会有很多工作要做。而能在研发效力指标中体现进去的仅仅是其中一小部分。所以用研发效力度量来间接和绩效考核挂钩是相当不好的。

三者是有分割的，但不是齐全蕴含。如果咱们肯定「硬要」建立联系，可能就会变成上面这个样子。这是咱们须要的么？

研发度量与绩效考核

尽管很多公司不抵赖，然而确实是上图这个样子，比方千行代码缺陷率高于多少就扣钱。这谁敢抵赖？一旦抵赖了通过一些研发效力指标来扣工资，员工都跑了，HR 也招不到人了。

目前国内 OKR 存在的最大的问题就是 OKR 激励大家设置有挑战性的指标谋求卓越；然而这些挑战性的指标和谋求卓越的良心和掂量本人工资的绩效考核是两码事。你把本人的 OKR 指标设置的很高，最初成了给本人加戏。你指标设置得再完满最初还是一句话的事且很难扭转。而后又有人说如果员工把的所有工作都和绩效进行关联，行不行？这里也有很多问题。

• 1）首先把每天的日常工作都和绩效指标关联是一项十分耗时的工作。原本工作很多还要把一部分精力用在关联。相当于效率没进步还升高了。
• 2）并不是所有的工作都能够量化。有很多行政类，协调类工作，不容易评估
• 3）如果对立，那么 OKR 也就是 KPI 了。软件研发搞成 KPI 就成了看钱写代码。KPI 低了大家都称心；KPI 高了很多人就走了。OKR 变味。
• 4）把日常工作和绩效关联的这件事也须要平台撑持。目前还没有比拟好的产品，只能自研。
• 5）如果都关联好了，前期绩效后果不如员工预期，会对员工和下级、HR 都是挑战。

举个例子：

如果员工设置好了 OKR，单方都确认了，掂量后果也显示都实现了，后果老板最初给的绩效不行咋办？

这就会对整个考核体系造成挑战。

看钱写代码也会对效力产生各种副作用。

举个例子：

软件是一个齐全非标品，无奈精确度量。一个产品的登录页面，A 用了规范组件，破费了几分钟 10 行代码解决问题零缺点；B 本人手工撸了一遍，耗时两天几百行代码，一测试各种问题。咱们能说 B 比 A 强么？

所以不能简略地靠代码量来掂量效力，更不能来做绩效考核的规范。

初心难守

员工职级、OKR 和绩效评审都是很难做的事件。想通过研发效力度量做绩效考核的想法是十分不靠谱的。规劝那些想通过研发效力度量扣工资的人还是省省吧，做集体吧。人人皆把「不忘初心」放在嘴边，可是「初心」如果那么容易坚守，也不至于都要把「不忘」放在前边揭示世人。

已经在某一家公司，13 薪都是阳历 12 月底随着工资一起发放。后果那一年公司的财务经理发了一个布告，思考到大家圣诞节有生产的激动，咱们往年的 13 薪会在圣诞夜一起发放。提前祝大家圣诞快乐。我到当初都仍然记得那个财务经理的名字。