前言
OKR和KPI对于大家应该都是耳熟能详的绩效考核方式，因为部门在推行OKR和360度绩效考核，我阅读完《OKR工作法》这本书后在组内也做了分享，结合我们小组的实践过程记录下自己的心得体会，我也非常赞同左耳朵耗子大大的观点: 绩效分应该打给项目，打给产品，打给部门，打给代码，而不是打给人。
OKR和KPI
更新历史
2019年07月12日 - 初稿
阅读原文 - https://wsgzao.github.io/post...
扩展阅读
SRE 和 DevOps - https://wsgzao.github.io/post...
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...
OKR实践心得
KPI和OKR没有好坏之分，选择适合团队的应用场景
- 我们小组制定目标（Objective）一般按季度以3个月为周期，目标不宜过短，理解任务和目标的区别
- 目标（Objective）数量一般保持在1-3，初期不宜过多建议只设定1个目标，目标的信心指数建议控制在50%-70%
- 关键结果（Key Result）一定是和目标（Objective）相关且便于衡量，不要存在模糊不清的表述
- 确定好本周需要推进的事项，以及其优先级（如P1/P2)，每周(如周一) review 目标和关键结果
- 确定好未来4周需要推进的事项，同样需要设定优先级
参考文章
读《OKR 工作法》
华为的 OKR 实践心得 - 读《绩效使能 - 超越 OKR》
OKR 工作法简介
微软、IBM 纷纷取消绩效评估，如何做员工绩效管理
谷歌的绩效管理
我看绩效考核
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。