购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

OKR制定流程

在本章中,我们已经指出了一个有效的OKR所应具备的具体特征,以及一些相关想法、建议和技巧。相信现在你一定迫不及待地想将其付诸实践,创建你自己的第一份OKR了。这一节我们将通过OKR创建的完整流程来指导你如何做到这一点,这个过程可以用一个十分方便的首字母组合词汇“CRAFT”来表示,它代表:

1.Create:创建

2.Refine:精炼

3.Align:对齐

4.Finalize:定稿

5.Transmit:发布

参见图3-5。

创建

一些专家可能会告诉你,要完成这一步,你需要召集你的团队成员聚到一起——无论是公司层面的OKR还是团队层面的OKR均是如此。先拿出一张空白标记纸,站在一张活动挂图前,大呼一声“开始”,于是就启动了一场经典的头脑风暴会议。很快,一个能引起大家广泛共鸣的想法被提出来,节奏之快超乎你想象。但我们不是这些专家,我们不建议你这么做。

图3-5 制定OKR的“CRAFT”流程

大型的头脑风暴已被广泛接受,成为很多公司研讨文化的一部分,但最近有研究表明该过程存在很多缺陷。让我们先从参与头脑风暴的人数说起,我们通常会相信一个堂而皇之的理由:把人们卷入到该过程中来意味着他们会更愿意接受和支持所创建的OKR。这可能是一个很有价值的理论,但却与社会科学家所呈现的事实相矛盾。社会科学家得出的结论是:群体规模越大,头脑风暴的结果越差。苏珊·凯恩(Susan Cain)在她的Quiet一书中描述了这种现象:

大约40年的研究得出了同样令人吃惊的结论。研究指出,随着群体规模的增大,大家的表现反而更差:与6人团队相比,9人团队产生的想法更少也更差,而6人团队的表现又不如4人团队。科学证据表明:在商业领域采用头脑风暴是一种愚蠢行为。

针对大型群体头脑风暴不能给出有意义结果这种现象,心理学家给出了几个原因,其中之一就是“社会惰化”现象,它表明:在一个群体中,总有一部分人在袖手旁观,什么也不做,而另一部分人却在绞尽脑汁。你可能已经在脑海中勾勒出了这些人的图像:他们低着头,要么看手机,要么看他们的便携电脑,仿佛和当前的讨论完全不相干一样。

为了避免大型群体头脑风暴的这个问题,我们推荐你采用一种完全相反的做法来制定第一份OKR草案,即小团队方式,一个很小的团队,很可能就2个人。上文提到的苏珊·凯恩是研究这一现象的后起之秀。她注意到,为了找到一个问题的创造性解决方案,人们需要深入而长时间地专注在任务上。试图期待由20个或更多人组成的群体放下手头的所有事情,花时间去制定一份OKR草案是不现实的。然而,如果是只有2个人的话,尽管这不可避免地也需要花费他们的时间,也可能对他们造成不便,但却更加可行。你召集的小团队可以投入所需时间以掌握创建OKR所必备的背景信息,包括:①分析你所处的竞争环境;②仔细审视你的战略;③确定你的核心能力,等等。如果你想在早期阶段卷入更多人,可以简单地让他们把关于OKR的想法通过邮件或问卷反馈给你,然后你的小团队再通过上面提到的问题过滤器(战略、竞争力、环境等),检视大家反馈的意见列表,把它们作为你产生更好想法的一个输入。

无论是公司层面还是团队层面,我们都建议你采用这种小团队的方式运作,生成2~3个目标,每个目标包含1~3个关键结果。这些OKR应该被制定得很有挑战(1.0分水准)以激发灵感。

精炼

你的小团队(也许是活力二人组)在这之前应当完成了OKR初稿,并提交给更大范围的团队成员评审了。这里有一个很微妙的点容易被忽视,所以我们决定稍作停顿来解释一下。提交给更大范围团队成员评审这句话很关键,确保研讨会参与人员为OKR讨论做好准备至关重要,所以我们建议你不要仅仅把OKR打包到一个电子邮件中发送出去了事。你的团队成员每天都可能会收到上百封邮件,这些信息很容易被淹没。而如果既通过邮件,又通过传统纸件形式分发,同时还附上CEO或团队领导的一封信的话,就会让这个过程显得尤为重要和备受关注。

关于谁应该参加研讨会这个问题,如果你正在研讨的是公司层面的OKR,那么公司的管理团队应当参加;如果你正在研讨的是团队层面的OKR,那么团队层面的管理团队就应当参加。会议的目的是仔细评审已经准备好的OKR初稿,让起草该草案的小团队向大家解释他们的考虑和选择,引发大家讨论(我们希望讨论越激烈越好),最终大家就即将投入应用的OKR达成一致。

作为该过程的一部分,每个KR都应当使用本章前面讨论的评分量表来制定KR的评分标准。你需要确保你的OKR终稿符合我们早前给出的特征,并直接体现你独一无二的战略诉求。至于时间安排,你可以先按一整天去预留,并尽量争取一上午就搞定。但你也可能确实要用上一整天,如果真是这样也不见得就是坏事,至少这表明大家都在积极地探讨和辩论。不过,如果你能提早结束就不要拖延时间,没有什么比让参会者提前结束会议更让他们兴奋。

最后再给一个忠告,这是我们基于和全球客户进行了成千上万个小时的研讨后的忠告:不要期望所有人都能就OKR达成完全一致。我们可以毫不含糊地告诉你,这实际上是不可能的。为什么?原因就一个,你会议室里的人不是僵尸,也不是机器人,他们独一无二的人生经历塑造了他们各自的观点和哲学,要让一组人就任何话题完全达成一致,比登天还难。事实上如果真做到了这一点反而不好,反对的声音有助于确保你的OKR被从各个角度审慎思考过。最后你必须对你们创建的OKR表示坚决支持,即使你团队中有一些成员并不是百分百地赞同某一个Objective或KR,但他们在公开场合也必须支持它们,否则一旦他们释放出负面信号,缺乏对整个OKR项目的信赖,对你而言就会很危险。你需要包容不同的声音和观点,但一定要促使大家像一个团队那样团结一致,支持并积极参与所创建的OKR。

对齐

现代组织中的大多数工作都是跨职能的,需要多团队协同解决所面临的问题或创造出新的工作模式,从而让多个业务领域都能从中受益。在团队层面制定OKR时,必须要基于这种假定来进行。

我们在前文中提到的小团队或动态二人组,应当把OKR初稿提交给其他团队评审,和这些团队的领导一起讨论存在依赖关系的OKR。也即是说,一方面你需要和你的同事一起讨论你所负责的部分OKR是如何依赖他们的,同时也要向其他团队分享你的独特定位,以帮助他们实现其目标,这是一个双赢的过程。

评分通常能帮助你评估你以及你的团队之间的依赖程度。你可能还记得,0.3分意味着你的团队无须任何帮助即可达到的程度,代表的是一般水平。如果你所定义的0.3和0.7这两个指标水平间差距非常大,那很可能就意味着这里面存在一个关键依赖。你和其他团队领导会面的目的,是要就依赖关系达成一致,并基于可提供的支持调整指标值。例如,如果你确定你的某个KR高度依赖于另外一个团队,那么你和这个团队会面的目的就是要让他们认可这种依赖关系,并承诺提供相关支持,这有助于你提升KR指标,因为你相信他们在必要时会给你提供所需要的支持。反过来,另外一种情况也可能发生,其他团队可能也会依赖于你们团队以达成他们的指标,这时你需要和他们一起探讨,如何才能为其提供帮助。

在这一步中,虽然你不希望对OKR进行全盘修改,但改变还是不可避免的。其他团队的新视角可以帮助你们发现和澄清目标中存在的潜在缺陷。一旦OKR刷新并汇总好之后,将它们发布给整个团队以再次征集大家的意见。此后除非变更遭遇重大阻力,否则就不用再进行面对面的交流了。

定稿

再强调一下,我们这里假定你创建的是团队层面的OKR,在这一步中,团队领导及其合作伙伴应同其上级(可能是高管团队成员)交流,以获准在下一个季度实施这些OKR。你可以提供一份概览,讲明:

1.你这份OKR是如何得来的;

2.你在起草OKR时所做的努力;

3.你和其他依赖团队达成的合作协议。

另外,让你的高管团队理解你选择的评分指标背后的理由也很重要。你肯定不希望你都有部分成果出来了,高管在那时才认为这不是他们想要的。

发布

在最后一步中有两个部分。首先是把你的OKR上传到一个软件系统,或者任何你认为合适长期进行结果跟踪的产品中(Google Sheets、Excel等)。这个过程确实很机械,但却至关重要。OKR必须予以严格和正式的分类并跟踪,以确保其完整性。在餐巾纸背面涂抹计算和构思想法可能会帮助你想出好点子,但当你准备通过若干季度的努力去超越竞争对手、成功执行你的战略时,这样做对你就帮助不大了。有很多高质量的软件供应商提供有这方面的工具,当时机合适时,你可以考虑购买一款。值得注意的是,软件应该始终被看作是一个使能者,而非必需品。我们在第5章会进一步讨论该话题。

其次是向你的团队成员和其他相关人员发布OKR。我们鼓励你使用多种媒介和大家进行广泛的沟通,但我们强烈推荐面对面交流的方式,比如全员会议或市政厅风格会议。这样做有很多好处,最主要的一个好处是,它为那些没有直接参与OKR创建的员工提供了一个交流机会,使得他们可以向做出OKR关键决策的人提问。给予员工这个机会可以让他们有一种公平和被倾听的感知,而这恰恰在很多场合缺失了。哈里斯互动公司(Harris Interactive)曾针对全球23000名员工做过一次调查,仅17%的人认为他们的组织鼓励坦诚的沟通,尊重不同意见以产生新的、更好的想法。 创新是成功企业的资本,如果OKR得以合适构建,可以很好地促进创新。但要做到这一点,每个人都必须理解你为什么要这样选择,以及他们应当如何为之贡献力量。这听起来有点像是在卖关子。是的,这就是我们的“且听下回分解”。我们将在接下来的第4章里告诉你如何自上而下地创建OKR,确保全员专注于做最重要的事情。 zt6X9JVbBWS0/hwLhjr0ztE1TvMzkSUSVaOvTNHXcjUElsAOI0YJYdCEcSntIfja

点击中间区域
呼出菜单
上一章
目录
下一章
×