OKR是一个很热门的话题，我所在的公司（有赞）很早以前就开始实行OKR了。2014年老板去硅谷进行调研，带回来一种新的管理方式，一直执行到现在。本次分享也是我在OKR实践方面的一些经历和感受。
OKR与项目管理、敏捷，都是一种提升公司或组织效能的手段，
OKR与敏捷之间也有着千丝万缕的联系，它俩是相通的，都有很多不确定性，不是你做了就一定能成功，还需要达成很多平衡。
管理是一门艺术，系统思考和组织设计，是两种底层能力，
在敏捷实践过程中一定会涉及到。要组建一个敏捷团队，一定要有具体的角色，我们在组建团队的时候就开始做组织设计，在大规模敏捷框架里，组织设计也是一项非常重要的工作。
你在组织中处于什么角色？比如项目经理、敏捷教练、ScrumMaster、技术负责人等。你在做决策时，是否客观？很多时候在小范围内做局部优化工作，没办法做到全局理性，为什么呢？我们发现，
无论是什么角色，在做自己工作的过程中，视野会被工作范围所局限。
如何突破自身的角色和有限的视野，看到更大的范围和跃迁到更高的维度，就要回到系统思考的话题。
系统思考来源于系统动力学，是一门学科。其中有一个属性，系统有一种层层嵌套的现象，所看到的是一层，如果想要看到更大更高的那一层，就要跳出所在的范围，到更高维度的世界去。
实践敏捷也是如此，需要系统思考和更高维度的视野。
我的敏捷世界观：见山就是山 | 见山不是山 | 见山还是山
我的敏捷世界观：
-
见山就是山。
最开始接触敏捷的时候，从课程中学到很多关于敏捷的方法、工具等，比如：三三五五。那时认为敏捷就是这个样子的，要实施敏捷的话，以它提供的框架，按部就班地来执行就可以了。这个阶段学到的是敏捷的形，没有参透敏捷的本质。
-
见山不是山。
后来经历了很多项目管理、组织优化、效能改进的工作，不经意间会根据需求和场景，将学到的敏捷知识和方法加以变通，灵活运用到实际的工作中。比如：基于整个组织的现状，运用同理心，感受需要被引导和改进的部分，然后慢慢结合敏捷去实践。随着时间的推移，我们在更多领域中加入了敏捷的元素，也做了一些创新。这个阶段是领会到敏捷的本质，逐渐融会贯通的过程。
-
见山还是山。
经过反思沉淀后我们发现，敏捷给出的方法论适用于很多工作场景，能解决很多问题，是前人经过无数实践总结出的方法。我们也会慢慢去反思：为什么要做敏捷？敏捷的本质是什么？
-
优先级。
我们的优先级是否明确。在一个团队或大的组织中，有没有做事的方法？优先级是什么？人在同一个时间段只能做一件事，先做哪件后做哪件？
-
高质量的交付。
我们做事的目的一定是为了交付，为了产生价值，高质量的交付是敏捷的一种结果。
-
灵活变化。
我们的组织或团队是否能够灵活应对外界的变化。如果是就是敏捷的，也不用刻意强调三三五五，僵化的敏捷不是敏捷。
前面问的是你在组织中的角色是什么。现在我们思考一下：
你在组织中的价值是什么？
是管理项目，还是作为一个敏捷教练带领敏捷团队？我们的出路在哪里？关注在哪个层面？
敏捷之上的世界：大千世界 | 道法术器 | 价值在外
根据系统思考的原则，需要看到更高的维度。因此除了敏捷之外，还要看到敏捷之上的世界，看清问题的本质。
佛曰：三千世界。世界之外还有世界。在实行敏捷的同时还应该有更高维度的思考和实践。
道法术器。道法是指我们学敏捷不应只是学习它的方法，还应该理解其本质；器是工具，工具是管理的辅助手段，在工具的制定方面，一定是工具适应组织，而不是组织来适应工具。在敏捷实行过程中，即便工具设置得再好，如果实际操作起来完全不匹配组织的现状，使用起来也会很别扭。术包括敏捷方法提供的框架和工具，比如前面提到的三三五五之类的。
在这里值得注意的是：要站在道和法的层面，从更高的角度来审视，是否需要用到所有的这些工具，避免生搬硬套，使敏捷变得僵化。
价值在外。不要以为敏捷团队的敏捷就是端到端的了，在敏捷团队之上还有更高维度的团队，比如：部门、业务线、事业部、甚至公司。我们要从全局看整体的目标是什么、以及是否达成。敏捷团队产生的价值是什么，包括对公司的价值和商业价值。
“价值在外”这个词是管理大师彼得德鲁克提出的，即：我们所做的任何事情都是在组织外部，才会被评价和被认可的。
我们所做的动作，是帮助公司完成敏捷转型，还是是为公司创造价值？在做组织设计时，我们也需要面向是否创造外部价值。
通常公司的使命愿景会描述公司的组织形态和目标，进而公司会组建团队去实现这个目标，所以组织设计一定是来源于使命愿景的。与此同时，使命愿景会通过企业文化巩固组织的设计。使命愿景是宏观的，它是引领组织往前发展的动力。在引领的过程中，一定会有不和谐的东西，即是我们身处组织之中，在微观层面发现组织瓶颈，然后推动和影响组织的设计，当然，任何的再设计也都是不能违背公司的使命愿景的。
具体到如何落地，就又回到系统思考的话题了。我们要通过系统思考的方式看清楚组织的形态、它是怎么运作的、各个环节之间是如何相互影响的。再通过教练引导的方式去影响组织的各个角色，改变其行为和认知，引导组织进行调整和优化，这是一个潜移默化的过程，不可能一蹴而就。
在整个实际操作过程中，我们会随着公司组织架构的调整，伺机引入敏捷元素进行适配。我们的最终目的是帮助公司提升效能，为实现使命愿景服务。
再来看系统。
我们在做组织设计和高维思考的时候，一定要考虑所在的系统。系统有哪些特征呢？
-
适应力。
组织都是有适应力的，在受到外力影响后会适应环境，自发进行调整。
-
自组织。
能够塑造自身的能力，使自己变得越来越强。一个团队也是一个系统，也能够塑造自己的能力，生成新的结构，让自己变得更多样化和更复杂。
-
层次性。
系统是有层次的，有底层系统、上层系统等。
OKR与敏捷：不同维度 | 殊途同归 | 知易行难
不同之处在于：
敏捷作用于一个团队，OKR作用于整个组织。
相同的是：
敏捷和OKR都是敏捷迭代的，其目的都是为了快速试错、降低风险。敏捷和OKR的规则都很简单，在实际落地过程中都会根据不同的组织形态和所处的不同环境形成不同的特点，要掌握其规律，根据场景和现状进行调整与适配。
回到组织设计。首先组织需要有一个使命，使命在组织中存在的时间是无限长的，从组织被创建开始一直到组织消亡；然后是愿景，愿景的周期跨度会相对小一点，一般是5-10年；再往下是战略，组织的愿景通过什么战略去落地和达成，战略的时间一般是3-5年，组织需要根据市场变化进行战略转型；接下来是目标，回答战略落地怎么做，上图是通过OKR的方式来落地，组织一般半年或1年定一个目标；再往下就是行动，采取什么样的行动来实现目标，一个月甚至一天做一个动作，来达成目标。
从使命到愿景到战略再到目标最后到行动，一层层细分，越往下越接近实际的工作，也越具象。
-
经验性框架。
OKR的原则很少，敏捷的敏捷宣言内容也不多；OKR和敏捷都要在实践中总结，不同团队之间难以复制。
-
可变性规划。
敏捷的下一个迭代是它的计划要进行调整，敏捷的目的是频繁探测市场反馈、快速试错；OKR也是一样，在执行时不是像KPI那样一开始就定死了的，而是要灵活调整，进行阶段性回顾，根据已完成的行动项，评估离目标还有多远，随时调整目标和行动，以达到想要的结果。
-
自驱式管理。
敏捷是自组织团队，有哪些任务、想做哪一个，可以自己认领；OKR也是这样，目标是自下而上定的，整个团队一起共创。
-
可层层拆解。
敏捷里feature需要拆分user story以及task，OKR也需要拆分目标、关键结果和行动项。
-
迭代式推进。
敏捷和OKR都是一个动态迭代式推进的过程，在这个过程中不断回顾，看目标的价值是否发生变化，有没有新的高价值目标涌现，当前行为是否可为目标作出贡献……不断迭代优化行动和目标，以达到更有价值的结果。
-
重价值交付。
我们做敏捷是为了更好地交付价值，OKR的目标也是交付价值。
OKR与组织复杂性：团队 | 事业部 | 事业群 | 集团 | LeSS is more
OKR实行的复杂性与组织复杂性相关。
在一个团队里实践相对容易。就像大家在实践敏捷的时候也会发现，在一个小团队中推行敏捷比较容易。而一旦到了大组织中，组织复杂性就体现出来了。
组织的划分也是系统性的，团队之上是事业部，再往上是事业群，再再往上是集团公司。顺便提一句，组织的复杂性，让我联想到敏捷中的LeSS框架，LeSS框架也是基于复杂性组织的。
如上图所示，团队是一维的，你、你的老板、你老板的老板，最多三层，纯粹的单线汇报关系；事业部是二维的，一个事业部里有很多个团队，团队与团队之间会有交集，团队之间的目标也可能会有冲突或依赖，相互之间要对齐；如果说事业部内团队间的关系网是一个二维的平面，那事业群就是三维的立体空间，一个事业群内有多个事业部，多个平面（事业部）之间会产生大量依赖，对齐的难度就更大；集团是四维的，集团内有多个事业群，各个事业群之间……各个单元之间的相互依赖就更加复杂了。
实例分享
以我现在所服务的公司为例。技术团队是一维的，团队成员直接向技术总监汇报，团队的OKR目标即技术目标，跟大的技术部门的目标紧密相关。技术团队和兄弟部门，比如产品团队，又有千丝万缕的联系，产品团队依赖于技术团队实现产品功能，二者的目标存在相互依赖关系，而对于技术团队而言，目标就包括两部分：技术目标和业务目标，变成二维了。
有敏捷实践经验的同学可能反应过来了：这样的组织设计不是很合理，让技术团队承担两个目标，这本身就是一件复杂的事，我们何不把它打散重组成feature team，形成敏捷团队的模式？
我们
在实际操作中，因为考虑到无法改变实线汇报关系，就用虚拟团队的方式来进行降维，让feature team来实现目标，解决各团队间的依赖。通过虚拟feature team的方式，降低事业部内目标的复杂性。
在集团层面，还有一个比较复杂的事情：业务中台。一般认知会觉得业务中台出现后，所有端到端的目标被人为地强化了复杂性，因为都绕不开业务中台能力的提供。业务中台和feature team之间也会产生目标的依赖和不一致性，因为业务中台提供的能力是需要feature team去对接的，反过来feature team会有一些面向用户的功能需要下沉到业务中台来实现，相互之间会有目标的不一致。
于是，对于团队来说目标就有4个：团队内的技术目标、来自产品的业务目标、来自其他feature team的目标和来自中台的目标。要怎么做呢？我们通过高频联动的方式，提升集团内目标的透明度，便于各方对齐。
像敏捷的每周迭代一样，OKR也是需要迭代更新的，我们的做法是：在feature team内，来自内部的目标一个月对齐一次，来自外部的目标三个月对齐一次。迭代更新之后，把信息同步给外部。因为只有透明了，才能真正做到对齐。从这个角度来看，OKR相当于每三个月一次sprint的组织级scrum。
OKR组织之上：组织边界 | 使命愿景 | 价值在外
OKR是整个组织层面的目标管理，一定要从公司目标出发，打通组织所有环节，把他们联动起来，才能使得各个团队的目标服务于整个组织的大目标，并为其产生价值。那么，
在我们实践落地OKR之后，再往上看，能看到什么呢？
-
组织边界，
组织是系统，所以也是有边界的，探寻到边界在哪里，我们就知道上层系统在哪里。
-
使命愿景，
任何组织都有使命愿景，都有目标，我们要看到组织的使命愿景，才能找到跟组织目标相联系的更高维度的世界。
-
价值在外，
用系统思考的方法，从外部感受我们为组织带来的价值。
推荐书籍
内容来源：敏捷+社区线上直播004期，《OKR与敏捷》分享实录
分享者：有赞效能改进工作者费解
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）