不是很了解 KPI 具体是怎样的机制，经常听别人提起而已。对 OKR 倒是算了解。话说正好赶上 13 年 Q4 结束 14 年 Q1 开始，每个 quarter 交接都是评价过去一个季度的 OKR 和制定新一个季度 OKR 的时候。

OKR 相对于 KPI 而言，不是一个考核工具，而是一个更具有指导性的工具，说白了，是一个 PLAN-DO-REVIEW 的 cycle。他存在的主要目的不是考核某个团队或者员工，而是时刻提醒每一个人当前的任务是什么。每个人都有自己的 OKR，每个团队有团队的 OKR，无论级别高低，团队大小，都需要制订和服从 OKR。这个 OKR 在每个季度结束之后要做一个评分。评分高低并不直接决定一个员工的晋升和待遇，而更多的是提醒员工，这个季度工作完成的怎么样，未完成的工作为什么没有完成，下一阶段的工作重心是什么。（其实我个人觉得，OKR 还是和薪资 / 晋升有一点点关系的，只是因为 OKR 太笼统了，没办法直接决定是否加薪 / 晋升）

提到重心，OKR 里的每一项 objective 都是有优先级的。最后的总分也通常是通过各个 key results 的权重加权平均的。所以在有限的时间内，哪些是重点，哪些应该优先完成，一目了然。

因为 Google 给员工的自由度比较大，OKR 的存在就保证了员工不会“跑偏”，也保证了这种自由度的存在。

另外，OKR 不会涉及具体数字，所以并没有给人很大压力，也不存在为了 OKR 而弄虚作假的情况（听说为了 KPI 作假的事情比较常见），其实没有人会期待团队 100%完成 OKR（如果真的 100%了，只能说明 OKR 定的太简单了）。没有具体数字，只有任务和完成任务的百分比，所以这种 OKR 更适合 high tech 公司作为指导工程师的工具。

Disclaimer: 我没有亲身了解过“我们一般所说的 KPI”，所以比较仅限于 OKR 的特点。以下谨代表我个人意见，与 Google 无关。

讨论 OKR 之前，有必要先说一个前提：Google 的 impact 文化。衡量的是员工为 Google 做出了多大的 impact，而不是员工是不是很努力地干了很多活，也不是员工是不是听老板的话完成了老板布置的任务。

所以 OKR 也是为了让员工有可能做出更大的 impact 服务的，因而有以下特点:

1. 模糊的目标，用于统一努力的方向，而非计划

所有做过 IT 项目的人都知道，再周全的计划总是赶不上变化。所以 OKR 不是计划，只是一个模糊的目标，具体如何实现还需要探索。但有了目标至少有了努力的方向，这样，个人的目标，团队的目标和公司的目标才有可能能够一致，从而为产生更大的 impact 提供可能。

2. 量化

OKR 必须是个 measurable goal

3. 由员工或者 Tech Lead 提出，而非经理

OKR 需要统一的是个人的目标和团队的目标。Tech Lead 负责的是团队的目标，而员工在意的是个人的职业生涯和个人为 Google 做出的 impact，两个目标通过共同制定 OKR 来统一。

4. (基本)不作为考核标准

既然 OKR 是用来统一目标而非衡量成果的，一般不作为考核标准，虽然 Perf 的过程中也会参考，但 1.0 和 0.7 之间本身并没有太大差别。