今天要写这篇文章，来自最近有两个点触动了我。第一个触动点是奈飞(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中列的目标，日常还会有很多工作要做。而能在研发效能指标中体现出来的仅仅是其中一小部分。所以用研发效能度量来直接和绩效考核挂钩是相当不好的。
研发效能度量、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薪会在圣诞夜和工资一起发放。祝大家圣诞快乐。我到现在都依然记得那个财务经理的名字。
