深入浅出了解 OKR（十）：OKR在敏捷转型中的实践（深入浅出的理解）

深入浅出了解 OKR（十）：OKR在敏捷转型中的实践（深入浅出的理解）

敏捷转型（数字化转型）是现在非常多的传统企业加快“上线”的有力抓手，也是传统企业在现代竞争中必须要迈出的一步，否则无法适应激烈的竞争。   我在企业敏捷转型里，经常使用的是我自己总结的一个“组织敏捷转型地图”和“团队敏捷转型地图”模型，并以此为核心内容在2019年北京的的Regional Scrum Gathering大会上做了名为《团队黑客》的主题分享。

我对未来组织有自己的想法，未来组织一定是“业务敏捷化”、“管理游戏化”和“组织社区化”三位一体的。要达到这个理想状态，必然经历组织敏捷转型和团队敏捷转型。

在“组织敏捷转型地图”中，我定义了组织达到敏捷组织会有5个大的阶段：

这个阶段组织开始启动转型工作，组织开始进行动员，做一些组织、架构等方面的调整和变化，企业文化也会被重新定调。

组织转型的动机大部分都是战略驱动的，但是落地一定会回归到业务上，业务存在的方式、方向都会有一些变化，这个时候对业务的梳理、重构、定义就非常重要。要找到重点突破的业务，也要对业务的指标、衡量体系产生明确的定义。

业务重构后，产品方面的调整和创新也会随之而来，业务会被分解到不同的产品上去实现，各种产品规格就会确定下来。同时在产品层级也会要求进行不同的组合、融合和创新，某些项目型的团队，也会走向产品化，用产品思维重新思考旧有的平台。

事情是由人来做的，战略、业务、产品都发生了变化，组织和架构也会做出对应的调整，团队在这个过程中也会有很多变化，包括但不限于人员构成、团队架构、流程、工具、文化等，这个过程是大部分敏捷转型团队层级要做的事情。核心目的是打造高效的交付团队，完成业务和战略的支撑。这个过程还要经历“试点”、“推广”、“固化”等阶段。

未来组织也许某些时候只是一个状态，会不断的重新进入到组织转型和业务重构中，再一次的经历循环。业务、产品、团队不断的进化下，组织变成“未来组织”形态。

在团队匹配的过程中，“团队敏捷转型地图”模型就非常有用了，我定义一个团队从组建Scrum团队开始一直成长为高效团队，会经历7个大的阶段：

Scrum团队开始形成，明确产品领域及资源配备，确定团队成员，明确PO、ScrumMaster一类的角色，建立团队章程，进行初步的敏捷培训和辅导。

团队开始运行Scrum，建立起迭代交付，并形成节奏感。这个阶段要熟悉Scrum，并形成习惯。通常这个过程要经历4~6个迭代。

这个阶段团队不再聚焦迭代，要开始建立产品规划能力，建立产品的愿景、目标和中短期计划，通常需要6~10个迭代。前三个阶段都是“定性”的，不需要数据来支撑。

团队在能够对产品认知一致的情况下，聚焦业务，能够熟悉产品优先级、聚焦MVP等，真正明白产品要解决的why是什么。这个过程通常需要4~6个迭代。价值优先阶段开始，要建立“定量”机制来衡量团队。

在做完产品和业务拉通后，团队不再聚焦“效率”，而开始聚焦“效能”。团队交付能力建立了一个基础之后，开始度量迭代交付能力，稳定提升交付效能，关注交付承诺，这个过程通常需要4~10个迭代。

这个阶段至少需要20个迭代周期，团队不断提升交付后，已经具备自我进化的能力了，这个时候团队开始持续构建团队，通过各种评测来发现能力缺失项，不断改进提升。

这个是团队的最终目标，团队整体开始关注商业价值和成功，也能迅速的形成解决方案，理想的目标是团队负责的相关业务开始指数型的增长。这个过程也需要至少20个迭代。   当然，这些阶段并不是串行的，而是一个并行结构进行。以一周的迭代来看，一个团队要做到高效团队，至少要努力一年以上的时间。 作为敏捷人士，我们如果单纯的使用敏捷实践，比如XP、TDD、Scrum等，所取得的成果都非常有限。在实施转型过程中，我经常会结合OKR来实施，OKR给我了一个价值对齐和衡量的办法。   当团队从“定性”向“定量”转变时，最难的就是对“价值”的衡量。“定性”阶段解决了产品的交付问题，“定量”阶段要解决产品的价值对齐和衡量问题。传统意义上的产品价值，主要依靠产品经理的个人能力来把握。敏捷方式下，可以应用很多的敏捷框架，比如SAFe，LeSS等来进行价值的对齐，但都有过于复杂的问题，需要大量的学习和实践。   如果我们使用OKR来做组织转型呢？把OKR当成另外一个组织敏捷转型的框架呢？

我在几个转型项目中，使用OKR都获得了不错的效果，通过战略对齐，使得团队的视角不断向业务端延展，不断的追求价值体现，帮助产品团队从最初的面向“理想”的团队，浪费大量的时间开发毫无价值功能的团队，转变为面向“现实”的，不断的纠正和业务、经营诉求偏差的团队。

在使用OKR的过程中，中高层和团队也增加了很多互动和相互理解的过程，使得价值观高度的统一。比如某个团队觉得开发某特性，主要就是为了让CEO能有市场宣传的卖点，对齐的过程发现这个特性是决定公司产品战略发展的伏笔，从而使团队对特性的重视程度有了重新的认知。

Scrum、看板等敏捷实践在交付上又能保障团队的基础工作，这样的敏捷转型会变成大家都认同的转型。

Scrum、SAFe、LeSS这些敏捷术语，对于公司中高层而言，都过于专业和局部，往往他们并不关心。而OKR简单直接，又和“绩效”有着千丝万缕的联系，我们可以打着“绩效提升”的旗号拉动中高层一同卷入。或者将“OKR与敏捷绩效”打包在我们的敏捷转型中，将我们取得的结果取得量化和展现，逐步变成成果，从而促进敏捷转型的推动。

OKR和敏捷有非常多的文化底蕴是一致的，比如：价值驱动，透明公开，持续适应，学习试错等。但是我们也要意识到从根本上来说，他们的基因是不同的。           OKR虽然是目标管理工具，但是从诞生以来，主要是面向战略落地，协助Intel做了一次重要的转型，这个主要的维度还是由上向下的，面向大组织向小团队渗透；OKR进入谷歌，经历了由40人到目前超十万人的过程，但是由投资人和创始人带入，帮助谷歌的愿景和战略实现。所以OKR带有“权贵”的味道，公司高层对绩效的关注，目标的关注很有利于我们开展OKR的实施部署。   敏捷呢，始于敏捷开发，面向工程交付，聚焦专业技能，更多的是草根文化。敏捷更多的是面向小团队，虽然现在有很多规模化敏捷的框架，逐步的向组织层级扩展，但是面向工程交付的基因在很多时候会显示出一些局限性，比如向上沟通方向很难达到高层，这样造成很多公司的高层并不care是否敏捷。   OKR和Scrum的融合还有很多火花，只有不停的迭代、实践，激发团队的主动性，引起中高层的关注，并通过成果的展现体现出实战价值才是最终的目的。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。