閱讀本文約花費: 12 (分鐘)

敏捷转型（数字化转型）是现在非常多的传统企业加快“上线”的有力抓手，也是传统企业在现代竞争中必须要迈出的一步，否则无法适应激烈的竞争。

我在企业敏捷转型里，经常使用的是我自己总结的一个“组织敏捷转型地图”和“团队敏捷转型地图”模型，并以此为核心内容在 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 可以聚焦在业务和产品层级，迅速的形成业务成果；
• 目标和关键结果的澄清，能把以进度和交付为度量的结果，直接转变为可衡量的成果；
• OKR 还能简单的解决依赖问题，使用对齐能增加整个组织内的团队协同效应；

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

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

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

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

OKR 和敏捷的基因论

OKR 和敏捷有非常多的文化底蕴是一致的，比如：价值驱动，透明公开，持续适应，学习试错等。但是我们也要意识到从根本上来说，他们的基因是不同的。

OKR 虽然是目标管理工具，但是从诞生以来，主要是面向战略落地，协助 Intel 做了一次重要的转型，这个主要的维度还是由上向下的，面向大组织向小团队渗透；OKR 进入谷歌，经历了由 40 人到目前超十万人的过程，但是由投资人和创始人带入，帮助谷歌的愿景和战略实现。所以 OKR 带有“权贵”的味道，公司高层对绩效的关注，目标的关注很有利于我们开展 OKR 的实施部署。

敏捷呢，始于敏捷开发，面向工程交付，聚焦专业技能，更多的是草根文化。敏捷更多的是面向小团队，虽然现在有很多规模化敏捷的框架，逐步的向组织层级扩展，但是面向工程交付的基因在很多时候会显示出一些局限性，比如向上沟通方向很难达到高层，这样造成很多公司的高层并不 care 是否敏捷。

OKR 和 Scrum 的融合还有很多火花，只有不停的迭代、实践，激发团队的主动性，引起中高层的关注，并通过成果的展现体现出实战价值才是最终的目的。

作者介绍：
杨瑞，资深敏捷教练，创业教练，埃里克森认证教练，连续创业者，复旦软件工程硕士。TGO 厦门分会学习委员。拥有超过 18 年的软件工程及研发管理经验，China DevOps 社区的核心发起人，国内敏捷社区核心组织者。多年 Regional Scrum Gathering 演讲嘉宾。EXIN Agile Scrum Master 认证讲师，管理 3.0 讲师。（微信：OscarYang）