22 OKR的优势：为什么要用OKR来取代KPI做团队规划？
你好，我是华仔。
如果让Team Leader（以下简称TL）选出自己工作中最头疼的几件事，那么团队规划一定是其中之一，因为这件事情很难有确定的标准，感觉怎么做都有一定的道理，但又不太确定什么样的规划才能拿到好结果。
那么是不是说，如果你不是TL，就不用掌握团队规划的方法了呢？其实并不是这样的。
首先，作为团队成员，你需要理解TL的规划，并且根据他的规划分解出自己的规划；当你自己学会了团队规划，就更容易发现潜在的机会，然后跟TL争取这些机会。
其次，现在到了P6+级别就可能带人了，如果你想晋升到P7的话，必须具备一定的管理能力，而无论你是带实体团队还是虚拟团队，都要掌握团队规划的方法。
KPI：关键绩效指标
团队规划到底要怎么做呢？大家耳熟能详的就是KPI了。
KPI的英文全称是Key Performance Indicator，意思是关键绩效指标。它把公司的目标自上而下地分解，并且通过相关的关键绩效指标来衡量实际的执行效果。
KPI的问题
虽然KPI规划法曾经的确是比较先进的管理方法，但是到了今天，它的缺点也暴露得很明显。
首先，它只适合标准化的、目标稳定的工作。
比如在一家生产洗衣液的工厂，生产线是标准化的流水线，KPI可以设定为产量、停机时间和良品率等，产品销售是目标稳定的活动，KPI可以设定为销售量和市场占有率等。
但是，工厂的技术创新就不适合用KPI来衡量了，因为创新有很大的不确定性，既不可能标准化，也不可能稳定产出。
其次，它也会给团队带来不好的风气。
索尼公司前常务董事天外伺朗就写过一篇名为《绩效主义毁了索尼》的文章，痛批KPI规划法带来的问题。这篇文章在业界流传很广，其激起的广泛讨论现在都没有停止。
如果我们先抛开文章结论对不对、观点是不是太偏激、索尼对KPI的理解是不是准确这些争议不谈，只看其中描述的现象，就会发现很多公司都存在同样的问题，比如：
- 故意定低指标：几乎所有人都把指标定得比较低，因为这样容易实现。
- 只顾短期效益：追求眼前利益的风气蔓延，短期内难见效益的工作都受到轻视，比如质量检验和老化处理等。
- 一切只看指标：上司不把部下当有感情的人来对待，一切都用指标来衡量。
- 工作和考核本末倒置：绩效考核需要把各种工作量化，但是很多工作无法简单地量化，所以公司在绩效考核上花费了大量的精力和时间，而在真正的工作上却敷衍了事，本末倒置。
KPI的困惑
KPI规划法的这些缺点，在互联网公司的技术团队往往会进一步放大，很多TL在使用这种方法的时候都遇到过问题，比如：
第一，程序员的工作要怎么量化？
代码行数？版本数？bug数？这些指标都是不可行的！
比如某通信大厂考核程序员的关键指标是bug的数量和等级，而考核测试员的关键指标是发现的bug数量和等级。
结果呢？程序员和测试员为了一个问题是bug还是需求遗漏、bug的等级是严重还是一般，能够吵上 2 个小时；2 个小时吵不出结果，就拉上双方主管再吵 2 小时；还吵不出结果，就拉上经理继续吵 2 个小时。
于是最后就看谁会吵，谁官大，搞得程序员和测试员身心俱疲，关系很紧张。
第二，技术团队怎么体现工作贡献呢？
既然代码量、版本数、需求数、bug数这些指标不可行，那么如何体现技术团队对业务的贡献呢？
有的公司喜欢用“技术团队背30%的业务指标”这样的方式来定技术团队的KPI。比如公司业务的整体目标是“新增用户100万”，技术团队直接按照30%的比例定自己的KPI为“新增用户30万”。
但实际上这种KPI没有什么意义，因为技术团队的工作并不能直观的转换为业务数据，最后只能是看运气，业务目标达到了技术团队就跟着吃肉，业务目标没达到技术团队就跟着挨罚。
第三，有风险的工作谁愿意做？
很多前瞻性和拓展性的工作也伴随着风险，比如引入 ElasticSearch，理论上是可以提升搜索性能的，但在引入的这一年可能会带来很多问题，之后能带来多少收益还不确定。
在KPI的机制下，这种有风险的工作很可能没有人愿意去做，因为大家都不想犯错。
技术团队规划的常见角度
考虑到这些问题，使用KPI规划法的时候，很多技术团队的TL会从以下3个角度来做团队规划：
1. 解决问题
比如解决版本延迟、线上Bug和团队成员士气不高等问题。
这是最容易找的角度，因为没有完美的团队，只要去找，一定能找到问题；而且这个角度看上去就很有价值，因为出问题肯定是不好的，解决掉总归是有好处的。
2. 优化性能
既包括团队优化，比如提升开发效率和质量，提升团队成员战斗力；也包括技术优化，比如将App的崩溃率从0.5%优化到0.3%，将后台接口响应时间从50ms优化到30ms。
这也是很多人喜欢用的一个角度，因为它也非常简单明确，不需要太多的思考，毕竟没有哪个产品和系统是完美的，每年都可以找到各种优化点，并且这些优化点还可以用指标衡量出来，看起来就是一个完美的KPI。
3. 引入新技术
比如引入Flutter来实现双端统一开发，引入机器学习来实现系统的某个功能。
业界各种新技术不断涌现，新技术有可能让生产效率或者生产质量大幅提升，所以引入新技术看起来既可以提升团队技术水平，又可以提升产品竞争力。
但是，从这些角度来做KPI规划，往往拿不到很好的绩效结果。主要原因在于，这些都是团队和技术的角度，没有结合业务目标，所以就算你做得很好，价值也不一定能体现出来。
我曾经多次遇到过这样的场景：
某个技术团队的TL兴致高昂地介绍了自己的团队规划。技术领导问了一句：“为什么要现在做这个事情，这个事情给业务带来什么价值？”
结果这位TL就答不上来了，因为在整个规划的过程中，他都没有这样思考过。最后，他的规划汇报没通过，被领导要求重新规划。
你可能会认为：这些事情本身都是有价值的呀，为什么不可以作为规划内容呢？比如App崩溃率从0.5%优化到0.3%，用户体验肯定是提升了的呀！
我不否认这个事情本身的价值，但是团队规划需要考虑的是如何做才能创造最大的价值。因为团队的资源和时间是有限的，需要让投入产出比最大化。
同样以App崩溃率为例，如果你的App是在东南亚市场推出，受当地市场的手机档次比较低端的限制，崩溃率0.5%跟国内市场比感觉很高了，但其实在当地已经算很好的了。
你花了很大力气，将崩溃率从0.5%提升到0.3%，确实有利于用户体验，但是这部分提升带来的价值对用户来说感知不明显。
相比之下，如果你花同样的资源按照当地用户的操作习惯将UI改版，可能效果会非常明显。
OKR：目标与关键成果
为了解决KPI规划法的问题，英特尔公司创始人安迪·格鲁夫（Andy Grove）提出了另一种团队规划法，后来由约翰·杜尔（John Doerr）引入谷歌发扬光大。
目前硅谷的知名企业都在使用这种方法，比如微软（Microsoft）、领英（LinkedIn）、推特（Twitter）、亚马逊（Amazon）、脸书（Facebook）和雅虎（Yahoo）等，它就是OKR规划法。
OKR的英文全称是Objectives and Key Results，意思是目标与关键成果。它的实施步骤是：
首先，设定业务目标（Objectives），比如提升市场占有率。
然后，为每个目标设定关键结果（Key Results），也就是为了实现目标具体要做的事情，以及具体的标准，比如为了实现“提升市场占有率”这个目标，准备“请XX明星做代言人”“投入100亿做用户补贴”等。
OKR 与 KPI 的区别是什么？
大部分人第一次接触 OKR 的时候都很疑惑：OKR和KPI看上去好像没什么区别，OKR的一个关键结果（KR）如果用数据来描述，似乎就是KPI的一项指标。
既然如此，那么我们为什么要强调用OKR，而不用KPI呢？其实它们的本质区别就藏在名字里。
KPI的关键词是Indicators，而OKR的关键词是Objectives。
换句话说，KPI 关注的是数据指标，而OKR关注的是业务目标。
我举几个例子来说明吧：
- 假如你是程序员，如果关注指标，你想到的是代码行数、bug 数和单元测试覆盖率；而如果关注目标，你想到的是解决产品的卡顿问题和实现精准推荐。
- 假如你是足球运动员，如果关注指标，你想到的是进球数、助攻数、跑动距离和比赛场次；而如果关注目标，你想到的是夺冠、四强和保级。
- 假如你是曹操专车的业务负责人，如果关注指标，你想到的是司机数量、订单数和乘客数；而如果关注目标，你想到的可能是让曹操专车成为网约车行业第二。
所以，不要小看指标和目标这两个词的力量，它们代表的是两种思维方式。
当你使用KPI规划法，更关注数据指标的时候，第一反应是“我要履行什么职责”，思维就会受到限制，只会关注当前已有的工作，不太可能去思考接下来应该做的事情是什么。
而当你使用OKR规划法，更关注业务目标的时候，第一反应是“我要做成什么事情”，思维就会更加开阔，而不会局限于当前正在做的事情，可以根据实际情况判断和选择接下来应该要做的事情。
方向对了，就不怕路途遥远；方向不对，数据再漂亮也没有意义。在快速发展的行业，比如互联网行业，我们需要拥抱变化、不断调整，显然OKR规划法更加适用。
《绩效主义毁了索尼》这篇文章里有这么一句话：“具有讽刺意味的是，因单枪三束彩色显像管电视机获得成功而沾沾自喜的索尼，却在液晶和等离子薄型电视机的开发方面落后了。”
怎么理解呢？按照 KPI 的思维，彩色显像管电视机是已经在做的产品，自然要把销量数据做得越高越好；但是按照 OKR 的思维，整个行业都在转向液晶和等离子电视，必须尽快切换产品方向。
彼得·德鲁克在《管理的实践》这本书中说道：“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”
这句话非常好地诠释了KPI和OKR的区别，提炼一下就是：KPI让我们正确地做事，OKR让我们做正确的事。
你知道大部分的人的KPI是怎么制定的吗？先看有哪几个指标，然后每个指标做一些提升，就当成KPI提交。
我就亲身经历过这样的KPI讨论场景：
某手游交易网站的产品经理列出了5个指标，用户量、成交额、用户安全、发货速度和收入，然后给每个指标设定了一个增长量。
团队内部讨论的时候，我提了一个问题：“为什么要制定这些KPI？”
产品经理的回答是：“这些指标每个都很重要啊，你说哪个不重要呢？”
事实上，这些指标在不同的时期重要程度是不一样的，有的指标甚至是互相冲突的。
- 如果业务目标是做到市场份额行业第一，那么用户量作为核心指标必须增长，你需要到百度买流量、补贴新用户和免交易手续费等，但这样做肯定会增加支出、减少收入。
- 如果集团要求创新业务必须实现盈亏平衡，那么收入作为核心目标必须增长，你就不能免除交易手续费，而是要实现交易阶梯收费，但这样又会影响用户量和成交额，因为会有一部分用户会因为手续费的原因而转移到其他交易平台。
当你用OKR规划法的话，需要先根据环境变化和业务发展进行判断和取舍，明确业务目标，然后才能基于目标分解出合理的KPI。
所以有一种说法是这样的：OKR其实就是一种牛逼的KPI制定方法。
OKR 与 KPI 的联系是什么？
虽然OKR和KPI有着本质区别，但这并不意味着它们截然相反、水火不容。
前面我也提到过，OKR的KR和KPI的表现形式基本一致。比如下面这个例子中的KR，我们说是它是KPI也没什么问题。
某App业务负责人的OKR
O：App注册用户数达到5000万
KR1：2021全年新增用户1500万
KR2：月活用户达到2500万
KR3：新用户月留存率达到40%
所以，OKR和KPI其实有着内在的联系，我觉得它们的关系用下面这张图来形象地表示：
如上图所示，OKR的KR有两种表现形式，一种是KPI，一种是里程碑。
因为KPI的要求是可以量化，而OKR的要求是可以衡量，有着微妙的不同。你可以用量化的数据来衡量，也可以用里程碑式的关键节点来衡量。
量化的KR很常见，比如前面提到的“2021全年新增用户1500万”。
里程碑式的KR，指的是关键事项的落地，难以量化但可以衡量。以索尼公司为例，彩色显像管电视的开发项目立项时的KR应该是“19XX 年开发出彩色显像管电视”，这就是一个无法量化但可以衡量的结果。
互联网行业常见的里程碑KR有“某某业务上线”“完成推荐系统从0到1开发”“落地敏捷开发流程”这些。
小结
现在，我们回顾一下这一讲的重点内容。
- KPI的缺点有两方面，一是只适合标准化的、目标稳定的工作，二是会给团队带来不好的风气，比如故意定低指标、只顾短期效益、一切只看指标、工作和考核本末倒置等。
- 技术团队的TL做团队规划有3个常见做法：解决问题、优化性能和引入新技术，但是因为没有结合业务目标，价值很难体现。
- OKR规划法关注业务目标，可以根据实际情况及时调整，更适合快速发展的行业。
- OKR是一种牛逼的KPI制定方法，KPI是KR的一种形式。当你先明确业务目标，再根据环境变化和业务发展进行取舍，才能制定出合理的KPI。
思考题
这就是今天的全部内容，留一道课后思考题给你吧。你完整地制定过团队或者自己的KPI吗，在这个过程中遇到了哪些疑惑和困难，学完这一讲你有解决的思路了吗？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
- 周平 👍（46） 💬（1）
我理解 OKR是KPI的升级版。因为 OKR包含了KPI。 比如，文中提到: "OKR 的 KR 有两种表现形式，一种是 KPI，一种是里程碑。" 也就是说， OKR是在KPI之上，加了一个O， 同时，也把里程碑纳入进来，解决一些KPI解决不了的问题。 这就使得OKR更灵活，不僵化。 同时，OKR不再追求量化，不再追求数据说话，而是追求可衡量。 可衡量就是说，可以用数据说话来衡量，也可以用里程碑来衡量。 OKR不适合什么？ 1.不适合个人规划，除非自己能够独立负责一个领域或方向。 2.OKR至少是一个季度，半年或一年。不适合一个月这种周期。 关于程序员的工作量如何量化？ 答:无法量化，一线的程序员不推荐用OKR来规划和考核，更不用说KPI了，更不合适。一线程序员的考核基本就是事后总结。 通过事后总结，看你做了什么事，贡献如何，质量和效率如何，是否有犯错，周围的人对你的评价等等。 从这里面看，大部分都是主观评价。因此，多发出自己的声音就很重要了。 我找到一种方法发出声音:在做一个项目之前，往往要和上下游沟通，了解相关的需求点。这个时候，多发表自己的看法，多问问题，也是一种发声的方法。
2021-02-03 - Jxin 👍（14） 💬（1）
KPI的弊端: 麦金泰尔用一个学习国际象棋的小孩子举例：如果这个孩子每赢一次棋，我们就奖励他糖果，那么糖果就是这个小孩子关于国际象棋的外在快乐(KPI绩效激励)。 如果驱动这个小孩子的仅仅只是外界作用于他的糖果奖励，那么将没有任何事情可以阻止这个小男孩用欺骗或贿赂的方式获胜(绩效指标终将沦为虚荣指标). KPI的好处: 在“推算型工作”很适用。“推算型工作”是指根据一系列现成的指令，按照某种途径达到某种结果的工作。比如，拧螺丝钉，这类重复性机械劳动，就属于推算型工作。
2021-01-20 - Monday 👍（13） 💬（1）
方向对了，就不怕路途遥远；方向不对，数据再漂亮也没有意义 金句---选择远远大于努力
2021-01-25 - 大魔王汪汪 👍（9） 💬（1）
总结：以目标为导向；kpi和okr某种程度会影响思考方式，前者偏被动量化，后者促进主动思考
2021-02-24 - Harvey 👍（6） 💬（1）
你好，华仔： 1.OKR与KPI的概念。OKR注重的是业务目标，及关键结果。KPI注重的是指标可以量化。举例：用OKR的方式制定找工作，目标是进入XX大厂P6。关键结果1:专业技术 关键结果2:业务贡献 关键结果:面试准备。使用KPI在关键结果1中 研究mysql100小时、输出笔记20篇 、解决工作中3个核心问题 2.之间的区别：在关注点和思维的区别我认为最深刻。一个关注指标，一个关注目标。在工作中即使没有用OKR，在做一个需求时也可以想想业务目标是什么，做这个需求能解决什么问题，对业务目标有帮助吗。而只关注指标的话就是需求做了几个，需求上线有没有bug等。对于改变思维方式需要多思考，多问为什么，看一些非专业类书籍，写笔记。 3.关于团队中的常见KPI的规划有一些想法。三种常规解决问题、优化、技术升级，没有结合业务目标。由于在团队中非TL，程序员除了做需求也只能处理这三种问题。 4.问题： 4.1 作为一个业务程序员应该如何避免做上文中的三类事情？ 4.2 程序员的工作怎么量化？
2021-01-23 - chopper 👍（4） 💬（1）
kpi和okr都用过，kpi的问题在于想出一堆事情去做，也有数据衡量，但是不能确定是否是当前最有价值的事情。我们团队现在用okr，团队大佬先根据现状定出目标，然后大家发挥主观能动性围绕目标定关键事情，保证行动方向和结果是上下对其的。
2021-08-05 - 起而行 👍（3） 💬（1）
发现了秘密，一线的开发kpi不好衡量，需要依赖同事之间的评价和感觉，所以更看重个人是否主动
2021-04-02 - Hesher 👍（3） 💬（1）
OKR提供了一种自驱动能力，而且是目标结果导向，就会获得做正确的事这一效果。 我现在的公司是执行OKR的，每个人都要制定年度、季度OKR，而这些又区分业务OKR、技术OKR、管理OKR。并且有上下层级关系，比如我的OKR要向上支持直属领导的OKR，领导再向上支持更高层级，一直到CEO，相当于是逐层细分目标。当整个组织都被赋予了自驱动能力，创新能力也会被放大，升级成智能型组织。
2021-03-31 - Monday 👍（3） 💬（1）
拜读了《绩效主义毁了索尼》，本篇文章从里面吸收了不少的能量。
2021-01-25 - Hero 👍（3） 💬（1）
华仔，技术研发团队，研发工程师的OKR，某一个月如何更好制定？ 可以分析一下？ 谢谢！
2021-01-20 - 白茶清欢 👍（2） 💬（1）
OKR是不是有对齐一说？ 我们也制定OKR，但是里面的O和KR必须和上级领导对齐，这样的好处是不会让员工的目标出现偏差，不好的地方是，大部分员工都会等着领导指定了O后，下面员工根据O定自己的OKR。
2022-02-14 - 程序员俊达 👍（2） 💬（1）
OKR关键在于O，这样大家的目标方向是一致的。而KPI是设定指标，如果不知道目标是什么，可能指标定义也就不清晰，会导致出现错误的方向。所以如果想要作为管理层，这两个都需要了解。
2022-01-27 - 苍茫大地 👍（2） 💬（1）
价值聚焦。分解Key Result。作为工作内容安排的导向，不作为程序员绩效考核的标准。但作为公司整体业务价值落地考核的主要支撑。
2021-12-06 - 阎晓静 👍（2） 💬（1）
经历过KPI，但作为一个组员，其实对KPI的印象已经很不深刻了，当前团队采用的是OKR的形式，但也不太了解如何拆分Key Results ，通过今天学习，了解可以KPI+里程碑的形式，明天就尝试下重新拆分这个季度的OKR。
2021-04-18 - 起而行 👍（2） 💬（1）
公司要求管理者必须制定团队OKR，而个人只需要看齐领导的OKR就行，我有个问题是团队只要做变化较大的运营活动，完全受运营和产品安排，这个时候个人如何制定Okr以及理解主管的okr呢? 另外，华仔感觉大型运营活动，比如国庆节拉新，和独立开发一个系统，比如所做APP的web端从0到1搭建，哪个对晋升更有帮助?
2021-04-02