深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法

简介：研发效能提升不知从何下手、一头雾水？阿里资深技术专家一文为你揭秘研发效能提升的系统方法。

注：本文是对云栖大会何勉分享内容的整理

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

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

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

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

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

第一个不等式，局部效率不等于高效交付？

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

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

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

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

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

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

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

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

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

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

研发效能提升实践体系

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

整个图分为三个模块：

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

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

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

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

协作和需求实践

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

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

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

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

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

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

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

业务驱动的协作模式

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

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

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

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

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

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

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

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

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

产品导向的交付模式

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

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

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

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

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

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

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

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

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

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

那么，怎样才叫以终为始呢？以终为始分为3个方面：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

技术和工程实践

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

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

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

领域驱动的架构和实现

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

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

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

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

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

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

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

标准化的工程基础设施

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

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

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

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

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

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