摘要： 题记：从技术 leader 的角度出发，看技术人绩效考核的痛。大多数公司里面总会因为 KPI 的考核方式而存在各种各样的问题，OKR 是一个在硅谷互联网公司比较流行的做法。怎样去理解 OKR 这个概念，并在技术团队中推行，从而使绩效考核更合理也更有意义？ KPI 的困惑 索尼公司前常务董事天外伺朗的《绩效主义毁了索尼》一文，曾经在业界流传甚广，也激起了广泛的。

作者：华仔爱技术（社区昵称），阿里技术专家，10多年IT老兵，著有《面向对象葵花宝典：思想、技巧与实践》

KPI 的困惑

索尼公司前常务董事天外伺朗的《绩效主义毁了索尼》一文，曾经在业界流传甚广，也激起了广泛的争议，支持的反对的意见和声音到现在为止都还没有停止。抛开文章的结论是否正确，观点是否偏颇，索尼是否没有真正理解 KPI 等争议，单纯从文章描述的现象来看，相信绝大部分公司里面都会存在类似的现象，例如：

“因为要考核业绩，几乎所有人都提出容易实现的低目标”

“因实行绩效主义，索尼公司内追求眼前利益的风气蔓延。这样一来，短期内难见效益的工作，比如产品质量检验以及“老化处理”工序都受到轻视”

“上司不把部下当有感情的人看待，而是一切都看指标”、

“为衡量业绩，首先必须把各种工作要素量化。但是工作是无法简单量化的。公司为统计业绩，花费了大量的精力和时间，而在真正的工作上却敷衍了事，出现了本末倒置的倾向”

我开始带技术团队后，在绩效考核这方面同样遇到了类似的疑惑，例如：

程序员的工作怎么量化？bug 数？代码行？版本数？

做过程序员的都知道，这些指标都是不可行的。例如某通信大厂考核程序员的 bug 数和等级，并且更加让人蛋疼的是同时考核测试人员发现 bug 的数量，结果程序员和测试员为了一个问题是 bug 还是需求遗漏、bug 等级是严重还是一般，能够吵上 2 个小时，2 个小时吵不下那就拉上双方主管再吵 2 小时，还吵不下那就拉上经理继续吵 2 小时，于是最后就看谁会吵，谁官大，搞得程序员和测试员身心俱疲，关系很紧张！

即使程序员的工作可以量化，那每次绩效都是这几个指标，定绩效目标还有意义么？

例如：假设考核程序员用 bug 数、代码行数、版本数，那 2000 年用这个指标，2017 年也还是这个指标，这样的绩效目标有什么意义呢？

团队 leader 如何制定团队的 KPI？

例如：可以看两个团队谁的代码行多么？可以看谁的团队 bug 数多么？可以看谁的团队版本数多么？可以看谁的团队分享次数多么？这些其实都不行。

前瞻性的工作谁愿意做，有风险的工作谁愿意做？

例如：引入 ElasticSearch 理论上是可以提升搜索性能的，但可能在引入的这一年反而会带来很多问题，而能带来多少收益还不确定，这个时候怎么定 KPI？

OKR 的尝试

带着这些疑惑，我尝试去进行一些探索或者改进，并试着去看看业界在面对这些问题的时候是如何处理的，于是顺利成章的找到了 OKR 这个在硅谷互联网公司比较流行的做法。然而很遗憾的是，虽然 OKR 有 Google、Facebook 这样的大公司光环，但我刚开始了解 OKR 的时候，基本没看懂 OKR 和 KPI 的区别，感觉这两个东西基本上是一致的，只是换了一个说法而已。

我们以广为流传的谷歌投资人 John Doerr 介绍 OKR 的 PPT 中的样例来看：

我第一次看到这个分解的时候，第一感觉就是：这不就是 KPI 么？我们完全可以说：主教练的 KPI 分为 3 点，每点都有量化指标；公关经理的 KPI 有 3 条，但其中有 2 条没有明确的量化指标，这点跟 KPI 不符合，但其实跟 OKR 自己的要求也是不相符的，例如如下的 OKR 要求第二条就是 measurable：

虽然出师不利，但我并没有放弃（幸好我没有给自己在这件事上定一个 KPI），而是继续去查找更多资料，看看各种不同的解读，再结合自己的思考和探索，然后在团队中进行了小范围的尝试，发现非常有利于解决之前遇到 KPI 相关的困惑，通过这样的“探索 - 尝试 - 思考 - 改进”的方式，逐步真正的理解了 OKR，发现 OKR 真是团队绩效管理的一个利器！接下来我将整理一下理解和实践 OKR 的一些关键点，希望让更多的人拥抱 OKR。

深入理解 OKR

理解 OKR 的第一个关键：OKR 与 KPI 的区别是什么？

OKR 全称是 Objectives and Key Results，而 KPI 的全称是 Key Performance Indicators，单纯从名称上来看，有点不同，但看起来又很类似，这也是我第一次接触 OKR 的时候的疑惑，OKR 的 KR 和 KPI 没什么区别，但实际上这两者的关键差别就在名称里面，如果不理解这个关键差别，实践的时候就会感觉 OKR 和 KPI 是类似的。

OKR 和 KPI 具体的差别表现在：OKR 的关键词是 Objectives，KPI 的关键词是 Indicators！

不要小看了这两个词的力量，正是这两个词决定了 OKR 和 KPI 的本质差异：OKR 关注的是目标，KPI 关注的是指标。当我们关注“目标”的时候，我们会思考接下来我要做的事情是什么；而我们关注“指标”的时候，我们会思考自己的工作如何评价。

以程序员为例，如果我们关注目标，我们会想接下来我应该做什么事情，是要解决产品的卡顿问题，还是可以引入大数据来做精准推荐；而如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢？我们想到的是代码行数、bug 数、单元测试覆盖率这些；

以足球运动员为例，如果关注目标，我们会想到夺冠、四强、保级；如果关注指标，那我们就会想到进球数、助攻数、跑动距离、比赛场次等；

以滴滴和快的为例，如果关注目标，快的的目标应该是超越滴滴；如果关注指标，快的的指标应该是司机数量、订单数、乘客数等；

为何这两种思考方式差异非常大呢？有一句名言形象的说明了这点：如果方向对了，就不怕路途遥远！而如果方向不对，指标再漂亮都没有意义，甚至指标越漂亮就错的越大。目标就是我们的方向，指标就是评价我们做的事情的质量。使用 OKR 的时候，我们的思维第一反应是“我们的目标是什么”；而使用 KPI 的时候，我们的思维第一反应是“我们的职责是什么”，如果我们将思维固化在当前的职责，那就不会去审视整个环境当前的状态以及后续可能的变化，也就不会及时的根据实际情况进行调整。

以《绩效主义毁了索尼》一文中的例子为例：“具有讽刺意味的是，因单枪三束彩色显像管电视机获得成功而沾沾自喜的索尼，却在液晶和等离子薄型电视机的开发方面落后了。”。因为彩色显像管是已经在做的产品，按照 KPI 的方式去思考，自然是要将彩色显像管销量指标做的越高越好；但按照 OKR 的方式去思考，就会发现行业都转向液晶和等离子电视了，应该尽快将目标转向液晶和等离子电视，而不是继续将目标放在彩色显像管电视上。

再假设以快的和滴滴为例，如果按照 OKR 的方式来思考，快的的目标应该是“2014 年 Q4 超越滴滴”；如果按照 KPI 的方式来思考，快的的指标可能是“2014 年 Q4 订单数增长 100%”，也许为了达到“2014 年 Q4 超越滴滴”这个目标，最终确实要求“2014 年 Q4 订单数增长 100%”，但更可能的情况是为了达到“2014 年 Q4 超越滴滴”这个目标，最终要求“2014 年 Q4 订单数增长 200%”，因为快的需要考虑滴滴本身的增长。单纯从指标来看，“增长 100%”已经是非常厉害的了，而如果从目标来看，“增长 100%”却还远远不够！

彼得德鲁克在《管理的实践》中说：“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”。我觉得这句话非常好的诠释了 OKR 的本质，以及 OKR 和 KPI 的区别，形象的提炼一下：OKR 让我们做正确的事情，KPI 让我们正确的做事情！

理解 OKR 的第二个关键：OKR 与 KPI 的联系是什么？

虽然我们前面深入剖析了 OKR 与 KPI 的关键区别，但这并不意味着它们就是截然相反，水火不容的。我们在实践中会发现，OKR 最后的 KR 和 KPI 看起来没什么两样，这又是什么原因呢？主要原因在于 OKR 中的 KR 和 KPI 的表现形式是基本一致的，OKR 的 KR 也要求 measurable，这点和 KPI 的“量化”指标基本一致，所以很多 KR 形式上看起来和传统的 KPI 一样。例如下图，这里面的 KR 我们说是 KPI 也基本没问题：

OKR 和 KPI 的关系，用下图来表示最形象不过了：

根据上图的描述，我们可以看到，OKR 首先确定 O，然后从 O 分解出 KR，然后用 KPI 或者 Milestone 的形式来表示 KR。

这里有一个细节需要特别注意：OKR 的 KR 可以是 KPI，也可以是 Milestone，这是为什么呢？关键在于 OKR 要求 KR 是 measurable，中文译为“可衡量的”，而 KPI 的指标要求是“可量化的”，也就是说衡量的方法更加广泛一些，可以是“量化”衡量，也可以是“里程碑”式的衡量。

同样以《绩效主义毁了索尼》一文为例，索尼公司彩色显像管的开发项目立项时的 KR 应该是“19XX 年开发出彩色显像管电视”，这是一个无法量化的目标，但完全可以通过里程碑的方式来评估这个目标是否达成；再以足球队为例，皇马足球队的联赛 KR 应该是“夺取西甲联赛冠军”，这也是一个无法量化，但可以评估的结果，你总不能说为了量化改为“夺取 1 个西甲联赛冠军”，因为 1 年内根本不存在夺取多个西甲联赛冠军这个结果。

理解 OKR 的第三个关键：OKR 到底要不要和绩效考核相关？

OKR 目前在美国硅谷的科技公司应用并取得了很好的效果，但介绍 OKR 的文章里面无一例外的都提到了 OKR 和绩效考核无关，例如 Facebook 的绩效考核是 360 度环评，而中国公司的绩效目前来看不太可能采用这种方式进行绩效评价，那如果我们要推行 OKR，绩效考核如何做？ 难道还要发明另外一套机制来进行考核？

前面我们分析 OKR 和 KPI 的关系的时候，提到了 KR 其实可以用 KPI 或者 Milestone 的形式来进行衡量，而这正好和我们传统的 KPI 绩效考核的形式是一致的，因此我认为根据 OKR 来进行绩效考核并没有什么问题，而且可以从已有的 KPI 绩效考核平滑的过度到 OKR 绩效考核，只要考核 OKR 的 KR 是否达成，达成情况如何就可以了。

例如，我们在制定 KR 的时候，可以直接将结果等级包含进去。以恒大足球队为例，如果 KR 直接定“夺取联赛冠军”，那考核的时候只有两种结果：达到和未达到，考核就比较粗粒度了，但如果 KR 为“保底 4 强，满意亚军，争取冠军”，那就可以进行传统意义上的绩效考核了：4 强是“正常”，亚军是“优秀”，冠军是“突出”，许老板也完全可以根据这个结果来决定发多少奖金 ：）

根据 OKR 进行考核的时候，还可能出现另外一个问题：KR 都达成了，但是目标没有达成。例如快的的目标是“超越滴滴”，KR 是订单数增长 200%，但到了年底盘点一看，订单数增长 300%，但第一还是滴滴的，那这个到底算达成还是没达成呢？其实如果按照 OKR 的核心是目标这个点来看，肯定是没达成，毕竟目标是最关键的。

理解 OKR 的第四个关键：OKR 的“目标”从哪里来？

OKR 最重要的是目标，因此要求目标本身就是正确的，不能凭空捏造或者胡乱猜想。一般在介绍 OKR 的文章里面，都会提到“自上而下”的目标分解方式。例如球队经理确定球队目标，然后主教练和公关经理再根据球队经理的目标来进行自己的目标分解，通过这种一层一层的分解，逐步将大目标分解到不同团队不同个人的一个个小目标。这种分解方式要求团队 leader 具备较强的业务理解能力。

我们在实践中发现，单纯采用“自上而下”的方式进行分解还不够，还需要“自下而上”的提炼，即：团队根据自己的业务和团队情况提出一些专业上目标。以技术团队为例，假如现在的系统问题比较多，团队成员花费较多时间在处理各种线上数据问题，虽然由于团队成员的能力很强，最终这些问题对业务没有什么大的影响，但站在整个团队的效率和质量角度来说，这样肯定是不正常的，因此团队 leader 可能需要提炼“系统存储结构优化”这个目标，而这样的目标是难以采用自上而下的方式分解出来的。

自上而下的目标分解需要 leader 有很强的业务理解能力，而自下而上的目标提炼要求 leader 有很强的专业能力，两者相辅相成，缺一不可，因此可以看出，实行 OKR 其实对 leader 本身也是一种考验，因为要求更高了。

一个技术团队 OKR 的实例

我们以一个假想的技术团队为例，假设这个技术团队做一款购物 APP，我们看看 OKR 应该怎么做。

1、首先，业务负责人（或者决策团队）要确定半年的业务目标，这个业务目标不能是眉毛胡子一把抓，而应该综合市场、用户、竞争对手等分析的出来。例如：业务目标可以是用户量增长，也可以是用户活跃度，也可以是市场地位，还可以是订单量，还可以是成交金额，还可以是利润……那这半年到底应该以哪个或者哪几个为目标，这是业务负责人（或者决策团队）要想清楚的，而不能像 KPI 一样，每个指标都按部就班的设定一个增长量就可以了。

2、假设业务负责人确定这半年业务目标是“用户量增长”，然后业务负责人分解了几个 KR，例如：“用户量增长 50%”，“从 XX 渠道买量 XX 万”（这个是 KPI 式的 KR）、“6 月底新增 XX 业务”（这个是里程碑式的 KR）。

3、那么技术团队拿到业务 OKR 后进行分解，注意这里的分解不是说技术团队背一个类似“用户量增长 20%”这样的指标，因为这样的指标是无法衡量这 20% 到底是不是技术团队的功劳，而是要从技术的角度对业务的 OKR 进行分解。例如：“从 XX 渠道买量 XX 万”这个 KR 对技术团队来说关系不大，可以无需关注；而针对“6 月底新增 XX 业务”这个 KR，技术团队直接将其转换为自己的目标即可。技术团队对“6 月底新增 XX 业务”这个目标进行分解，得出 1 个 KR：“5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”、

4、针对“用户量增长 50%”这个 KR，初看好像和技术团队没有太大关系，但实际上这就是技术团队需要基于业务来思考技术的一个典型 KR。技术团队应该从技术的角度去分析业务的目标：哪些技术是和用户增长量相关的，这些技术目前是否具备，是否目前做的不好还有优化空间。例如：影响用户增长量的一些技术指标有“安装包大小”、“App 启动时间”、“App 崩溃率”、“App 耗电情况”……等等，假设经过分析后技术团队认为目前安装包太大，并且 App 启动时间较长，那么可以将这两项相关的优化作为技术团队的 OKR：“App 安装包从 20M 缩减到 8M”，“App 启动时间从 2s 优化到 500ms”，而这两个 KR，业务负责人几乎是不可能提出来的。

5、除了上面的自上而下的目标分解外，技术团队也需要从团队和技术本身的角度来思考是否有这个阶段需要重点做的事情。例如：我们团队目前的版本节奏较慢，而慢的原因是因为版本多而测试环境不足，测试环境不足是因为机器不够，那可以得出一个目标“解决测试环境不足导致版本等待的问题”，分解出来的 KR 可以是“添加 4 台测试环境机器”（是的，虽然是一件很简单的事情，但这也可以作为 KR），也可以是“引入 Docker，支持一台机器搭建 20 套环境”（这个 KR 比较符合技术人员的理解）。

通过这种 OKR 的方式进行思考和分解，最终技术团队要做的事情如下：

“5 月 30 号完成开发 XX 业务开发，6 月 15 号上线”

“App 安装包从 20M 缩减到 8M”

“App 启动时间从 2s 优化到 500ms”

“引入 Docker，支持一台机器搭建 20 套环境”

写在最后

OKR 对很多人来说还是一个新事物，我接触 OKR 并不久，也许还有很多东西没有彻底理解，也许实践中也还会遇到各种各样的困惑，但是单纯从思路的转变来看，我认为 OKR 不仅仅是一个绩效和目标管理方法论，更是一种“聚焦目标”的思维方式，掌握这种思维方式后，不仅可以在工作中应用，在个人生活中也完全可以应用，并都能够取得很好的效果！

另外社区发起了一个有关程序员KPI的话题：

KPI之痛：有哪些奇葩的技术人员考核方式？-聚能聊-云栖社区-阿里云

欢迎各位同学点击查看和参与