前言

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 纷纷取消绩效评估,如何做员工绩效管理
谷歌的绩效管理
我看绩效考核

文章目录
  1. 1. 前言
  2. 2. 更新历史
  3. 3. OKR和KPI的概念
  4. 4. OKR工作法
  5. 5. OKR实践心得
  6. 6. 参考文章