* 英文书名：Radical Focus
* 作者：Christina Wodtke
* 读书时间：2018年11月
* 读书背景：所在公司开始实施OKR，感觉与之前公司使用的KPI还是有明显差别，但又不很确定差异在哪里，所以找本书来学习一下。希望明确以下问题：
   * OKR是什么？与KPI的差异有哪些（为什么用OKR比用KPI好）？
   * OKR如何实施？有哪些原则性建议和需要避开的坑？
* 内容简介：本书以一个创业团队为背景，讲述了OKR的概念与具体实施方法，并总结了一系列相关原则。以下笔记为抽出来的干货。

1. OKR是什么？

1.1 OKR的定义

OKR=O+KR
O=Objectives，目标（有挑战的、方向明确的目标）
KR=Key Results，关键结果（3-4个明确且具体的结果指标，且能确保O完成）；

1.2 OKR的特点（区别于KPI）

• 自上而下分解制定[icymoon注：分解OKR到部门的过程，确保公司的OKR可达成]；
• KR要能确保O的完成 [icymoon注: 人为刷KR指标，可能会对O造成负面影响]；

2. OKR的实施方法

2.1 操作流程

1）团队成员共计讨论制定OKR（接下来三个月/半年的目标和关键结果指标）；

组织所有团队成员，讨论得出1-2个关键OKR，示例模版如下：

2）逐级分解，公司OKR/部门OKR/小组OKR…，可以考虑拆分到每个人；

3）周期性评估OKR实施进展（周/月/季度/半年/年...）

每周依据OKR，评估进展情况和当前工作内容的优先级，并在团队内同步。示例模板如下：

4）庆祝关键进展达成

周期性Review工作进展和问题的同时，也别忘记庆祝进展，给团队鼓励，可以是小的展示会，相互展示阶段性成果，也可以是团建活动。这对保持团队氛围和状态很重要。
当然，也要注意控制庆祝的节奏。个人感觉最快以周为单位就够了。当然，团队Leader及时对下属工作进行反馈特别是表扬，随时要做。

2.2 指导方法

2.2.1 设定目标的原则

• 目标要明确方向并且鼓舞人心；
• 目标要有时间期限；
• 由独立的团队来执行目标（尽量避免相互依赖和扯皮）
• 目标要有挑战性（具体表现为有一半把握）
• 实施OKR之前，先要明确企业的使命

2.2.2 影响目标达成的5个常见因素

• 没有给目标设置优先级
• 缺乏充分沟通，导致团队没能准确理解目标
• 没有做好计划（任务分解很重要）
• 没有把时间花在重要的事情上（执行中跟随优先级）
• 轻易放弃（没有跟进目标很危险，需要反思和吸取教训）

3. OKR的6个使用场景

这一章，主要是书中一些 OKR 实践Case的总结，供大家参考。

3.1 场景1 如何开会讨论制定公司级的OKR

1）提前找人面向全员收集并统计最受欢迎的建议
2）每个高管带1-2个建议参会
3）汇总高管与员工的建议，并展示
4）讨论->辩论->争论->投票排序 ==> 得出三个目标；
5）Brain Storm，自由列举所有能衡量目标的指标（先讨论衡量什么比较容易，再讨论具体的值）
6）对5）归类并统计，找到能保障目标达成的指标是什么（目标通常都能覆盖用户指标、收入指标和满意度这三类关键结果）
7）给每个关键结果设置具体的目标值，确保OKR有挑战
8）最后5分钟确认最终的OKR

• 是否让人受鼓舞并觉得有挑战
• KR是否有意义，是否能保障O的达成

3.2 场景2 服务部门的OKR如何和公司目标关联

这个场景，书中举例说明了一个研发经理如何制定了帮助销售团队实施目标的 OKR。笔者看来，主要有以下几个方法可以借鉴：

• 管理者们一起商量制订 OKR，效果会更好（比如，支持部门的负责人要与被支持部门的负责人达成一致）
• 通过讨论和提问，逐步明确目标，特别是可量化数据，比如服务部门的目标，通常是支持xxx团队实现目标，那么，就要从这个方向来逐步求解：
  • 怎么去确认的确支持了xxx工作？可以举一个确实支持目标实现的例子？
  • 解决歧义描述，让关键结果更明确
  • 确认历史数据，来考量现在的关键结果是否可衡量
  • 反推关注这些关键结果，是否真的能实现目标
  • 校准边界条件，比如xxx情况下是否算 OKR 达成
  • 最后，要确保关键结果是个积极的描述

关于这种场景，笔者还有一点补充，在稍微大一些的公司，不少 OKR都可能是需要不同部门共担的，这就容易出现大家都负责，等同于没有人为没有达成 OKR 这件事情负全责，这点该怎么办呢？

• 需要管理者有好的目标分解能力，OKR 分解到下级组织后，能边界清晰，且能确保当前这一级的 OKR 达成
• 如果发现确实无法拆分清楚，可能要考虑调整组织架构了，通常组织边界应该划在耦合度最低的地方

3.3 场景3 全公司的各级OKR如何设定（包含部分场景1的内容）

标准流程如下：
1）所有员工提交他们认为这个季度公司需要实现的目标。
2）管理层用半天的时间讨论 OKR。
3）管理层作业：向各自主管的部门介绍公司季度OKR，并完成每个部门的 OKR 设置。部门经理和成员通过会议，自由列举目标、归类分组关键结果、投票排序，做出最后的选择。
4）CEO 确认部门 OKR，如果发现有的部门对 OKR 理解有偏差，再和部门进行讨论。[管理层要确保各部门 OKR 达成，能保证公司 OKR 达成]
5）自上而下关联。部门经理在把公司和部门的 OKR 传达给下级子部门时，再用同样的方法制定各自的 OKR。
6）个人 OKR（可选）。个人 OKR需要其经理确认。设定&&跟踪个人 OKR 的执行可以使用一对一沟通的方式，这是也是一种不错的指导方式。
7）全体会议。CEO 向全员解释 OKR 是什么，为什么这样设置，然后对其中几个进行示范性的拆解。解释时要涵盖上季度的 OKR 总结。会议气氛要积极。OKR是一个不断反思和迭代的过程，不用怕失败。

对于第一次实践 OKR，有三种方法能减少理想破灭的风险：

• 全公司只设置一个 OKR
• 全公司实施前，先用一个相对独立的团队去尝试
• 也可以尝试用 OKR 做项目管理，先让员工理解这个方法并养成习惯

3.4 场景4 在产品研发过程中使用 OKR 思想

首先，要求每个人在提出新功能时，都要要搬一个清晰的目标和一系列关键结果（可以理解为列成 OKR 模式），用来帮助大家更好的理解为什么要做，有多渴望做。
接下来，在产品迭代的每个生命周期里，使用看板做敏捷开发的日程安排，所有潜在 Issue卡片放在待办事项，开发人员挑选出来要做的，移动到正在进行，再到完成。所有的 MVP 都在看板上，并且包括标准化的描述、具体需求、原型草图等。
注意，这里每一个重要Issue都要回答清楚两个问题：1）通过这个功能我们试图达成什么目的？2）我们怎样衡量项目的成功与失败？
同时，有一个tricky的地方，是编写MVP卡片时，把 “O（目标）”换成了“假设实现了这个目标”，鼓励研发人员开阔思路来做。

上面这个实施方式看起来够好了吗？No~~~

一是明确的 OKR 要和产品的前期调研工作配合使用；
二是有了这样的 OKR Issue，还是需要做优先级排序的；
三是产品本身的 OKR 要结合公司的商业目标进行；
四是在跨部门协作中，也要应用相同的框架来对齐，更容易沟通，也可以激发更多建设性合作；
五是类 OKR 的阶段性反思和总结，也是必须的。

总之，这样的 OKR式的产品迭代管理，可以有效地进行优先级排序，跟踪进度，评价结果，总结反思，并且建立良好的沟通习惯。

3.5 场景5 使用OKR改进周报

在写这个场景前，先说一下周报的意义吧。因为，我估计很多人，都不喜欢写周报，估计更没人喜欢看周报 :-p。

• 给管理者看：
  • Manager可以通过周报知道每个人做了什么，将要做什么，有什么风险；
  • Manager可以根据这些信息，考虑是否要调整团队/成员的工作优先级，要协调什么资源来支持团队工作，有什么风险超出了团队/成员的处理范围要介入处理；同时，也是阶段性工作产出的评价依据之一；
• 给同事看，看同事的：
  • 协作的同事也可以彼此知道那些要协同达成的重要目标有什么进展，有什么要同步配合；
• 给自己写，给自己看；
  • 周报也是个人总结和反思工作的好时机：我这一周是否朝向目标有了实质性的前进，我是否在重要的事情上花了足够的时间，我遇到什么困难和问题了
  • 写更长时间阶段的工作总结时，周报也很有用：比如，当我申请promot时，我能通过周报提炼总结出自己的工作内容和价值。
• 看自己团队成员的：
  • 及时了解每位同学的工作进展/计算，问题和风险，提供有效地指导帮助；
  • 发现团队中协作不顺畅的地方，协调沟通，信息对齐；

由此可见，周报是组织多维度沟通的有效工具，也是基础的管理工具，更是自己的总结沉淀。那么，如何用 OKR 来改进周报呢？这里介绍一个周报模板：

1. 列出所有的 OKR 和信心指数，并把信心指数标记不同的颜色，比如红黄绿灯（提醒每个人为什么要做现在的事情）
2. 列出上周的优先任务，并标完成情况，如未完成，标注原因（可以让团队了解进展，以及什么阻止了团队的前进）
3. 列出下周的优先任务（通常三个就够了，要具体全面，比如，确定 X 项目的设计文档）
   //这里也可以加几个不那么重要的事情，但要值得下周做的且下周能完成的；
4. 列出风险或阻碍（无法独自解决的问题、控制风险）
5. 备注（要简短、及时、有效）

3.6 场景6 避开OKR常见的坑

这些 OKR 的大坑，如下：

• 设置了多个目标（Google 可能需要，但大多数公司不需要）
• 设置 OKR 的周期过短--一周或者一个月
• 用绩效指标来驱动目标的完成（目标本身就是鼓舞人心的，要让目标来驱动业务绩效，唯 KPI 论要不得）
• 没有设置信心指数（ OKR 是要鼓励团队挑战目标）
• 没有追踪信息指数的变化（跟踪执行很必要）
• 把每周例会当作汇报，而不是谈话（OKR 执行中需要讨论问题）
• 没有庆祝节奏，过于严肃（团队即使还没有完成所有 KR，也该为追求卓越自豪）

4. 最后的建议

4.1 如何恢复目标的魔力

从重构目标开始，不要把它变成绩效考核的工具，目标应该着眼于如何鼓舞和激发成员。这意味着要改变团队目标的制定方法、推动节奏和表现形式。具体这样做：

1. 用目标来定义和驱动 成功，目标要务实、明确，让团队聚焦。（这里书里提供了一个数据，只有7%的人真正理解目标……笔者感觉低得不可思议）
2. 别把绩效评估和 OKR 挂钩（OKR 让人挑战极限）
3. 实时追踪目标进度，让团队聚焦，让成员自我驱动
4. 在邮件中沟通目标（本质是让成员在很短的时间内找到自己和团队的目标）
5. 自上而下的目标设置兼顾自下而上的成分

4.2 如何评估绩效、升职与加薪

持续沟通而非一次性评估，每月至少2次一对一交流，指导和校正，内容包括投入度，绩效水平与协同能力。需要管理者和员工各自分享观点，讨论问题如何快速改善。
这样，年终的评估只是日常交流的一个延续。

4.3 使用 OKR 的最后建议

• 只设置一个公司级别的 OKR，除非 公司有多条业务线；
• OKR 的时间长度至少三个月起；
• 目标里不要有传统的绩效考核指标，要能鼓舞人心
• 每周盘点时，先从公司 OKR 开始，然后沟通部门级别的，个人 OKR 要一对一沟通；
• OKR 自上而下关联，按照公司=>部分=>个人的顺序设定；
• OKR 不是唯一一件要做的事情，而是必须要做的事情；
• 周一 OKR 进度确认是一次谈话，不是汇报或指标，要讨论信心指数、状态指标和优先级变化 ；
• 鼓励员工对公司的 OKR 提出意见和建议，让所有人都能参与其中；
• 把 OKR 公开
• 周五庆祝，可以让团队保持乐观积极；