OKR 和 KPI

前言

OKR 和 KPI 对于大家应该都是耳熟能详的绩效考核方式，因为部门在推行 OKR 和 360 度绩效考核，我阅读完《 OKR 工作法》这本书后在组内也做了分享，结合我们小组的实践过程记录下自己的心得体会，我也非常赞同左耳朵耗子大大的观点: 绩效分应该打给项目，打给产品，打给部门，打给代码，而不是打给人。

OKR 和 KPI

更新历史

2019 年 07 月 12 日 - 初稿

阅读原文 - https://wsgzao.github.io/post/okr/

扩展阅读

SRE 和 DevOps - https://wsgzao.github.io/post/sre-vs-devops/

OKR 和 KPI 的概念

OKR （ Objectives and Key Results ），目标与关键成果法。从概念上能看出，OKR 本身是一种目标管理方法，用以评价员工是否称职，并不是绩效考核工具，一般不和工资挂钩。

KPI （ Key Performance Indicator ），关键绩效指标。是一种衡量员工表现，以及管理公司整体绩效的工具，和员工收入直接关联。

OKR 工作法

一句话讲清楚 OKR 核心：制定一个较长期的目标（ Objective ），并且将目标分解成为一些关键的结果（ Key Results ）

《 OKR 工作法》推荐一种四象限的 OKR 展示形式：

本周关注的任务：列出 3~4 件最重要的事情，只有本周完成了这几件事情，团队的目标才能向前推进；明确这些事情的优先级。

未来四周的计划：有哪些事情需要其他团队成员做好准备或支持，都列在这个象限里。

OKR 当前的状态：如果你设定的信心指数是 5/10，那目前完成的概率是更高了还是更低了，团队一起讨论一下原因。

状态指标：挑出两个影响目标达成的其他因素，团队需要额外关注，比如客户关系、团队状态、系统状况等。当这些地方发生意外时，马上讨论找出应对方案，确保 OKR 不受影响。

这个文档会成为 OKR 执行过程中的会议工具，你应该学会这样讨论问题：

• 这个优先级列表能确保我们的 OKR 完成吗？
• 团队的能力可以完成 OKR 吗？谁能帮助我们？
• 我们准备好新一轮的发力了吗？市场部知道产品部马上要做什么吗？
• 我们的团队已经筋疲力尽了吗？我们的产品是否存在什么隐患？

团队成员坐下来开会时，讨论这四个象限就够了。如果只用它作为会议概要，可以用更具体的文档来补充说明每个象限的详细情况。每个团队对 OKR 盘点会议要求的精确程度不一样。

不过会议还是越简短越好，要不然 OKR 盘点会议将变成团队成员现场刷存在感，事无巨细地列出一堆他们上周完成的事情。要信任团队，他们每天都做了正确的选择，要把会议的基调定在大家为了共同的目标相互支持与配合上。

做好会议的时间安排。建议周一会议时间的 1/4 用来讲述进展，其余时间一起讨论下一步计划。提前结束会议也很正常，因为没有必要为了凑时间而拖延会议

《 OKR 工作法》这本书还特意提到了 Scrum 敏捷开发，我之前也记录了一些心得方便大家理解和参考

敏捷开发 Agile 中 Scrum 与 Kanban 的实践心得 - https://wsgzao.github.io/post/agile/

OKR 实践心得

KPI 和 OKR 没有好坏之分，选择适合团队的应用场景

1. 我们小组制定目标（ Objective ）一般按季度以 3 个月为周期，目标不宜过短，理解任务和目标的区别
2. 目标（ Objective ）数量一般保持在 1-3，初期不宜过多建议只设定 1 个目标，目标的信心指数建议控制在 50%-70%
3. 关键结果（ Key Result ）一定是和目标（ Objective ）相关且便于衡量，不要存在模糊不清的表述
4. 确定好本周需要推进的事项，以及其优先级（如 P1/P2)，每周(如周一) review 目标和关键结果
5. 确定好未来 4 周需要推进的事项，同样需要设定优先级

参考文章

读《 OKR 工作法》

华为的 OKR 实践心得 - 读《绩效使能 - 超越 OKR 》

OKR 工作法简介

微软、IBM 纷纷取消绩效评估，如何做员工绩效管理

谷歌的绩效管理

我看绩效考核