OKR之剑·实战篇04:OKR执行过程优化的那些关键事
作者:vivo 互联网平台产品研发团队
本文是《OKR 之剑》系列之实战第 4 篇——OKR执行过程不是一成不变的,团队和个人在执行中不断优化执行的具体行动,保障OKR的高效执行。
前言
“言治骨角者,既切之而复磋之;治玉石者,既琢之而复磨之,治之已精,而益求其精也。”古之骨器切后需反复磋之,玉器雕琢后仍需反复打磨,团队在引入OKR、制定OKR、执行OKR中,仍需持续优化,以求精益求精。
一、执行好OKR的ABCDE
1.1、Aim in line:定期沟通,目标一致
如果希望团队中的每个人能正确理解目标,那么就需要不断地和他沟通。定期的沟通对于团队来说非常重要,一方面保证团队信息透明:信息透明有利于OKR持续的推进,同时避免因信息不同步而造成人力的重复投入,重复工作;另一方面保证团队成员对目标理解的一致,确认所有人能明确并且承担自己的责任,不出现偏差,形成更强的“合力”。
定期沟通没有固定的形式,可以是正式的OKR会议承载,也可以随意的找个茶水间一起聊一聊。可以是自上而下的沟通(比如管理者月度面谈机制),也可以是自下而上的反馈(比如Office hour机制:每周约定某个时间段,团队成员可以主动约各级管理者沟通)。
团队成员有各种形式的沟通,能够充分、全面地了解团队目前的方向、目标,每位成员都了解团队的目标、规划,更有助于将个人的行动、计划保持在同一方向上。目标理解一致重要的是让团队成员了解团队的方向,理解为什么制定这样的目标,以及个人在其中承担的责任和做出的贡献。最大程度调动每位成员的积极性和自驱力,而不是被动地接受工作安排。
各种形式的沟通确保信息的透明和目标理解的一致,团队成员也可能更愿意主动沟通,全面了解团队情况。
1.2、Be planned:做好执行计划
“凡事预则立,不预则废”——《礼记·中庸》
OKR的执行靠意志力就一定会有好的结果吗?不一定!就拿减肥来说,多数人也只是想想而已,三天都很难坚持,买个体重秤比所谓的意志力有用多了。
以我们团队为例,我们在一个季度的OKR执行周期中,每周都会同步自己的计划,执行计划需要聚焦于OKR,避免流水账和无意义的凑数。每周的计划完成后,都会推动OKR的完成度提升一点。
同时也为了让OKR执行和每周的计划更有仪式感,我们使用了OKR管理工具来帮助团队成员有规划的去做重要的事情,让我们在执行过程中不会迷茫,能一直保持在既定的轨道上。

1.3、Concentrate:聚焦重点,少即是多
制定OKR时,很可能会陷入“我都想要”的困境:工作中很多事情看上去都很重要,比如说技术团队要深度参与业务版本的评审、设计、开发、测试等重要环节,那这些是否都要一条条详细地列入OKR中呢?显然这么做有悖OKR聚焦的原则。
在制定篇中我们提到OKR不是拉清单式的罗列,而是帮助团队聚焦方向,少即是多。
一个团队理想的状态是持续做重要且有价值的事情。在OKR执行时,我们要回答自己几个问题:这个事情如果不做,对我们的目标有影响吗?如果按照重要性排序,哪些事情最重要呢?离目标我们还差了多远?
例如,90年代末苹果濒临破产,乔布斯回归后即砍掉70%的产品线,产品 重心放在“消费级”和“专业级”,“台式”和“便携式”四个领域,不到一年的时间带领苹果扭亏为盈,奠定了苹果科技巨头的基础。这是典型的抓重点、重要的事最高优先级的管理案例。
日常工作中,有时难以避免会有琐碎的、计划之外的事情需要处理,但不能陷入其中,这很容易会产生虚假的忙碌感和充实感,但这些事情对目标的实现却毫无用处。很多团队个人会经历这样的情况,在目标制定时重点明确,目标聚焦,但实际执行中却陷入了琐碎的事情中,忘记自己原本的目标。
所以我们建议,在OKR执行过程中要经常审视自己是否聚焦于目标,避免深陷于不断做与目标偏移的事情的陷阱,这是非常必要的。

1.4、Daily:OKR是日常工作的一部分
OKR的目标要激动人心,OKR的执行要脚踏实地。
OKR目标很“高大上”,怎么让OKR落地呢?我们建议OKR要和日常工作结合起来,比如通过周报的方式做到常态跟踪,保证目标不跟丢。对于挑战型的目标,实现的过程是长期的,很难一蹴而就。目标在制定时“激动人心”,如果长时间没有正向反馈和结果,很难持续地投入精力,再加上日常琐碎事情的羁绊,很容易不了了之,慢慢变成自欺欺人的僵尸OKR。
OKR与日常工作结合,让我们在制定工作计划、审视执行情况时,也时时对OKR进行回顾审视。OKR源于日常工作,又高于日常工作,是对日常工作和团队方向的提炼、结合。
1.5、Effect of long time:长期坚持,优势自现
团队引入OKR并执行一段时间后,可能会有种“药效慢”的感觉,有人会问“我们投入了很多精力去学习和引入OKR,为什么没感觉到团队有明显的变化呢?”。
从我们多年执行OKR的经验来看,“未见药效”的初期阶段是必然存在的,我们当初也 经历过这样的时期。前期磨合阶段比较迷茫,后面慢慢发现团队有了很大的变化,其中最宝贵的收获是有了自驱、敢于挑战的团队氛围,这种氛围渗透在团队工作中的方方面面,在这种氛围的助力下,团队成事的能力越来越强。但这种变化不是一两个OKR周期就能明显感觉到,而是长期坚持沉淀出来的结果。
随风潜入夜,润物细无声。OKR理念会在制定——执行——复盘的周期中潜移默化地渗透给团队每个人。我们提倡长期主义,坚持做正确的事情。在团队执行OKR的过程中,发现不足,然后持续改进,形成良性循环,一点点地改变,这是一个渐进的过程。希望每个团队能多一点耐心,不急于求成,埋头种因,果水到渠成。
二、不同OKR执行过程的关键事项
2.1、个人OKR和团队OKR
团队制定好OKR以后,我们建议每个人都设定单独的OKR,个人OKR服务于团队的OKR。团队OKR体现了团队的目标,聚焦于现阶段团队需要做的关键事项,个人OKR的制定要以团队OKR为导向,用以反映个人成长以及对团队目标的贡献。
个人和团队OKR的关系,我们总结了三个关键词:对齐、包含和扩展。
对齐。个人OKR承接自团队OKR,与团队OKR的某一部分对齐(这部分体现了个人对团队目标的贡献)。对齐意味着目标的一致,不会出现偏差,也避免员工过于关注他们个人的OKR带来的弊病。
包含。团队成员个人OKR的累加包含了团队OKR的内容。个人实现目标的同时也帮助团队达成了目标,团队的成功离不开每个人的贡献。
扩展。个人OKR不局限于团队OKR,会在其中融入一些自己的想法和追求,个人OKR是团队OKR的延伸扩展。

2.1.1、owner制
在日常的OKR执行过程中,我们发现每个人会不自觉地更多关注个人OKR。前期我们一直要求每个人更多地关注团队OKR,后来发现只要做好了对齐,更多关注个人OKR效果会更好。但是在这个过程中,必须要有人跟进团队OKR的进展,起到监督、资源协调、风险把控的作用。
怎么保证团队OKR在跟踪过程中,不会出现没人管的局面呢?我们摸索出owner制:团队OKR的每一个KR都有专人负责,即KR owner,KR owner可以是一个人也可以是多人。owner在整个OKR周期内,负责跟进KR的进展。

在跟踪的形式和时间节点上,个人OKR和团队OKR会有一些区别:
个人OKR用于日常的跟踪执行,在OKR周总结上体现进展和跟踪过程。
在月度复盘和季度总结会这些时间节点上,我们更关注团队OKR的整体情况,每个KR owner需同步对应KR的进展和风险并进行记录。当然如果KR要做调整,那么相应的个人OKR也要做出变化。
个人成长类OKR怎么跟踪呢?
个人OKR通常由两部分组成:个人成长相关 + 团队OKR部分。其中关于团队的那部分,一方面大家比较关注,整个团队都是监督人,很难不重视;另一方面团队OKR的进展会定期同步,不会跟丢。但是个人成长相关OKR的责任人只有自己,怎么取得更好的跟踪效果呢?我们的经验是:
额外增加一个人进行监督,监督的角色可以由OKR教练承担;
在OKR周总结中常态化跟进,同时在主要流程节点(庆功会、月末总结、季度复盘等)要同步进展,让OKR的执行情况对团队保持透明。
2.1.2、聚焦于结果
有效的OKR聚焦于结果,而非任务,严谨的说是指团队想要达到的结果。然而当制定个人OKR时,大家往往会忍不住把那些与岗位相关的任务全部包含进来,比如说提交月度总结、研发同学解决系统的bug、产品同学提交日常版本的策划等等。虽然任务的罗列看上去很“充实”,也利于个人的任务管理,却并没有对整个团队的战略执行产生实质性的贡献。

我们提倡集体主义,集中力量办大事,不提倡单打独斗和个人英雄主义。个人OKR要以团队OKR为导向,这是个人OKR制定和执行的立足点。个人OKR如果没有聚焦到团队目标中来,完成得再好,对团队想要实现的结果也没有促进作用。和团队目标对齐的前提是个人对团队OKR的认同,怎么让更多人认同团队OKR呢?这就需要更多人参与到团队OKR中来,理解了制定和执行的过程并参与其中,可以增强大家对它的承诺,参与即认同。
2.2、承诺型OKR和挑战型OKR
要敢于设定“胆大包天的目标”。——《从优秀到卓越》
谷歌将OKR分为两类:承诺型和挑战型(或愿景型)。 两者的区别主要在于:
实现难度不一样。承诺型OKR实现难度要比挑战型OKR低,如果用信心指数来说明(10分制),承诺型OKR一般在5分以上,而挑战型OKR一般在5分以下。当然这并不绝对,不能根据信心指数简单来划分两者。
时间侧重不一样。承诺型目标侧重的是现在和即将要做的事情;挑战型目标侧重未来导向,时间跨度会比较长,1-2两周就可以完成的事情绝对称不上有挑战性。
预期结果不一样。承诺型OKR与日常考核指标紧密关联,比如版本发布、销量增长、功能建设等。一般来说预期完成度高,全力以赴的情况下可以100%完成;挑战型OKR反映了更高的追求,已不局限于日常工作,旨在调动整个组织的积极性和活力,预期的完成度比较低。

这两种类型OKR的相对比重与团队的定位以及组织文化相关,没有绝对的比重值,同一个团队不同的季度都会有所不同。重要的是,要考虑清楚几个问题:我们想要达到什么结果?当前的目标能否带来突破?我们是否可以承担更大的风险去实现更高的目标?我们通常会思考目标是否能够带来业务的突破,或完成后对业务进一步发展有促进作用,以此作为重要的判断标准。
另外我们想说的是,正如前面制定篇所言OKR要有挑战性,即使是承诺型OKR,也不仅仅是完成任务,我们提倡 “OKR不仅是跳一跳能够到的目标,而是要鼓励使劲地跳一跳”。

在OKR的执行过程中,OKR的属性不同,跟踪方式也会有所区别。
2.2.1、承诺型OKR的跟踪
承诺型OKR和日常的工作有关,这意味着目标内容的确定性和完成的必要性强,在跟踪过程中要求要严格一些。严格体现在两个方面:一方面是完成进度的容忍性要低,一旦进度出现风险,要及时跟进,分析原因并给出后续计划;另一方面,对于承诺型OKR,最终季度复盘时打分要严格一些。比如说100%完成但没有超出预期的KR,不能打满分10分,只能给7分。
2.2.2、挑战型OKR的跟踪
(1)管理者要支持。
一个团队要实现“胆大包天的目标”,没有管理者的支持,是很难坚持下去的。管理者的支持主要是两点:
一是放权,让一线人员放开手脚去干。实现挑战型的目标,依靠的是员工内在驱动力,他们愿意做挑战能力边界的事情并能实现“自我超越”。怎么调动员工的积极性?给他们更多的自主权,这是实现挑战型目标的土壤。
二是资源的支持。管理者愿意持续投入资源,这是实现挑战型OKR的保证。投入多少资源要从团队的现状考虑,但必须从OKR的制定开始,就要考虑好后续资源的持续投入情况。

以我们团队举例,作为业务开发团队,主要的时间支撑业务版本的开发,但我们也会制定挑战型的OKR,比如说技术组件的沉淀和推广。在资源的投入上,我们遵循721原则,达成业务目标的基础上,分配10%的精力到技术高地突破和挑战型目标的实现上。几年时间孵化出十几个Nex系列技术组件,并已推广到全公司,在效率提升和降本增效方面做出了很大贡献。
(2)时间跨度不局限于一个OKR周期。
一个OKR周期通常是一个季度(Google推荐,OKR周期可以按实际情况制定),我们也将OKR周期设定为季度,但有些挑战型OKR在一个季度内是完成不了的。OKR的执行不是一锤子买卖,干完一个季度就清空,下个季度重新开始。对于一些预期跨度时间长的挑战型OKR(承诺型OKR也是如此,挑战型OKR这种情况会多些),可以在多个季度分阶段持续性跟踪,不局限于一个季度。
三、OKR执行过程中的调整
通其变,天下无弊法;执其方,天下无善教。——王通《中说》
3.1、执行过程中可调整
首先我们认为:OKR是目标管理工具,不是约束团队施展发挥的锁链。我们提倡团队在执行过程中灵活应变。在OKR的一个执行周期中,如果出现以下两种情况,需要考虑调整:
(1)实际进展与OKR偏差过大。
在OKR跟踪期间,团队要定期审视实际情况,如果执行进展与目标是逼近的,并且能够继续牵引团队正向前进,说明团队OKR处于健康的执行状态。如果有一天你发现团队在做的事和OKR没什么关系,那就要一起坐下来想一想:为什么我们偏离了目标?原来的目标是否还有必要继续跟进?是否要以当前做的事情为准,树立个新目标?
实际上,团队中会存在一些大家“拍脑袋”想的OKR,季度初很难完全规划好整个季度的所有工作,出现一些事与愿违的情况是正常的。所以当OKR目标与实际情况产生较大偏差,一定要及时调整,快速响应。

(2)更高的战略需要。
OKR为企业提供了上下协同的关联纽带,当更高组织的阶段性战略目标发生了调整,下面团队的目标要时刻与上级组织对齐,这种情况下也要做出OKR的调整。OKR不是不变的,敢于拥抱变化是务实的表现。
调整OKR以应对变化,这里的变化通常是指外部带来的变化,不是内部引起的变化,比如:迎接行业风口,转换新赛道。团队内部的变化还不至于影响到调整OKR,在团队执行前,内部需要建设好鲁棒性的组织梯队,保证团队具有充足的力量去支撑,这是团队执行前需要做的热身准备,具体可以阅读我们的《OKR之剑·实战篇02:OKR执行前的热身准备》。
不同层级的组织对于OKR变更的态度会有所区别:越高层级的组织调整OKR越需谨慎。高层级的组织OKR变动会产生连锁反应,牵一发而动全身,影响面太广。所以,高层级组织变更OKR需要充分验证、谨慎操作。相比而言,一线团队敏捷性更强,必要时刻可以灵活应变,进行调整,更快速地响应上级组织的需求。但是要强调的是任何团队的OKR都不宜频繁调整,过程中调整相当于否定了团队成员前期的一些努力,一定程度上会伤害大家的信心和积极性,所以调整前需谨慎评估。

3.2、OKR调整的要点
我们作为一线研发团队,对于执行过程中调整的要点也尝试做了些总结,这里分享给大家:
价值导向。
OKR保证团队一起在做有价值的事,当事情的价值在发生变化,OKR也需要随之变化。
协同。
当更高级组织或者企业的战略目标发生变动时,团队目标也要协同对齐。但这里不是给大家宣扬刻意盲目的“唯上”,只是建议眼界放宽,更多地关注企业共同的目标,也注重团队自身的成长。
定期审视。
团队需要有一套适合自己的OKR跟踪节奏,定期关注状态、进度,方向正确就继续执行,发现问题果断调整、及时止损。这里需要将团队的日常和OKR自然的结合,能够保持常态化的跟踪,更多内容可以阅读我们的《OKR之剑·实战篇03:OKR的跟踪需要有“自己”的节奏》。
不惧变化。
处于舒适状态下的团队可能不想去改变、去挑战,慢慢变得平庸,只想守着自己的一亩三分田。我们提倡不吃老本、不躺平,要做有挑战有突破的事情,拥抱变化。
四、疫情下的OKR执行
在疫情反复的当下,工作在一起的团队成员可能随时会变成“线上网友”。面对集体远程办公带来的消极影响(工作效率低、沟通不便、管理困难等等),我们要如何保证OKR的高效执行呢?
(1)团队早晚会。
远程办公时每天定时召开早晚会,这里并不是让大家频繁去同步OKR的进度,更不是增加会议密度。而是,一方面进行信息的同步,了解团队成员每天的工作进度、总结、风险等等;另一方面是希望大家多“见见面”,让每个人能感受到自己依然是和团队一起在工作,“早上一起开工,晚上一同收工”,增强仪式感,激活团队。毕竟,OKR的执行成功和团队每一天的工作是密不可分的。

(2)适合线上的OKR会议。
无论线上线下,团队原有的跟踪节奏应该保持不变,跟踪过程不应该被会议的开展形式影响。OKR线上会议的组织形式没有固定的模式,重点是保证信息的准确同步、讨论氛围的热烈活跃。

(3)团队温暖不打烊。
团队惊喜是我们一直坚持的,远程办公虽然不便,但OKR的激励不会因此打烊。线上工作间隙,我们会经常为每个人安排一些温暖福利。这些福利虽然价格不高,但对于提高团队的归属感和营造快乐的团队氛围却发挥着很大的作用。
总之,OKR的执行不在于形式,而在于团队感受。如果团队能够保持自驱自组织,条件不足那就创造条件,我相信没有团队一起克服不了的困难。
写在最后
本文介绍了OKR执行过程中的一些注意点,并分享了一些我们团队的经验,希望能给其他的团队带来一些启发,可以让OKR执行得更好。下篇文章我们会重点介绍OKR的致胜法宝:硬性的业绩和软性的氛围,期待与大家再次见面。
《OKR 之剑》系列文章:
OKR之剑·实战篇04:OKR执行过程优化的那些关键事的更多相关文章
- UI5-技术篇-jQuery.ajax执行过程中Token验证及JSON格式传值问题
最近两天在测试OData服务类方法CREATE_DEEP_ENTITY及GET_EXPANDED_ENTITYSET,刚开始采用ODataModel方式调用没有任何问题,但是ODataModel采用的 ...
- 精尽MyBatis源码分析 - SQL执行过程(四)之延迟加载
该系列文档是本人在学习 Mybatis 的源码过程中总结下来的,可能对读者不太友好,请结合我的源码注释(Mybatis源码分析 GitHub 地址.Mybatis-Spring 源码分析 GitHub ...
- OKR之剑(理念篇)02—— OKR布道之旅
作者:vivo互联网平台产品研发团队 1.我们是如何引入的 1.1.企业文化匹配 大概是在2013年底,一些创业者在硅谷深受OKR洗礼,并在自己的公司内小范围运用,以此OKR开始传入中国.而vivo初 ...
- OKR之剑(理念篇)01—— OKR带给我们的改变
作者:vivo互联网平台产品研发团队 一.前言 OKR即目标与关键成果法,起源于英特尔,在谷歌发扬光大.近几年在国内比较火,很多企业都相继引入了OKR的管理方式,小到2-3人的小微初创公司,大到十几万 ...
- 洗礼灵魂,修炼python(73)--全栈项目实战篇(1)——【转载】前提准备之学习ubuntu
本篇是为项目实战做准备,学习Linux是必备的,不然都不好意思叫全栈对吧?下面是一位资深大神写的文章,够详细,我也不用浪费时间再写了 原文链接:Ubuntu学习——第一篇 内容: 一. Ubuntu简 ...
- JS-正则表达式实战篇(Angel著)
JS-正则表达式实战篇(Angel著) 大家会看到我最新的系列博客都是spring boot怎么突然来了一个js的呢,而且这个貌似对大家而言好像很简单的嘛,所以在写之前我说说我写这一篇文章的初衷.公司 ...
- 算法---FaceNet在Tf下的实战篇
FaceNet---Tensorflow下的下的实战篇 @WP20190225 ===============目录=============== 一.FaceNet算法简介 二.FaceNet配置与使 ...
- 掌握SpringBoot-2.3的容器探针:实战篇
欢迎访问我的GitHub https://github.com/zq2599/blog_demos 内容:原创文章分类汇总,及配套源码,涉及Java.Docker.K8S.DevOPS等 经过多篇知识 ...
- Linux Capabilities 入门教程:进阶实战篇
原文链接:https://fuckcloudnative.io/posts/linux-capabilities-in-practice-2/ 该系列文章总共分为三篇: Linux Capabilit ...
- 二、Redis基本操作——String(实战篇)
小喵万万没想到,上一篇博客,居然已经被阅读600次了!!!让小喵感觉压力颇大.万一有写错的地方,岂不是会误导很多筒子们.所以,恳请大家,如果看到小喵的博客有什么不对的地方,请尽快指正!谢谢! 小喵的唠 ...
随机推荐
- TPC-DS工具介绍及性能测试
一. Hive-testbench工具介绍 TPC-DS:https://www.cnblogs.com/webDepOfQWS/p/10544528.html 由于原生态工具生产测试数据表存在bug ...
- socket链接和发送demo
Socker 包是创建客户端的,用于链接服务器: ServerSocket 包是创建服务器的,启动端口进行监听等待链接 socket客户端-----------------java.lang.Stri ...
- Aignize第一期完善产品逻辑+类图说明书
Aiganize产品说明+拟类图(第一期) ·附图: 此应用由: 前端:微信小程序前端+vue3后台管理系统后端:Springboot+Mysql 服务器:后端服务器+AI交互服务器 整个应用流程大致 ...
- SpringBoot项目中常见组件的配置属性
本文本的属性摘录自官方Properties配置清单,并附加了国内开发常用的框架配置属性.以国内WEB开发中,所涉及的常见组件为顺序组织配置清单 1. 配置属性清单 1.1 日志配置 序号 属性名 类型 ...
- [ARC161F] Everywhere is Sparser than Whole (Judge)
Problem Statement We define the density of a non-empty simple undirected graph as $\displaystyle\fra ...
- MyBatis高频面试题
1.MyBatis中使用#和$书写占位符有什么区别? 2.Hibernate 与 Mybatis区别(MyBatis与Hibernate有什么不同). 3.持久层设计要考虑的问题有哪些? 4.你用过的 ...
- Asp .Net Core 系列: 集成 Consul 实现 服务注册与健康检查
目录 什么是 Consul? 安装和运行 Consul Asp .Net Core 如何集成 Consul 实现服务注册和健康检查 Consul.AspNetCore 中的 AddConsul 和 A ...
- 12、FlutterMediaQuery获取屏幕宽度和高度
final size =MediaQuery.of(context).size; class HomePage3 extends StatelessWidget { const HomePage3({ ...
- spring-cloud-alibaba项目打包
在父依赖中加入 <build> <plugins> <plugin> <groupId>org.springframework.boot</gro ...
- 【DevCloud·敏捷智库】如何利用故事点做估算
背景 在某开发团队辅导的第二天,一个团队负责人咨询道:"领导经常管我要开发计划,我如何能快速的评估出预计开发完成时间呢,我们目前用工时估算,我听说过故事点估算,不知道适合吗?" 问 ...