OKR 最差实践

OKR 实践一年多了,最近在看《OKR 工作法》,发现真是每一步都踩在 badcase 上。所以写了这篇博客,作为读这本书的总结,也作为 2019 OKR 实践的总结。


双月 OKR

头条实行双月 OKR,也就是每两个月定一次 OKR,当然也是每两个月做一次大的总结。我能感受到的方式是:

  1. 涉及跨团队合作的情况下,双月中/末,会和多个团队沟通,一起讨论下个双月的 OKR,保持目标和优先级一致。推动目标完成最好的方式就是让别人认可自己的 OKR,并成为他的 OKR。
  2. OKR 是双向的,会自下而上,也会自上而下。这个和书里提到「OKR 是自上而下关联的」类似,不过在实践中又多了一个维度。
  3. 技术团队的 OKR 和产品数据挂钩。书里「场景2:服务部门的 OKR 要和公司目标关联」这节写得很清楚,技术、产品、设计等团队,每个优化方向都是不一样的,但最终都会体现在产品数据上(比如 DAU)。如果公司方向是提高产品数据,那么每个团队的目标,都应该围绕这个去展开。
  4. 注重 ROI 与指标量化。对齐目标的时候,听到对多的是“这个预期收益是什么”,“这个收益怎么看”,“这个 ROI 是多少”

无法达成目标的因素

这部分主要介绍了五点,大部分都踩过 😥。根据个人感受,合并了几点。

没有给目标设置优先级 / 没有把时间花在重要的事情上

在 2019 年中制定 OKR 的时候,被问到几句话:

  • 你的目标太分散,盘子太开,收敛一下
  • 如果让你这个双月就做一件事,你做什么

这个对话发生在上一个双月目标进展不理想的情况下,再回头看那个双月,我对齐了四个目标,并且每个目标相关性不大,KR 加起来有十个以上。最后的结果是,在一个 O 上有一定进展,而 ROI 较高的 O 几乎没进展。

另一个问题是「没有把时间花在重要的事情上」,这点是同事遇到的 case:每天被很多事情打断,而且这些事情都不是我的目标。当时 Leader 给到的建议是,可以多看一些时间管理相关的书。

“重要的事通常不紧急,紧急的事通常不重要”。—— 德怀特 · 艾森豪威尔
重要 - 紧急矩阵是一种常见的时间管理工具,多数人能排除不重要也不紧急的事,却很难摆脱不重要但紧急的失误。
人们通常会选择去做紧急的事,不管是重要的还是不重要的,因为我们对时间压力太敏感了。

对于这个问题,我的解决方案是:

  • 先解决紧急的事情,毕竟对于研发来说,紧急通常意味着线上事故,没有什么比线上事故更高优的事情了
  • 沟通问清楚 deadline,并提前将 OKR 的 TODO 细分,高优 TODO 未处理完之前,其他事情暂缓。这个场景通常是需要了解某件事情上下文
  • 如果某类事情多,而且紧急,建议将这类事情列入 OKR。并找到为什么不能提前规划,每次都要高优插入的原因

缺乏充分沟通,导致没能准确理解目标

缺乏沟通,或者认为对方已经明白不再需要反复沟通,这种情况在实际生活中很常见。书中的例子是:

“你有没有跟他说过,让他承担好自己的角色?”
“有啊!”她想了一下,继续说:“应该算是说过了,我和他讲过他是在浪费时间,我觉得他知道我再说什么。”实际上汉娜用“总裁”挖苦过杰克,这和明确的支出杰克没有做好本职工作还是不一样的。

表达不够明确造成的双方差异,会在后续再次对齐目标的时候体现出来:

  • 风险后置,再次对齐的时候,可能是一周以后。比如,进展同步发现做的事情已经和预期的不一样了
  • 容易引发争执和不满,双方都认为是对方的问题,恶意揣测。比如,我意思这么简单你都不懂?这还用猜吗,只有可能这样

要解决这个问题,首要就是保持沟通,沟通完以后,至少要明确:事情本身,负责人,交付时间。而需求评审中,用例评审就是很好的固化需求的方式,保证 PM、RD、QA 大家理解是一致的。

之前对很多团队的用例评审进行过调研,部分团队觉得过于形式化,也有团队觉得这个环节就是在给产品细化需求,初稿逻辑不清晰,把细化的负担交给了研发和测试。但绝大多数团队,还是觉得一定的用例评审是有必要的,如果初稿逻辑不清晰,正说明了需要更多沟通。用例评审将这个问题提前暴露了出来(当然,需求过于笼统,应该直接打回)。

没有做好计划

计划,不仅仅是如何把 OKR 制定出来,还需要周期性的重新审视目标,比如:

  • 对目标感到疑惑
  • 对进展不满意

轻易放弃

需要克服畏难情绪,OKR 鼓励有挑战,比如书中提到的 50% 的完成信心。但这样制定是为了持续突破,而不是给放弃一个理由。

周会

想起之前和翻译组的朋友聊天,他们戏称头条是碰碰车乐园。有任何事情,开口就是我们拉个会碰一下。当然,这并不坏,无论说头条是碰碰车乐园还是拉群文化,根本都是为了高效沟通,提供更多的 context。但这里想说的是我刚入职的时候,参与的一周五次的周会。

这五次周会,参与的团队不同,沟通的对象不同,周报格式不同,需要突出的重点不同。但有一点是相同的,就是时间特别长,在 1h~2.5h 之间。可以说很大一部分时间都在准备开会和开会上了。但其实注意力是有限的,而且大家每天的事情也很繁杂,所以开会的时候,大多在干自己的事情。开会想要沟通交流、信息同步的目的并没有达到,反而造成恶性循环。包括开会需要写的周报,也没有重点,这个会在后面提到。这样进行了小半年以后,终于周会下降到了一周两个,但对于有用信息的提取,还是比较有限。

书中所提到的「周一制定计划,周五庆祝成果」在大的团队中,比较难实现。建议是分小组或者专项,一般三五个人。如果几个人的目标是一致的,就可以作为一个小组。我也看到过别的组在周会的时候,拿着一堆零食进会议室,估计就是在庆祝成果。会觉得这样的团队,氛围更加活跃。提供一个轻松的环境,也有助于“坦诚清晰,不自嗨”,把工作中真正的问题暴露出来,促进沟通。

如果不想在团队中推行这种周会方式,也非常建议个人用这种方式进行总结。周期性的总结,能更好的暴露问题,确保不偏离目标,甚至是及时发现目标的合理性。

周报

周会多,那么周报也多。在「场景5:使用 OKR 改进周报」这一节中,描述的场景深有体会:

上司要求我,“写一份周报,内容涵盖你的团队在本周做的所有工作,以后每周五都要提交”。你一定能想到我当时的感受,我不得不去证明我的团队正在努力工作,去证明我们存在的意义还不够,还要证明我们需要更多的人。
所以我跟其他很多人一样,列出了每一件事情,可是除了流水账没有任何有价值的内容。然后我开始要求下属,让他们按照我的格式把他们的周报发给我,我把它们汇总成一个“又臭又长”的大文档。

当然,作为一线码农,不需要证明“我们需要更多的人”,更多的是证明自己真的在做事情。这两点体现在周报上是一样的:流水账。

事实上,我们周会多次提到:大家的内容太散,不够聚焦,没有突出目标,没有突出问题等等。周报的格式也一改再改。对于不同的会议或总结文档,内容侧重点不同,当然格式也不一样。我在公司内文档中,搜索“周报”关键字,看到了很多周报格式。主要分为两类:

  1. 小组周报,内容是 5 ~ 15 人的工作进展
  2. 团队周报,内容是 50 ~ 200 人的工作进展

小组周报偏单点,比如修复了 xx 问题;和 xx 团队沟通 xx 事情。而团队周报更注重目标,在这个目标下,本周主要有哪些突破性进展,关键进展高亮标记。

在我看来,周报不同的写法,主要看参会者是否清楚你的目标。对于相同目标的人来说(比如技术方向相同),更应该突出进展,及时发现问题与风险。当目标拆分到具体要做的事情,其实每件事都是很单点的,加上日常迭代与问题修复,实际上专注开发的时间并没有想象的那么多。对于团队(包含多个技术方向)来说,主要是突出目标的关键进展,横向去看每个技术方向的成果与问题。当然,跨团队或者跨方向还需要突出几点,比如关键问题修复方案、最佳实践、遇到的疑难问题,可以促进团队间沟通和技术成长。

想起 CEO 面对面的时候,有人给一鸣提问:有的团队一周五天,三天写周报,一鸣怎么看这个问题。最开始我也觉得这事情挺恶心,每周进展到处写,无数次同步。后来思考了一下,对自己来说,希望看到别人的周报是什么样的,怎样才能获取有效信息,其实这事就理解了。比如,在周报中没头没脑写一句:将 xxSDK 升级到 3.0,这就完全不考虑受众。

书中在这一节给出的方案是:

  1. 把团队的 OKR 作为开始,并标注完成目标的信心指数
  2. 列出上周的优先任务,并标注完成情况
  3. 列出下周的优先事项
  4. 列出风险和阻碍
  5. 备注

文字描述不是很直观,结合书中例子与在实践,以下两种形式比较满意:

这种形式每周会更连续,但表格太多也容易缺乏重点。

最后

2020 年,也用 OKR 的方式管理自己的生活,希望 2020 最后能交一份满意的答卷。也欢迎各位给到自己对于 OKR 的看法,或者一些实践经验。