乍看起来，OKR显得特别简单：决定你要做什么，以及如何知道是否做成功了。然而，真正创建和实施OKR前，还有很多功课要做。前面我们讨论了“你为什么要实施OKR”这个话题，这一节我们再探讨另一个话题：“你准备在哪个层面实施OKR？”我们给出了一些选择供你参考。

仅在公司层面实施

对很多组织来说，这可能是最合理的选择。从公司最高层组织开始实施OKR有很多好处。它清晰地传递了组织最关注的是什么，代表管理团队展现了承诺和责任，可以为以后在更低层级组织实施OKR提供方法借鉴。这样做可以让公司快速平滑地切换到OKR上来，同时也给员工一定时间去消化这个概念，帮助他们理解OKR是如何帮助公司取得更大成功的。关于“平滑推进”这个概念确有其科学依据，被称为未来锁定（Future Lock-in）[1]现象。行为科学家托德•罗杰斯（Todd Rogers）和马克斯•巴泽曼（Max Bazerman）用这个术语描述人们更倾向于认同那些在未来某个时刻一定会推行的变革（假定这个变革同他们的价值观是一致的）。4尤其当你过去曾遇到过类似的变革阻碍时，这种平滑切换方式就更有优势。因为你仅仅在公司层面推行，它对员工的影响也最小。随着你逐渐展现OKR所带来的早期收益，员工会慢慢接受这一理念。

如果你选择从公司层面开始推行OKR，那么高管是这个项目能否成功的关键，没有高管的支持，项目从一开始就注定会失败。同时，你还需要有热情的OKR斗士来推动项目，以此向整个团队证明它不是昙花一现式的赶时髦。

公司层面和业务单元/团队层面都开展

一种更加雄心勃勃的做法是：在公司层面和业务单元/团队层面都实施OKR。这里的业务单元/团队指的是直接向高管汇报的那层组织，可能不同公司的叫法会有所不同。具体实现上，公司和业务单元/团队等层面并非同时开展，而是更希望先制定公司层面的OKR，在它被广泛沟通后，业务单元/团队才制定自己的OKR，以体现同公司目标的一致性。

这种做法很重要的一点就是，一定要确保公司层面的目标是经过仔细甄选并被大家深刻理解了，因为它们是业务单元/团队OKR的关键输入。再说一次，高层主管的赞助至关重要。另外，这种方法需要你做一些事前准备工作，在你让业务单元/团队创建其OKR前，你要给出一些关键指导原则，如：

（1）Objective或KR的最大条目是多少？

（2）相关专业术语如何理解？

（3）如何评分？

（4）……

我们会在详细讨论这些主题。

整个组织都实施OKR

这是你的终极归属：在公司层面、业务单元及个人层面都实施OKR，确保从上到下对齐一致。问题是，需要多长时间才能做到这点呢？因为你试得更远，在更基层组织应用OKR，所以前面章节中列出的问题在这里也存在，而且还被放大了。除非你的组织足够小，否则我们不建议你从一开始就这么做。这并不意味着你要花费数年才能达成这个目标，一旦你在某个层级成功实施了OKR，就可以进一步推动其在更大范围内应用，直至整个组织都完全拥抱OKR并成为你组织文化的一部分为止。具体什么样的开展节奏合适，得由你来判断。

仅在业务单元/团队层面试点

为了降低推行风险，一些组织可能会选择先在业务单元层面/功能部门层面试点的做法。他们试过试点证实OKR理念的可推行性，通过速赢吸引更多的人加入试点行列。这种方法需要一个深刻理解OKR内在工作原理、深信OKR能带来切实业务结果的领导者来领导（相当于是另外一种形式的赞助，只是层面低一些）。如果试点确实能达成速赢，它就会获得其他团队的广泛关注，从而争相效仿试点团队的做法。所以试点团队在OKR选择上非常关键，他们的OKR必须是可达成的。如果选择了一个遥不可及的目标并在该目标上惨败，这无疑会吓跑那些原本就害怕做这件事情的人。

在项目中实施OKR

这是另外一种平滑切换到OKR的方法。不是在公司层面或业务单元/团队层面，而是在你最大的项目中推行OKR。找出该项目的目标，然后制定相应的关键结果去跟踪项目并确保其成功。这种方法可以帮助把OKR理念社交化，创造出一个流畅的术语交流环境，同时提升你的项目管理纪律。我们认为这可以作为一种备选方案，但绝不应成为绝大多数组织的首选。任何你投入了时间和精力的项目，都应该同公司的整体战略（以及愿景和使命）建立联结。在这种情况下，你会更倾向于在公司层面应用OKR以加速战略执行，并最终将OKR推行到整个公司。

[1] 罗杰斯和巴泽曼把未来选择更多反映的是人们的理想自我的现象称作“未来锁定”。一些研究指出：人们的远期选择更符合理想自我，而近期选择更多反映的是现实自我或欲望自我。

特殊情形

这一节里，我们会用到术语“团队”以及“业务单元”。但是，重新定义创建OKR的“团队”，并不仅仅是一项重新构建你的组织结构练习。让我们来看两个OKR实施的通用场景，以帮助你定义OKR“团队”。

两个团队共用同一组OKR

当两个团队间存在业务合作关系时，他们可能会共用一组OKR。例如IT团队可能是垂直组建的：IT销售运营团队、IT财经团队、IT市场团队、IT产品团队等。在这种情况下，不是让每个IT团队或者业务团队单独创建其OKR，而是让他们联合去创建一组OKR。业务团队在创建OKR时，相关的各IT团队被卷入制定过程中，以确保OKR是可行和易于理解的。这样，从一开始两个工作上存在相关性的团队所制定的OKR天然就是一致的。该模式同样适用于财经性质的集团组织。

其实，不仅IT团队和财经团队可以采用这种模式，公司其他团队也可以这样做，这取决于你所在的行业和组织结构。例如，在软件领域，产品团队和开发团队通常是紧密协同的，虽然各有独立的团队领导，在组织结构也是两个截然不同的部门，但如果它们之间的依赖关系比较强的话，也可以联合起来只创建一份OKR。

多个团队共用同一组OKR

一些组织需要多个团队共同努力才能取得成绩。我们在一个中等规模的高科技公司里就遇到过类似情况。他们不是采用每个团队单独设定自己OKR的做法，相反，他们组建了五个小分队去分别达成他们五个关键举措。每个小分队都有自己的一组OKR，而分队成员则来自不同的团队，这样，一个小分队可能会包含四名工程师、两名设计师、一名市场分析员、一名财务经理和一名产品经理。

我们基于实际客户经验以及调查研究，给出了如上两种OKR部署方案供你参考，也许还存在更多的联合创建OKR的方式，只是我们这里没有列出来。但正如前面所说的那样，不管你采用哪种过渡方式，你的最终目标都应是在整个组织内全面实施OKR。只是，在通往这个终极目标的过程中，你应该有足够的耐心，在时机上也要注意把握。最重要的是，要从一开始就克服惰性，先行动起来，万事开头难！出了几种OKR部署方案。