——驾驭数字化力量的必由之路

对于企业组织来说重要的是在数字化浪潮下如何生存和发展，那些无法适应的企业将就此沉沦。同样，每一次浪潮都是一个新陈代谢的机会，这不是制造焦虑。处于这样的大时代，在这样的洪流中，我们别无选择，只有加入其中，成为数字化时代的弄潮儿。 理解、应用和驾驭数字化的力量——弄潮数字化时代 数字化是一个巨大的力量，为了弄潮数字化时代，我们需要做到3点： 1）理解数字化力量：理解它怎么发生作用，怎么影响我们的业务，也就是认识数字化的本质。 2）应用数字化力量：就是在理解的基础上，把它应用于我们的业务中，实现业务的数字化转型。 3）驾驭数字化力量：我们组织必须变革，技术和业务协同方式必须发生变革，这样才能保证业务数字化转型的开展。理解、应用和驾驭数字化的力量，弄潮数字化时代，这是一个很大的主题——时代的主题。 BizDevOps是什么？ BizDevOps 是关于在数字化时代业务和技术如何高效协同的实践、方法和理念。其中Biz是业务，Dev和Ops是技术。业技协同是 BizDevOps 的核心，也是驾驭数字化力量的关键。 我们首先回顾一下业务和技术这两者之间的关系的演变历史。 从早期信息化到今天的数字化过程中，业务和技术之间的关系一直在变化，我们说的是IT技术。在工业化时代，技术和业务的关系是相对独立的。业务的需求是明确的——支撑现有的业务，改进它的运营效率。所以技术是支撑者，改进既有业务的运行效率。技术是支撑业务，业务的需求是明确的，只不过要把他分析和整理出来。在那个时代 CMMI、结构化工程是较为适合的方法。 到了互联网时代，发生了一些变化。技术和业务开始融合，它们的边界变得模糊，互联网技术与业务相结合，拓展了新的商业模式。社交、电商、互联网娱乐等都是那个时代产生的，它们是新的商业，但没有技术赋能，这些商业也不会产出。 到了数字化时代发生了更根本的变化。数字化技术已经成为我们今天一切业务的内核，业务、甚至包括非常传统的业务，都要运行在IT系统之上。任何业务的价值交付、业务创新都要以数字化产品为支撑，技术已经成为业务的内核了。 在与企业经营上，业务和技术已经不可分割，甚至技术成为业务的内核。 然而，回到组织内部，业务和技术的协作关系是什么样子的呢？前几年，整个行业在DevOps 浪潮中有很多积累和发展，让技术内部的价值交付变得更顺畅了。 在 DevOps 的旗帜上，我们也试图去突破做技术组织和业务之间的分离。不能说没有突破，但毫无疑问，他们今天还没有做到很好的融合，不管在组织上，流程上还是实践上，业务和技术都还是分离的。这已经成为业务交付和创新的关键堵点。 现实中，数字业务的创新与发展，要求业务和技术不断融合；而在组织和机制上业务和技术依然相互割裂。这已成为我们驾驭数字化力量的核心矛盾。 BizDevOps 要解决的正是这一核心矛盾，它的目的是：打造业务和技术有机融合的数字化组织，赋能数字业务持续创新和长期发展。 BizDevOps是为数字化时代服务的，数字化时代需要这样的变革。我们业务需要数字化转型，组织同样需要数字化转型，技术和业务是我们组织中两个最核心的职能。 我们认为成功数字化转型应该是蝶变的过程，化茧成蝶后机体还是过去的机体，但具有了超越的能力。我们今天做 DevOps，改变效能，提高交付能力。但站在组织数字化角度，组织的数字化转型还停留在内部，比如说技术职能内部，而没有改变面向客户的交付模式，我们得到的不过是一调爬得更快的毛毛虫。 BizDevOps，要面向客户，改变技术与业务的协同方式，改变业务创新、业务交付模式，它必然是一个蝶变的过程。 如何实施 BizDevOps？ 这里介绍一下整体的内容。我们用1个目标，3个能力和5个实践做了概括。 1个整体目标：打造业务和技术有机融合的数字化组织，赋能数字业务的持续创新和长期发展。 3个能力要求：它是实现这个目标，组织必须具备的能力要求。 5个关键实践：是关于做什么，如何做才能实现这三个能力。 接下来我们看三个能力要求。 第一个能力，形成以客户价值为核心的组织协同能力。这就要求我们打通Biz到Dev、到Ops，价值交付链路和反馈闭环。 在打通链路，形成闭环的基础上，还要实现全链路数字化运作。全链路指的是从Biz到Dev、到Ops贯通；数字化运作是指的是基于共同的底层模型、共同的作业对象，在各个环节里实现数据的即时共享，真正实现价值贯通。 全链路数字化运作是第二个能力，只有全链路数字化运作才能保障效率、质量和有效性，并产生高可用的数据，这个数据不再是独立环节，是一个整体的，全要素、实时贯通的数据。 第三个能力，基于高可用数据的过程透明和效能度量能力，保障数字化执行落地，并持续提升组织效能。 这是 BizDevOps 需要的三个能力，它们形成一个闭环，不断加强和持续改进。 三个能力是要求，而5个实践则是达成这些要求的具体操作。 我们来看看这5个实践，它是一个四宫格，左边是协作和管理实践，右边是工程和技术实践，上面是组织层面整体相关的实践，下面则是团队级别的操作实践。 这样相互交叉，左上方是组织层面的协作和管理实践，我们称其为：业务驱动组织协同机制；左下方是团队层面的协作和管理实践，我们称其为：产品导向组织交付方式。右上方是整体的工程和技术实践，我们称其为：适配业务特征的持续业务交付；右下方是单产品层面的工程和技术实践，我们称其为：应用为核心的研发资产和流程管理。在加上中间的关于度量和改进的实践，我们称其为：全量、全要素、实时数据支持的度量和持续改进。这五个实践构成一个整体，最终是为了支撑数字业务的持续创新和长期发展。 下面分别介绍这5个实践。从协作和管理实践开始介绍，先讲团队层面的，未来团队应该是怎样的，今天有一个根本的变化就是从项目导向，向产品导向迁移。前面我们说过，数字化时代所有业务都要依靠数字产品支撑，数字产品承载了数字业务——业务的规则会沉淀并体现产品当中，最核心的数据资产也必须由产品沉淀。我们对业务产期负责，就必须有人对于产品长期质量、长期演进以及对业务支撑能力负责。为此，我们需要从项目导向走向产品导向。 第一：基本假设不同。项目是以确定性为假设的，项目范围是确定的，按照确定的范围、确定时间交付确定的内容就可以。而今天我们的业务持续演进，产品与业务一同演进，怎么可能是确定的？我们不得接受不确定性，建立反馈和调整的闭环，来支持我们探索和发现业务价值。当然更主动的是拥抱不确定性，与业务共同探索、创新。 第二：成功标准定义不同。项目导向，是把技术看作成本中心，以按时、按预算交付衡量成功；产品导向，则要求业务和技术融合，产品和业务共同构成利润中心，以业务目标和结果的达成来衡量成功。 第三：工作分配模式不同。项目导向是从把人作为资源分配到预先确定的工作（项目范围）上，倾向批量式的规划和交付；产品导向是把工作分配到稳定的价值交付团队，寻求持续迭代交付和演进。 第四：团队组织方式不同，项目导向是面向项目的范围和时间要求，临时组建团队；产品导向是面向业务和产品愿景，组织跨职能的相对稳定的长期团队，长期的团队才能对长期的质量、演进和业务结果负责，对所承载的业务资产负责。 第五：关键产出不同，项目团队的关键产出是单次项目的交付物；而产品导向的团队的产出是服务于业务创新和发展的产品，以及其沉淀的资产，包括数据资产，工程资产等。 再看组织层面的协作和管理实践。其核心是业务和技术要真正连通，形成系统的闭环。 从业务目标的制定和机会识别开始、再到业务规划，产出为目标服务的业务需求，再分解成各产品的需求。 前面讲过，产品由相对稳定团队负责，它们共同分解设计产品需求，完成排期和交付。产品团队对产品的演进、产品的资产沉淀以及维护负责，对产品的交付效能负责。 今天一个明确的趋势，整体的应用交付模式在向云原生迁移，将更多工程活动标准化并委托给基础设施完成，一方面效率提升，一方面也保证系统地弹性和韧性。 近期的一个核心变量是 ChatGPT 带了的冲击，AIGC会从根本上改变应用生态和软件交付生态，我相信开发模式近五年会发生根本性转变，技术开发范式会发生根本变化，但业务和技术协同方式只会越来越紧密，反馈越来越快速。业技协同的要求也会更高。 再看来看右边工程和技术领域，在 BizDevOps 时代有什么变化？基础部分并没有变化，云原生、微服务不会变化。但是很重要的，今天在讲持续交付时核心的是持续交付什么，我们讲的是持续业务交付，这点非常关键。 它不去刻意区分稳态和敏态，也不分持或非持续的交付的。我们首先在模型上统一它们，然后再去辨别所谓稳态和敏态，持续或非持续，究竟是哪些行为、模式不同。这将为我们的改进提供非常有针对性的指导。 大致上看一下这个模型，它由三个核心部分，分别是：业务交付、产品发布和应用变更。所有的交付都要处理好这三个问题。当然应用变更，在不同的地方称谓是不同的，互联网产品中用应用变更比较多，传统产品可能会称其为模块或产品变更。 稳态和敏态的交付并不是两个截然对立的状态，而是一个连续过程的两级。 是什么区分敏态和稳态？ 最重要的是三个要素。第一：部署单元的大小。稳态部署单元会通常会更大，云原生开发以微服务化的应用为单元发布，发布单元会更小，纸质单应用部署发布。第二：发布的批量。稳态的发布批量也会更大，即使你已经做了云原生改造，理论上的部署单元比较小，但由于种种限制，仍然可以要求多个应用必须一起发布。比如，每个月只有一发布窗口，要求所有应用放在一起发布，发布批量也会变大；第三：发布过程的灵活性和效率。稳态的发布过程的灵活性和速度会更低。在稳态发布中，通常过程会更僵化和缓慢，可能有比较多的手工和审批环节。这可能是因为系统对稳定性的高要求。但现实中更多的还是受制于技术的复杂度和技术能力，或者是单纯的流程限制。 稳态和敏态并不是非黑即白的两个状态，而是一个连续的过程。这个图里面从红到绿，它是连续谱，过度的区分这是稳态的、这是稳态的，设定人为的限制，事实上变相剥夺了那稳态业务变得敏捷的权利。 明确敏态和稳态的图谱，更是为了指明改进路径。而这个路径的设计既要务实，也要积极。务实就是要与业务的要求和能力水平相匹配；积极就是持续寻求改进的可能。 比如，我可以让发布单元的粒度变小一点点。我们不用上来追求微服务的绝对的“微”，将庞大的应用适当的拆分，依赖关系解耦的更好，让它们可以单独验证、单独部署。这样发布单元的粒度变小了一点点，是不是变得更敏捷一点？ 比如，我们可以让发布的批量小一点点，从半年做一次上线发布，现在变成三个月发布，批量变得小了，是不是更敏捷了呢？当然改进要与能力的提升匹配，为了减小批量，往往需要流程、工具和工程的配套才行。 比如，我们可以持续减少发布过程耗时，依靠技术改进，比如集成流程的优化，自动测试改进，把一个月的发布变成了三周，是不是也变得更敏捷？ 我们想强调的是，从稳态到敏态是一个持续和连续的过程。而决定我们偏向敏态和稳态是三个变量。我们的改进也可以围绕这三个方面展开。 我们定义了理想的持续交付模式，我们把它描述为：单应用部署、单业务需求发布、最小化发布流程。也就是上图中的模式。 这是持续业务交付“完美”目标，是 BizDevOps 追求的理想模型，最卓越团队可以做到的。 然而，现实中我们有种种业务、技术和流程的限制。这一理想交付模式只是给我们指引方向，至于我们要走到哪一步，要依现实而定，我们既要考虑业务需要，也要考虑团队的能力和投入。 全量、全要素、实时数据支撑度量和持续改进 最后讲一下度量和改进，也就是第五个实践，我简单讲其中的一个部分。 今天效能度量成为大家的关注，我觉得热度有点过了。大家定了很多指标，但现实中起到作用的不多。为了澄清和选择这些指标，很重要的一点需要分清楚这些指标的类别。 指标体系有一个很重要的是业务结果指标，这是业务的最终目标，比如收入、用户转化和利润等。业务结果当然重要，问题是它很难建立与交付或产品团队的直接关联，这就失去了指标的引导改进的意义。 为此，我们定义了团队的效能指标，但我们必须明白我们要的并不是交付效能，而是业务结果。交付效能和业务结果之间是有一个转化函数的。我们要时刻检讨，这些效能真的能带动业务结果吗，转化函数有效吗？这个问题帮我们聚焦到有效的效能结果上去。 交付效能指标，对于研发要尽可能偏向结果，比如交付速度、质量、有效性等，这是交付效能指标。这些效能指标大家一定要清楚，它是业务结果的代理而已。应不应该使用这样的结果指标，我们在判断结果指标有没有问题时，最终都是看它对业务结果的影响是什么样的。 交付效能指标有一个问题，它无法直接导向改进行动。比如，缺陷密度太高，说明质量差，可是我们该做什么呢？所以我还会关注内部能力和行为指标，比如：说测试覆盖率、架构解耦度，这些是能力指标；比如：代码评审的比例，需求并行度这是行为指标。能力、行为都是为交付效能服务的，它们不是我们最终追求的结果，却是导向结果的依据和手段。 区分上面三类指标很重要，它们目的不同，用法也是不同的。越是左边的越是偏向内部，应该授权给团队，赋能他们去分析和发现问题。越是偏向右边的，越偏向外部，可以作为组织的导向和要求。我们可以说相对而言，左边的是指标，右边的是目标。我们要的是目标，而非指标。指标只是分析问题的依据。 度量是一个复杂命题，能用好度量的团队少之又少，这是现实。它的本质困难来自于业务创新和产品交付是一个复杂系统，很难靠一个预先确定的度量系统来衡量和约束。而且产品交付中也存在测不准原理，就是测量本身会干扰行为，从而得出错误的数据，甚至导向错误的行为。越是向内的和微观的，越难以测准，这一点和物理学的测不准原理也是一致的。 我讲的只是原则。其实最重要的是，降低对度量的期待，尤其把它作为管理手段的期待，然后才能正确的应用它，以目标为导向，指标更多的是赋能团队。如果能建立指标和目标的有效映射，并指导改进，那度量就能发挥作用了。 总结，今天从数字业务的创新和发展的交付看，组织的烟囱或竖井，依然是创新和交付效率和效果的最大问题。 我们看各个职能，他们往往是忙碌而“高效”的，当然这个高效是要打引号的。因为从客户角度、特别是业务角度就是另外一会事了。忙是内部的资源效率，客户感受到的是对业务需求响应和流动效率，业务感受到的是从想法到实现和验证反馈闭环的效率和效果，这些都往往与内部的繁忙相反。 事实上，敏捷、精益还有 DevOps 都在试图打破组织的竖井。但回到 BizDevOps 的视角，这是 Biz，这是Dev，这是Ops，Ops指的是运维，其实还有运营。那么，今天影响数字化创新的是这三个竖井，打通和融合它们就成立一个重要命题。 BizDevOps目标就是要打通这三个环节，业技融合，真正加速业务交付速度和形成有效的业务反馈、调整闭环。数字化业务转型已经成为时代的浪潮，相应的组织必须变革，实现蝶变，才能驾驭数字化的力量，弄潮数字化时代。BizDevOps 是我们驾驭数字化力量的必由之路。