您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
从DevOps到BizDevOps, 研发效能提升的系统方法
 
作者:何勉
  1342  次浏览      15
 2022-2-21
 
编辑推荐:

本文主要介绍了从DevOps到BizDevOps, 研发效能提升的系统方法。希望对您的学习有所帮助。
本文来自于微信公众号云效 ,由火龙果软件Linda编辑,推荐。

这几年“研发效能”一直是热词,很多组织都会启动研发效能提升专项。我与其中的很多有过深入的交流,他们中达成最终目标的并不多,经常是高调开始,草草收尾。为什么什会这样呢?

提升研发效能,首先要弄清楚要解决的问题是什么,然后才是落地解决问题的实践方法。否则问题没定义清楚,就很难有好的结果。

那提升研发效能究竟要解决什么问题?

我将提升效能要解决的问题,归纳为3个效能不等式。

> 三个不等式揭秘研发效能的本质

第一个不等式,局部效率不等于高效交付?

这一点,大家应该会感同身受。当我们去问各个部门或者个人时,都觉得他们很忙,效率很高。但是,我们去问业务部门或用户,却是另外一回事,他们会抱怨产品研发响应慢、交付迟、质量也不好。

这就是组织内部视角的局部效率并不等于用户视角的高效交付。这个是提升研发效能要面对的首要问题。解决它需要更有效的组织协同、更合理的交付模式,和更好的过程质量。

接下来的问题是,高效交付就够了吗?这就引出了第二个效能不等式。

第二不等式,高效交付能不等于持续高效

有的时候,为了高效的交付,我们可以采取临时动作,比如把一群人关在一起,成立一个临时项目,这样沟通协作会更便捷,这可能会达成一时的高效。但是,如果缺乏长期质量思维,当我们在做下一个项目,往往会发现问题,之前的代码和设计存在各种问题,比如可修改、可复用性很差,它们成为后续项目的负债而不是资产,长期的效率无法维持。

如何从高效交付转变成持续的高效,这是研发效能要解决的第2个问题。它对我们的工程和技术能力和实践都提出了要求。

第三个不等式,高效交付不等于业务成功

产品交付的目的是支持业务发展和业务创新。我们必须保证交付的东西,能解决用户问题,并构建可持续的商业模式,否则交付再多也没有意义。

今天,市场和用户的不确定持续增加,破解这一问题不容易。它需要整个组织能够聚焦用户问题,快速交付和试错,并形成有效反馈调整的闭环。做到这三点才能让高效交付转化为业务成功,这是提升研发效能要解决的第三个核心问题。

我们认为,研发效能提升的本质就是要解化解上面的三个不等式,从而把组织内的局部效率转化为用户可感知的高效交付,并保障持续的高效和带来业务的成功。最终实现:“持续地顺畅高质量交付有效的价值”。这是效能提升的根本目标。

> 研发效能提升实践体系

明确问题是开始,解决它们需要系统的实践方法。接下来,我们分享这些实践方法,它是我们对过去的实践的提炼和总结,并概括为这个图。

整个图分为三个模块:

左侧是协作和需求实践。左上方我们称之为业务驱动需求的协作模式和产品导向的交互模式,下边是以终为始的需求分析和设计。左侧这部分实践解决的是局部效率如何带来高效的交付。

右侧是工程与技术实践。右上方我们称为领域驱动的架构和实现,中间是标准化的工程基础设施,下面是应用为中心的持续交付,这部分实践解决的问题是如何让我们高效交付带来持续。

中间这部分是创新实践。它包含:如何高效探索业务、如何持续快速地完成业务交付,并形成有效的反馈和调整的闭环。创新实践要解决的问题就是高效交付如何带来业务的成功。

接下来,我们一步步展开,看一下各部分的关键效能提升实践。

>>协作和需求实践

首先我们来看协作需求实践。

在介绍协作之前,我们需要弄清楚协作的上下文——也就是当我们谈协作时,我们在谈什么。

让我们先从梳理需求交付的内在结构开始。

首先,产品交付都是源于目标,有可能是用户目标,如:更高效的完成某项工作;也有可能是业务目标,如:实现业务的增长,提高用户的黏性等。我们基于用户目标和业务目标规划业务需求。除了业务目标外,客户的具体诉求也会转化为业务需求。

业务需求的实现需要落地到产品中,它会被分解为一个个的产品需求。产品需求会进一步被分解为技术任务,通过实现技术任务来交付产品需求,最终实现对应的业务需求。

当然,产品需求并不一定都直接来自业务需求,产品也会做出自己的规划,包括架构的升级和技术重构,或者面向未来的前瞻性技术布局,如AI算法、区块链平台等。这部分产品需求,虽然不来自当下的业务需求,但它同样服务于业务目标,只不过是长期和未来的业务目标。

了解了产品交付的结构之后,接下来,我们看在这样的结构下,如何实现团队的高效协同。

>>>业务驱动的协作模式

首先,我们协同的结构应该和前面的产品交付需求层次结构一致。业务需求、产品需求和技术任务由不同的职能的人来负责,例如业务人员负责创建业务需求,业务人员和产品经理一起把业务需求规划分解为产品需求。

业务需求、产品需求、技术任务,这是交付需求过程中的基本价值单元。而文档、代码、测试、数据等都是为它们服务的,与应该向它们关联,并沉淀为资产。

业务需要被收集、管理、规划和交付,完成这些工作需要有独立的空间,它对应研发协同工具中的“业务空间”。在业务空间中,还要能看到业务需求是如何拆分为产品需求的。我们称之为管一层也要向下看一层,这样才能保证业务需求交付。

业务需求交付是一个动态的过程,需要清晰的工作流,它定义了业务需求从提出、接收、规划,直到发布、验收的整个过程。顺畅高质量地交付就是要让这个工作流更加顺畅,减少过程中的阻碍和等待。

与业务需求一样,产品需求也需要被收集、管理、规划和交付,研发管理工具,同样要为产品人员提供专属的产品交付空间,并定义产品交付的工作流。技术开发者也需要对他们友好的工作台。在这里,他们接受、管理、计划和完成技术工作。

更重要的是,我们需要让这三个层次三者变成有机的整体,让大家真正的协同起来,顺畅的交付业务需求。这三个层次的工作流是相互关联,业务需求规划后被拆分为产品需求,产品需求会被进一步拆分为任务,这些是自上而下的。

再看自下而上的,下层的工作完成后,它的状态要能够被自动卷积上去,比如产品需求下所有的任务完成后,对应的产品需求进入待测试状态。业务需求所有产品需求完成后,业务需求的状态也需要自动变更。

这三个层次的联动和透明,让问题和阻碍更容易被识别,比如业务需求交付延期或者出现问题时,能清晰的看到是哪一个产品造成的,应该在哪里采取动作。

我们把这称为业务驱动的协作模式。组织中不同的职能和团队,必须相互协同完成业务交付,达成用户或者业务的目标,业务驱动的协作模式,让这一过程更加透明和高效。

>>> 产品导向的交付模式

前面讲的是协作模式,企业的业务需求最终还是要到落实到产品交付团队中交付的。以前我们更多把IT交付团队看成成本中心,先确定需求范围,再确定时间,然后分配资源、成立项目、完成交付这也被称为项目导向的交付模式。

项目导向的交付本质是把人作为资源分配到事情上。其背后的假设是未来是确定的,在确定的时间内交付确定的内容。它强调计划和执行,追求交付的确定性。

确定性今天已经越来越不现实,组织必须学会与变化共舞。另外,项目导向的交付导致短期思维,缺乏工程、技术长期改进意识。同时,因为团队的临时性,也无法持续团队的交付效能。

数字化时代,我们需要从项目导向的交付模式向产品导向的交付模式迁移。产品导向的交付模式本质是把事情交给跨功能的特性团队,由相对稳定的特性团队持续的接受并完成需求的交付。

特性团队对产品的迭代负责,他们拥抱业务的不确定性,并为此不断演进产品。特性团队要维护产品,必须建立长期思维,注重代码资产和工程资产,并持续改进团队交付能力和交付流程,提升交付效能。

但这还不够,因为如果各个产品各自为政,任何特性团队的需求过载都会让它成为整个业务瓶颈,解决办法是,同一业务领域的多个特性团队,共享同一需求列表。这就让一个团队出现资源瓶颈时,需求可以分配到另一个团队,这与今天很多服务行业中实行的,“一个队列多个服务窗”的本质是一致的。

>>>以终为始的需求分析和设计

前面,我们讲了,企业的协同模式应该是业务驱动的,团队的交付模式应该是产品导向的,它们解决协同流程的问题,但光有流程是不够的,我们还必须保证输入的质量。

IT行业有一句著名的话:“输入的是垃圾,输出的也会是垃圾“ 。需求的输入,是交付过程是源头,也是最关键的部分。如果输入的有问题,交付的中间过程也不可能顺畅。那我们应该怎么做呢?

“输入垃圾,输出垃圾”的反面是以终为始,——也就是在需求输入的时候,团队要知道最终要做成什么样子,并在业务、产品和技术之间达成一致。

那么,怎样才叫以终为始呢?以终为始分为3个方面:

第一,对于业务需求,要有明确的业务目标,并基于目标定义清晰的业务流程,确保业务流程可以支持业务目标的实现,这是业务分析要完成的工作。

第二,对于产品需求,它要能支持业务流程的实现,为此我们要基于业务流程,明确定义产品的功能,对于每一个产品功能,首先要明确用户使用的交互流程,并在交互流程的基础上,明确验收标准。

第三,明确业务需求、产品需求之间的结构,也就是业务需求和产品需求之间的层级关系。这对后面的团队协作都很重要,我们协作交付的目标不是产品需求而是业务需求,只有结构清晰,协作的时才知道这些产品需求如何协同向业务对齐,完成快速交付业务需求。

总结一下,业务分析和产品设计分是一个金字塔的结构:

需求永远源自业务目标,基于业务目标分析业务流程,基于业务流程分解产品需求,并对产品需求进行设计。

金字塔的上面两层:是业务分析关注的。我们引入了“事件驱动的分析”方法,——基于目标和业务事件分析业务流程,并基于业务流程拆分定义产品需求,并划分最小可行产品(MVP)。

金字塔的下面两层:是产品设计所关注的。在业务流程设计的基础上,分解出产品需求,并对产品需求进行澄清。澄清和设计需求最好的方式是以用户使用实例来说明操作流程、验收规则是什么样,也就是用户在什么情况下,做什么操作,将得到什么结果。我们引入了“实例化需求”分析方法来支持这一过程。

通过系统的业务分析和产品设计方法,在需求上从GIGO转变为以终为始,这是局部效率转化为高效交付的重要一环。

下面,让我们在从另一维度,解释一下协作和需求实践,以上图的产品截图为例,总结一下,我们在协作部分要做到的三点:

第一点,我们要看到并且要管理端到端的业务需求的交付过程,我们称之为前后职能拉通。这些职能可能是业务、产品、开发、测试,部署和运维。我们要拉通这些职能,让他们更高效的配合,让业务需求从左到右顺畅的流动和交付。

第二点,左右模块对齐。一个业务需求可能会分解到不同的产品里面,每个产品都有自己的工作流,产品的交付要向业务的交付对齐。

我们的目标不是让某一个产品忙起来,而是让业务需求的交付更顺畅。所以各个产品都要向业务需求的交付对齐。研发管理工具上也要能实现这一点,包括,规划上对齐产品和业务需求,以及在执行过程中对齐产品和业务,并即时发现因无法对齐带来的阻碍和等待。

第三点,内建过程质量。需求在每个阶段应该有明确的质量标准并执行到位,例如需求输入的质量要做到以终为始,需求测试的质量、测试转发布等都应该有明确的标准。质量应该建立在每个需求的每个阶段之上,而不是成批的依赖于最后的检测阶段。

我们要做到前后职能拉通,左右模块对齐,内建过程质量。最终形成这样下图所示的协作模式。

图中每个节点都是一个具体活动,这些活动有它的节奏、负责人、输入输出,以及实践方法的支持,如前面提到的事件驱动的业务分析和实例化需求等,这样才能让业务、产品、技术真正形成一个整体,做到这样顺畅和高质量的交付业务需求。

>>技术和工程实践

技术和工程部分,我们究竟要解决什么问题呢?我们先看一幅图。

上图横轴是时间,纵轴是生产效率。我们希望效率是沿着绿色线一路向上的,但是现实中可能随着时间的推移、产品变得复杂、团队规模变大,而效率反而降低。

区分这两条线的核心就是在工程和技术实践上,它决定我们积累的到底是资产还是债务,也最终决定了长期的效率。

>>> 领域驱动的架构和实现

在技术方面,我们要持续积累并维护好领域资产,让它易于理解、扩展、维护和复用,今天业界普遍都认识到领域驱动设计的重要性,也愿意投入精力。然而,领域驱动设计要发挥作用并不容易。

领域驱动设计不仅仅是设计的问题,它是涉及需求、架构和实现的系统工程。需求和业务是源头,架构是枢纽,而他们都需要落地到现实当中。最重要的是如何把需求、架构和实践真正连接起来,连接他们的是领域模型。

如上图所示,我们从业务需求开始去分析业务流程,基于业务流程分解和设计产品需求,通过实例化需求定义验收测试,澄清和细化产品需求。更重要的是,在整个的需求分析的阶段中,我们要不断地提取和精化领域模型。因为对领域的认识和抽象来自于每个具体的业务、具体的需求,所以被称为“业务引领的领域建模”。

领域模型应该成为应用架构设计的基础。我们基于领域模型去划分子域,设定子域的上下文,基于领域模型去定义接口的设计契约,划分子域和限界上下文,并约束微服务的边界,让微服务成为可复用的领域资产。限界上下文和服务契约最终保障领域资产的可复用。所以我们称为“领域引领的微服务架构”。

在实现上,领域模型、验收测试、服务设计契约都是高质量代码的约束和指导。我们的代码要体现领域模型,与架构和接口契约一致,并符合相关验收标准。

同时,测试先行的方式,让我们有更靠谱的自动化测试,而自动化测试会让我们的重构更有保障。持续的重构又保证代码资产不会快速腐化,维持系统健康。

今天分享的更多还停留在概念层面,但是我希望能在思考规划上给大家带来启发。除非你认为你可以牺牲长期的质量,你不需要积累一个长期可重复的资产,那么上述这些都是不可或缺的。

>>>标准化的工程基础设施

接下来我们看工程部分。今天比较幸运的是,我们看到工程部分的技术趋势正在收敛。

我们看到基于容器管理和分发制品,基于k8s编排环境资源,这一部分已成为了一个事实,大家都不再考虑要不要做,而是什么时间做,或者怎么做的问题。这个方向大概率不会改变。但问题是,我们讲容器,更多还是站在资源的视角去看,即站在运维的视角,但是在开发视角,看到的是代码,代码对应的是应用。如果仅做到这一点,开发和运维之间还是有隔阂,他们所面对的对象就不同。

今天我们看到另外一个趋势,是基于OAM的标准去做应用管理。OAM的标准是阿里和微软共同提出的叫做开放应用模型,基于OAM可以管理应用的开发、编排和运维。OAM是一个标准,基于这个标准,开发可以声明式地编排应用,运维也可以基于已有的声明进行自动化的运维。

OAM 面向应用的部署和运维的终态,统一了应用开发和运维的基本模型。它首先提出了应用描述的基本模型,包括应用的拓扑、资源依赖、部署方式、运维方式等,然后定义声明式的应用编排、部署和运维方式。OAM基于应用,统一了开发和运维的基本语言,让应用成为开发和运维共同的关注和操作的基本对象,解决了技术基础实施的问题,让真正的DevOps 成为可能。

但是这个离真正的DevOps还差一点,我们刚才讲的只是我们有了DevOps的基础,我们从部署这个阶段基于这样的标准,但是我们还没有定义我们的应用是怎么交付的。如果把应用和交付这一部分也包含进去,就会实现真正的DevOps。

我们看这样一幅图,如下图所示,我们这样定义应用的变更流程

首先,我们要解耦部署和发布,部署是技术行为,发布是业务行为。我们希望每一个应用可以单独部署,所以我们要解耦部署发布,以应用为单元,持续的集成和部署。

但是这还不够,应用的变更从哪里来?应用来自于业务需求,业务需求拆解为产品需求,产品需求对应一系列应用的变更。

每个应用的变更都有自己的流程。当这个业务需求对应所有的应用变更部署完成之后,这个业务需求也应该能够完成发布。

我们的工具、流程、操作要能够连接起这些应用的变更和产品需求,直至业务需求。这样我们就能够做到以业务需求为单位发布——当一个业务需求下所有的变更都部署完成后,业务需求可以随时发布。

我们认为持续交付的最佳形态是以单应用为单位变更部署,以单需求为单位,需要的时候就去发布,在此基础上,我们就有机会建立起最快速的业务闭环。

以上是我们看到云原生持续交付的形态,也就是以应用为单位的持续部署,业务为需求单元的持续发布,前提是,我们以应用统一了开发和运维的基本单元。

总结一下,我们认为云原生下的BizDevOps的形态是什么?有三点:

面向终态,基于开放应用模型OAM,形成运维和开发底层模型的一致化和标准化。

以应用为核心,连通应用的开发、集成过程和部署运维过程,实现云原生时代的DevOps。

连接并对齐业务需求与应用变更,并完善反馈闭环,实现真正意义上的BizDevOps 。

> 总结

效能提升,必须从清晰定义问题开始。

我将提升研发效能要解决的根本问题总结为三个效能不等式。化解这三个效能不等式,需要系统的实践。

第一,让局部效率转化为高效的交付。为此,我们需要落地业务驱动的协作模式和产品导向的交付,同时在需求上要做到真正的以终为始。

第二,让高效交付可以持续,为此,在技术上要做到领域驱动的架构和实现,不断积累和优化领域技术资产。在工程上,要建设云原生的标准化基础设施,并以应用中心打通开发运维和连接业务的需求,最终实现以应用中心的持续部署和以业务需求为中心的持续发布。

第三,让高效交付带来业务成功。为此,需要建立业务探索和持续交付之间的快速执行和反馈的闭环。

以上3点的共性是,它们都以业务为起点。比如:以业务需求驱动组织中各个环节和部门的高效协同;从业务目标开始,分析业务流程,并分解设计产品;连接业务需求和产品应用变更,实现业务需求的持续发布;建立业务探索和持续交付之间的快速闭环。

落地这些实践,必须打通业务( Biz)、开发(Dev)和运维(Ops),让他们成为一个高效运作的整体,建设BizDevOps实践体系,赋能数字化时代的组织,加速业务发展和创新。

   
1342 次浏览       15
 
相关文章

中台产品面面观
如何在互联网产品中建立中台?
什么是产品生命周期管理?
产品设计之前,如何分析业务需求和用户痛点?
 
相关文档

产品经理是怎样炼成的
APP产品规划方法
产品经理培训文档
产品生命周期管理PLM
 
相关课程

产品经理与产品管理
卓越产品经理训练营
产品需求分析与管理
基于用户体验的产品设计
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
AI产品经理入门实例讲解
AI 产品经理如何练就
如何做一名AI产品经理
看合格的产品经理是如何制定产品战略
产品经理如何去做版本迭代规划的
最新课程
产品经理与产品管理
卓越产品经理训练营
产品需求分析与管理
基于用户体验的产品设计
更多...   
成功案例
某单位研发中心 产品集成与服务平台
中物院 产品经理与产品管理
船舶系统 以用户为中心的产品设计
亿阳信通 产品经理与产品管理
中物院 产品经理与产品管理
更多...