DevOps|中式土味OKR与绩效考核落地与实践

devops,中式,土味,okr,绩效考核,落地,实践 · 浏览次数 : 226

小编点评

## 中国如何做目标管理和绩效考核? 1. **道德品质和能力素质:** 每个人的职位行为决定了业务结果不同级别/工作性质的人员,绩效考核应该有不同权重组合团队管理者的绩效不得高于团队的绩效。 2. **基层一线小伙伴:** 看职业行为+业务结果中层管理者主要要看能力+业务结果管理层主要看业务结果。 3. **OKR与绩效挂钩:** OKR的达成与否主要涉及业务结果中可以量化的指标,一些不能量化的工作也可以是OKR的目标之一,但是如果想在绩效考核中体现,容易产生理解偏差。 4. **目标管理和绩效管理问题:** - classic难题?国内绩效管理和考核涉及到因素比较多1)中国「人际关系」「面子」在作祟,360度评价不可靠; - 中国企业发展快,变化也快,国外很多的实践落地都要经过改良。 5. **建议:** - 基于实际情况更新OKR,并拆解OKR成多个目标才能有效率地完成。 - 在和团队每个人去聊的时候,期望他们能设置的高一点。 - OKR的设定是自上而下,从上到下一层层去设置,每个人的目标要能有力支撑 TL也就是团队整体的目标。

正文

昨天一个小伙伴和我讨论了一下OKR和绩效管理,所以这次想简单明了地说下在中国怎么做比较合适,很多高大上的理论无法落地也是空中楼阁。

 

首先说一些,我个人的理解

  • 道德品质和能力素质决定了一个人的职位行为

  • 职位行为决定了业务结果

  • 不同级别/工作性质的人员,绩效考核应该有不同权重组合

  • 团队管理者的绩效不得高于团队的绩效

     

     

在组织层级中,基层一线小伙伴不但要看功劳,还要看苦劳,而职级越高则越是要看业务结果。到管理层这个级别,这个时候苦劳意义已经不大。因为对于基层一线小伙伴来说,有些功劳(业务结果),不是说自身具备了道德品质和能力素质就能拿到的。功劳和苦劳并重,这也是对基层一线小伙伴的一种保护,因为很多时候基层一线小伙伴只是执行者,无法决策,不能因为事情没做成,就一点收成也没有。

 

例子1:小伙子辛辛苦苦干一年,快要出活的时候,业务调整,项目不做了。这个时候你说小伙子绩效不好,这是不太合适的。

 

例子2: 管理层早8晚12点,咔咔的加班,结果一年多业务带黄了,这样的苦劳对公司没啥意义。

 

  • 基层一线小伙伴看职业行为+业务结果

  • 中层管理者主要要看能力+业务结果

  • 管理层主要看业务结果

 

OKR和绩效是一回事么?在一个系统中评定?

不是一回事。OKR有OKR系统,绩效有专门的绩效系统,采用的360度评价考核,主要考核的是上下左右对你的工作认可,当然上占据的比重会大。

OKR是否关联绩效?

关联。我的中式土味做法是把OKR直接转化成绩效考核中最重要的一部分,比如70%,同时加上一些企业文化、团队培养、技术分享,这样大家在完成OKR的同时,其实把自己绩效的主要考核部分也就完成了。

如果OKR不与绩效挂钩,就会产生你让我做的和最后考核我的不一致这个问题,这对一线员工来说,对积极性的影响比较大。你让我干的我都干了,然后你拿一个从来没有跟我说的指标考核我?但是对非一线员工,其实360度考核影响得更大,因为已经不能仅仅通过你每天的日常工作衡量你的贡献了。

OKR 与绩效考核啥关系?

OKR的达成与否主要涉及业务结果中可以量化的指标。有些不能量化的工作也可以是OKR的目标之一,但是如果想在绩效考核中体现,容易产生理解偏差。

OKR与绩效考核挂钩后会出现设置OKR讨价还价?怎么解决?

是的,OKR和绩效挂钩后会出现这个问题。为了拿到好绩效,OKR都不会设置成「踮着脚能够到的目标」,多数会设置成「正好能完成」,这个时候在和团队每个人去聊的时候,还是期望他们能设置的高一点。至少他们设置的高一点,在我这里印象分提高不少。

OKR的设定是自上而下,从上到下一层层去设置。上级设定完成 10 个功能,那么下级9个人的团队就要能至少完成 10 个功能,还要有其他贡献;如果9个人每个人设置完成1个功能,那么TL /团队的目标就是完不成的。团队每个人的目标要能有力支撑 TL 也就是团队整体的目标,如果没有拆解下去,那么就是 TL 的问题,也就是团队的问题。O 一定要拆解下去,否则更大老板的 O 就完不成了。当然OKR也不是一成不变,是可以根据实际情况更新的。

非一线员工, 是指Team Lead 对吧?

至少是 Team Lead 这个级别。因为他们的大部分产出应该通过团队达成产出,与上下左右的协作,甚至是对公司业务达成的影响,而不仅仅是个人做了哪些事情。

TL的个人绩效是会参考OKR达成率和团队的业绩对吧?那团队业绩这块有做量化指标衡量吗?

你可以认为团队业绩就是 TL 的个人业绩。因为你不这样认为也不行,团队绩效好的时候, TL自己也会把团队所有的绩效算到自己头上;团队绩效坏的时候,TL自己会把团队绩效放到其他人身上去。为了避免这两种情况,画约等号,甚至是等号是做好的办法。也可以激励 TL 带领团队拿到一个比较好的团队绩效。

而他个人的OKR就是团队业绩中「事」部分做得好坏的最大考量指标,结合我上面说的360度,就是 TL 的个人绩效。也就是说 TL 个人绩效= 团队绩效 > TL 个人OKR + 360考评+ 企业文化+ 管理能力

很多员工最恨的就是团队绩效很差,但是 TL 拿了超出团队绩效表现的高绩效。

目标管理和绩效管理的问题,不管是KPI还是OKR,经典难题?

国内绩效管理和考核涉及到因素比较多

1)中国「人际关系」「面子」在作祟,360度评价不可靠;

2)在中国工作压力大,很多时候是既要有OKR 又要有 KPI,还要有企业文化等软性指标。

3)中国企业发展快,变化也快,国外很多的实践落地都要经过改良。

4)年终奖在员工薪资中占比过大,每个人都要争取高绩效;而在外企,大家相对躺平一些,OKR/绩效考核虽然有差异,但是大家拿到手的差距没那么大。

 

我的相关文章

互联网公司员工职级、研发效能度量、OKR与绩效考核
互联网公司实行目标管理(OKR)五点原则和基础
互联网公司目标管理OKR实践落地与反思
互联网公司目标管理OKR和绩效考核误区

与DevOps|中式土味OKR与绩效考核落地与实践相似的内容:

DevOps|中式土味OKR与绩效考核落地与实践

昨天一个小伙伴和我讨论了一下OKR和绩效管理,所以这次想简单明了地说下在中国怎么做比较合适,很多高大上的理论无法落地也是空中楼阁。 首先说一些,我个人的理解 道德品质和能力素质决定了一个人的职位行为 职位行为决定了业务结果 不同级别/工作性质的人员,绩效考核应该有不同权重组合 团队管理者的绩效不得高

devops|中小公司不要做研发效能度量

我特别反感那些不顾公司现状一上来就想要做研发效能度量的人,尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量,就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下,公司想要做好研发效能度量也有标准的三步:长时间对研发效能

devops|中小公司效率为王,没必要度量

之前写过一篇文章《devops|中小公司不要做研发效能度量》,主要是从基础设施方向考虑,因为很多条件都不具备,贸然高投入去做研发效能度量可能达不到我们的预期效果,给出的建议是先做好当下打好基础。今天想到一个好例子,可以类比下。 两个人小家庭 1)人少 2)收入清晰 3)支出清晰,买了什么东西,花了多

DevOps | 产研协同效能提升之评审、审批流、质量卡点

研发过程中有各种需求的评审、审批流和质量卡点,有的是为了质量把关,有的是为了彰显权力,还有一些是为了信息告知。本文主要讨论在软件开发过程中涉及的评审、审批和质量卡点三种情况,同时探讨对研发流程的影响,在这过程中如何去提效。 同团队内部评审 同团队之间的评审包括产品团队内部的PRD评审,RD团队内部的

DevOps|从腾讯TEG CDC解散聊技术中台价值和建设

近日一则腾讯TEG CDC整个部门解散的消息在很多群里炸了锅,有的唱衰互联网行业,有的唉声叹气,还有的甩锅到 AGI 的发展。总体上来说,这个事情的确已经发生了,我想从组织架构和整体效能这两方面来分析下这次组织变化。 腾讯TEG CDC解散 6月28日,网传腾讯TEG CDC整体解散,人员涉及设计师

DevOps|乱谈开源社区、开源项目与企业内部开源

之前的一篇文章《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意,有的小伙伴非常不同意,我觉得这都是非常正常的反馈,话不说不透,理不辩不明,我还是特别希望能和大家一起把这个问题弄明白。这篇文章就是那篇文章的后续,本文主要讨论开源社区、开源

DevOps|研发效能解决的是企业效率问题

研发效能并不能解决企业效益问题 它不是利润中心,不能给你带来直接收入(研发效能相关工具厂商做咨询、出方案、卖工具除外)。想要解决企业效益问题,依赖于企业战略、业务/产品、组织、运营、创新等其他方面。 研发效能解决的是企业效率问题 研发效能解决的是企业内部「产研运协作效率」的问题。 企业最需要两种涉及

DevOps|研发效能不是老板工程,是开发者服务

有人说研发效能是老板工程。不是的,研发效能不是老板工程,它不直接服务于老板(虽然老板可能看一些报表),反而是服务于广大产研运(产品+研发+质量+运维)的同学,所以有的公司也把研发效能叫做基础中台,平台工程,开发者服务团队,或者叫开发者服务平台。做好研发效能,做好开发者中台,就容易把公司的各种中后台能

AI DevOps | ChatGPT 与研发效能、效率提升(中)

为啥 ChatGPT 突然火了? 简单概括就是:产品太过惊艳,体验超预期 之前人工智能发展多年,报道最多的也许就是曾经的李世石大战AlphaGo,现实中的特斯拉自动驾驶,还有波士顿动能放出的机器狗。对于圈外人士来说一般也接触不到这些,仅仅看看而已。但是 ChatGPT 不一样,一声巨响,石头中蹦出一

DevOps|1024程序员节怎么做?介绍下我的思路

1024,祝每个程序员小哥哥小姐姐节日快乐。 因为在研发效能部门,我支持过几次 1024 程序员节的活动,所以经常有朋友问我1024 程序员节怎么做,本篇就是简单介绍下我的思路,希望对你有用。 1024程序员节的由来 俄罗斯把每年第256(=2^8)天,即平年9月13日或闰年9月12日定为国际程序员