结束语-okr对价值极致追求海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

在我个人职业生涯经历，以及后期的经历中，我经常从各级管理人员口中听到一句话，那就是：我

不管过程是怎样的，我只要看到我要的结果，如果结果没达到就不行。我们管这种态度叫“唯结果论”。

在我还是一个职场新人的时候，在一段相当长的时间里，对一些管理人员的这种考核时的唯结果论的态

度深恶痛绝，有两点：

员工在过程里的努力、付出，以及展现的能力和才智，仅仅因为结果不是想要的结果，就被全

盘否定；

有时候没有达成结果，并不是员工的错误。可能在最初决策时就偏离了方向，也可能是沟通没

有到位，最终导致员工交付的东西不是上级想要的。唯结果论，实际上把决策和沟通的错误也让员

工来承担了。

现在，研究管理和多年的人，我对管理人员的这种行为依旧深恶痛绝。我认为这是管

理人员自身没有尽到应有的职责，并将责任和风险转员工的一种表现。

但是我对“过程”和“结果”却有了和以前完全不同的看法。

讨厌唯结果论的人，无非是讨厌自己的付出没有得到认可，没有获得尊重，而且方向性的错误反而

由自己。抛开个人的感受不谈，我们从企业经营的角度来看，企业协调人员和资源进行工作，当然

是为了收获结果，还得是正确的结果。如果没有结果，过程中再努力，也确实没有意义。

如果我们在日常生活中仔细观察一下，就会发现无论企业还是个人，都有可能陷入一种虚忙碌中。

用“忙”的过程来缓解某种焦虑、感动自己，又或者逃避真正问题。

而OKR的出现，则把人们从这种状态中拉了出来，因为它只看目标和关键结果，并不看过程。你的过

程是努力的、科学的也好，是自我感动也好，总有交卷的一天。而OKR就站在那一天，手里拿着一把

尺子，度量你折腾出来的结果。

所以使用OKR，会让你放弃过程里那些花里的东西，从而减少浪费，减少不必要的忙碌，把自己的

行为调整到产出有价值的结果上来。本质上，它也是一种“唯结果论”，但显然它与我前面所说的那种唯

结果论不同，它发挥的完全是正向作用。

虽然OKR如此强大，但是我在辅导企业和团队的过程中，发现最常见的一个错误：就是把目标和关键

结果定义成任务。许多企业在制定OKR时，都是把原来的任务装进OKR的格式里。本质上他们的

也就不是OKR了，而是在任务；所谓的目标管理，本质上还是在管理过程而已。

我在《04|重识目标O：任务和价值，应该以谁为导向？》和《05|关键结果KR：如何制定才

能体现目标“进度”？》中举的那些个名为OKR实为任务的例子，相信只要用过OKR的朋友就都

见过，甚至自己就写过。

这到底是为什么呢？我花了很长的时间去探索问题的根源，后来我发现人们思维中一直有一个误区，那

就是：

结果=任务完成

但是OKR中的关键结果，是指有价值的结果，而不是“任务完成”的这种结果，因为任务完成可能是完

全无价值的，关于这点之前的课程里就反复举例论证过。

不但完成任务不等于有结果，而且有意义的任务也不等于有价值的结果。

对于许多IT团队来讲，提升代码的单元测试覆盖率，是一件非常有意义的任务。然而单元测试代码的

开发和，需要投入不小的人力成本和时间成本。而对于一个中大型规模的软件来说，只有30%左

右的功能是频繁使用和的，其余70%的代码使用和更改的频率非常低。

如果你的目光只聚焦在单元测试这一任务上，那么你很有可能认为这70%的代码理所当然应该有配套

的单元测试；但如果把目光提升到项目的高度，那么就会发现这个做法的投资回报率特别低，而且还占

用资源，影响其他更有价值事项的进度。

所以即使你有足够的理由认为你现在做的事是有意义的，但并不意味着它是一个OKR认可的结果。

OKR的结果不但要求是有价值有意义的，还要求是可验证的。它能给我们有效的反馈，这些反馈包括我

们是否走在正确的？我们是否离目标更近了？我们是否做过头了？我们是否做得还不够？而任务和

任务的进度并不能告诉我们这些，我们完全可能沉迷于“有意义的任务”中而做过了头，或者错失了其他

的机会。