YouTube|谷歌、亚马逊、YouTube的管理利器，适合创业公司吗？( 四 ) 低薪|中薪|亚马逊|谷歌|创业公

谷歌一般会在一年的11月和12月，各个团队和产品部门分别制订未来一年的计划，并将其凝练为OKR。次年1月，还会回过头来复盘上一年的OKR，并在公司层面明确这就是最高战略，按照谷歌的传统，高管团队还会对公司的OKR进行评分，进而明确找到那些没有达标的部分。
在接下来几周甚至几个月的时间里，成千上万的谷歌公司员工将会制定、讨论、修改团队和个人的OKR，并对其进行评分。员工拥有浏览公司内部网站的权限，以便于他们了解其他团队如何衡量成败。他们也可以追踪自己的工作是如何与他人的工作联系在一起的——如何融入公司的整体战略。
如同李想说的，OKR是一个组织建设工作，它不是业务，所以O必须一把手亲自参与、亲自做，只要老板做、高层做、总监做，所有的员工就一定会跟着做。时至今日，李想也一直在坚持，日报、周报、OKR都是第一个更新的。
4
OKR的错误示范
OKR的一大用处是，通过讨论来确立目标，并且明确想要实现这个目标所需要的步骤、人力、物力，所以也就很容易判断出每个员工提供了什么价值。
所以OKR天然适合人才密度很高的科技互联网企业，它是管理聪明人的利器。但对于充斥大量一般性事务、流程性岗位的传统组织而言，OKR有时反而会造成混乱，因为“屁股决定脑袋”，传统组织架构中的中下层员工未必能在一定高度看到全局，所以这时候更适合的管理方法可能是KPI。
OKR的一种失败情况是，当目标（O）是通过顶层规划好，再层层缓慢传达下来时，由于缺少经常性的更新，O长期不变，或扔在一边无人问津，或退化为机械的KPI，最终成为没有意义的数字。
我们通过两个完整案例，来剖析OKR的实战过程中，前人走过的坑：
这两个案例都来自硅谷创业公司减肥宝，但是在不同发展阶段所面临的问题。第一个案例是公司发展初期，遇到的问题是如何创建正确的O，与KR在传达和协同中的问题。减肥宝的创始人阿尔伯特·李在复盘OKR时说：
当我们开始实施OKR时，远比预期要困难得多。我们之前没有意识到做下面的工作需要花费多少心思：创建正确的公司目标，然后对目标进行分解，再层层建立关联，并激励员工的行为。我们发现，在高层次、战略性思维和更细致的指令沟通之间取得平衡，是很有挑战性的。
自从我们获得了A轮投资并扩大了领导团队的规模之后，我们工作的领域也就随之扩大了。在推动问责制的过程中，我们为每位领导者都设定了一个宏大的目标。我们也为员工创建了公司的OKR，但不是直接将员工与我们的OKR进行匹配——这么做是不进反退的。有些目标太过狭隘，而有些又太模糊。很快，我们有了一大堆的公司OKR，但是对公司来说，最重要的是什么？我们得到了树木，却失去了森林。
当公司的人数从10人增加到30人的时候，我认为生产效率会提高200%，但我低估了规模的扩张减慢效率提升的程度。由于工程师团队每周都要在不同的项目之间进行轮换，这大大降低了他们的工作效率。在每次中断之后再重新回到特定的产品项目时，他们不得不问自己：如何重新开始？从公司的经营收入来看，升级软件版本的工作尤为紧迫，但开发工作却不得不时断时续。
我感到超级沮丧，我们雇了这么多有才华的人，花了那么多钱，但公司却没能走得更快。市场部的OKR是利用个性化电子邮件进行定向推送，这成为公司的重中之重。我们的目标是精心设定的：希望将一定数量的当月活跃用户推到我们的博客中。其中，一个重要的关键结果是通过电子邮件增加点击率。但问题在于，市场营销部门中没有人想到需要通知工程部门，而工程师们也已经设定了他们自己的当季优先事项。没有工程师的支持，这个OKR在开始之前就注定要失败了。而且更糟糕的是，直到这个项目死掉，阿尔伯特和我都没有发现它注定会失败——这个项目在一个季度后就下马了。
这次失败给我们敲响了警钟。我们发现：团队之间需要更多的协同。我们的OKR系统设计得很好，但在执行方面却出现了短板。当各部门需要互相依赖以获得重要支持时，我们却没能及时明确各部门之间的这种依赖关系。协同有时也像是碰运气，经常需要在规定的期限内完成。我们并不缺少目标，但我们的团队一直在不断地相互背离着。
在接下来的一年，我们试图通过为执行团队定期召开会议来解决这个问题。每个季度，部门的负责人都会提出他们的目标并确认相互之间的依赖关系。在一些最基本的问题得到答案之前，没有人会离会，比如我们是否满足了所有人的需求？团队是否扩张过度？如果是这样，我们如何使他们的目标更贴近现实？