背景, 公司最近在推OKR体系, 一些个人想法记录.

O (Objective) 做方向性的指引; KR (Key Result) 做阶段性的目标, 必须可量化 (所谓SMART标准, specific-measurable-assignable-relevant-time-based).

O和KR一起写, 为了啥O目标做啥KR事儿, 确保做事目的不跑偏.

OKR要求挑战性, 考核结果应当和绩效/利益分配无关, 但是实际上肯定是有关的. 感觉这个在执行上, 很看团队文化氛围, 很依赖团队每个成员的主观积极性, 自觉性.

一些实践问题的看法

问题: 对于O的设定, 到底能否量化, 还是只是一个方向性的陈述?

问题: 如果O可以或者必须量化, 那么KR的全部达成, 是否代表O的达成, O一定是KR的果? 或者另一面看, 如果其他非KR中的因素导致O的达成, 那么KR是否需要继续完成?

问题: 接上面一个问题, 假设O和KR的非必然关联性, KR层面评估比较好做没啥问题, 但是在O层面, 应如何有理有据的评估?

常见OKR举例:

• O: 销售额翻一倍
  • KR：订单数达到10笔，其中2笔必须由新的客户带来
  • …

这里的O是个简单粗暴可量化的目标, KR也是很量化的, 但是可能的结果是KR即便全部100%完成, O并不能达到. 也有可能KR全没达到, 但是由于种种原因, 如爆了大R, 接了笔大单子, O达成了. 那么对于订单的数量及新客户KR是否还应当继续?

一个O完成一定和全部KR完全对应的例子:

• O: 6月前完成X产品上线
  • KR 3月前完成产品调研
  • KR 4月前完成需求设计
  • KR 5月前完成项目开发
  • KR 6月前完成内部测试

感觉这只是一个很常规的计划, 以OKR的形式写出来. 而且所有的KR是由前置依赖性的.

对应一个我们自己实际的工作场景例子:

• O: 成本优化, 费用降低X
  • KR: 网络流量费用降低X
  • KR: 数据库成本降低X
  • …

这个例子里面, O和KR, 区别不明显, 只是简单的任务拆解. 成本来源算一算, 每块儿定个目标值, KR全部完成, 则O一定达成. 其实大部分财务业务定业绩目标的时候也是类似的, 大家抗的利润分一分, 简单粗暴, 简洁明了.

如果O本身只写”成本优化”, 那么是一个没有办法量化的O.

量化O好处: 易于考核. 缺点: 和KPI及分解貌似没啥区别; 此外, 在预测已经达到目标的前提下, 大家的主观能动性不足, 不够挑战性, 除非O的量化目标高到基本够不到.

另外一个问题是, 很多O, 其实是非常难以量化的, 如 提升用户体验, 提升开发效率, 提高人员素质, 等等.

O一般是上一级制定, 下一级发挥主观能动性, 来主动提KR, 共同商议. 从多层级来说, 上面一级的KR是下面一级的O. 从这个角度来说, O可量化, 更容易考核和执行.

另外一种写法

• O: 成本优化, 降低到X
  • KR: 数据库A使用优化, 降低一半实例
  • KR: 测试机器改成按需
  • …

这个写法里面, 所有的KR有助于O的达成, 但由于各种不可控因素, 即便KR全部完成, 也不能保证O的的实现. 但这样定KR的好处是, 更加明确, 可执行性强. 缺点是, 这样的KR, 实在是太难计划出来了!

问题: KR何时决定, 是否可以随添加或者调整KR, 合适考核KR?

一般OKR指导意见, 针对一个O的KR不宜超过5个, 那么是否限定了人的主观能动性, 比如说针对成本优化. KR是不可预测的.

我的看法是, 看团队规模, 不应限制KR的数量, 只要针对O是有正向作用, 以及和其他KR是兼容即可. 但是应该一定的时间周期 (如月/季度), 定期对KR进行回顾和调整, O相关的新KR点可以添加, 以作为一种承诺或者压力. 为了确保短期内足够聚焦, 一个周期内的KR视人数限制数量. 发现之前不work的KR点, 其实也不必要删掉, 或者调整, 如实回顾就好. 否则大家就随便定KR, 毫无不能完成的压力.

实践中这样操作: 每次只制定下一期的KR, 如Q1的, 然后Q1结束对于KR进行考核, 再定Q2的KR, 有点所谓PDCA (plan-do-check-adjust) 的意思. 因为O一般来说变动概率不大, 而KR, 如果要有实操性, 则一般短时的目标为佳. 订立半年甚至一年的KR, 除非预见性非常强才可做到.

问题: KR的粒度问题

一些细小的, 和O相关的点, 是否有必要在KR中体现出来. 拆得太细, 感觉是每期工作的罗列. 拆得太粗, 又缺少了一定失效/目标性. 例如:

• O 成本优化
  • KR 通过措施X, 将数据库A实例降到r4.xlarge (4月前完成)
  • KR 通过措施X, 数据库A实例降到r4.large (5月前完成)
• O 成本优化
  • KR 数据库A实例降到r4.large (5月前完成)

前者对于过程更为细化, 即便第二点未能完成, 也影响对于第一点的达成. 而后者则对于实施路径较模糊, 时间较长, 最终也难以达到.

这个办法是可以通过多层级KR来解决, 如

• O 成本优化
  • KR 数据库A实例降到r4.large (5月前完成), 对具体执行人来说算是个O
    • KR 通过措施X, 将数据库A实例降到r4.xlarge (4月前完成)
    • KR 通过措施X, 数据库A实例降到r4.large (5月前完成)

更细力度的拆分, 对应到更短的迭代周期内做进一步拆解.

问题: 对于O以及KR, 是否应该指派负责人, 能否指派多人?

我的看法是对于KR, 应该且只有一个负责人, 否则很容易成为三不管的地带. 对于O, 感觉比较模糊, 团队内的O一般一定是挂在团队负责人身上的了, 第一责任人应当是分管这一块儿的同事, 如果有的话. 但是感觉不利于发掘其他人的主观能动性, 因为觉得, 好这是你的O, 和我无关了.

对于可以继续拆解的KR (对下面是O), 指派多人, 没有问题. 但是到最终执行层面 (行话话叫叶子节点), 那么一定是应当分到具体人的.

问题: 不同KR打架问题, 例如:

• O 实现流水X
  • KR 实现流量扩大X倍
  • KR 实现单位流量收益提升X倍 (继续向下拆解):
    • KR 实现展示点击率提升X倍
    • KR 实现点击转化率提升X倍

如果KR是在不同负责组或者人身上, 那么可能流量的扩大会导致单位收益的下降; 严格提升单位收益, 可能会导致符合采买要求的流量减少. 同理, 但看展示点击率, 可能会导致通过诱导性的素材, 不利于点击转化率, 以及整体单位流量收益的提升. 这个是问题拆解的艺术. 不同KR责任人, 得始终不忘一个O, 并在这个基本前提下协作. 这个我觉得是OKR的好处.

TODO 如何理解OKR和绩效无关 ???

总结

• OKR = Objective and Key Result
• KPI = Key Performance Indicator

其实各种痛批KPI导向弊病, 鼓吹OKR的神奇, 不用过分在意. 我觉得OKR不要看的那么神奇, OKR中的KR, 甚至O, 其实和KPI差别不甚很大.

不过更常见的说法是, OKR和KPI是共存的, 为了解决不同类型问题的手段. 我的理解是: 对上汇报KPI, 对内执行OKR. 执行层面, O是相对长期目标, 对应的KR, 是为了实现这个长期目标, 从不同角度展开, 分阶段, 分人员设定的短期目标, 并定期回顾调整, 从而确保目的最终顺利达成.

不用纠结何谓O, 何谓KR, 如何将任务拆解分配, 以及调动人员积极性, 还是要跟据实际情况及时调整. 作为管理者, 要实现”上下同心, 力出一处”的结果, 重点还是要靠人的管理能力解决. 一套新的OKR制度, 只能一定程度上, 诱使目标实现. 技术上没有银弹, 管理更是如此.