BizDevOps：从理念到实践，贯通企业全链路协同

👆

点击蓝字关注我们

引言

BizDevOps的概念由DevOps发展和进化而来，其目标超越了开发和运维的协同，进一步实现业务、研发和运维的全链条协作，让业务作为价值的起点及核心目标。

BizDevOps的核心驱动力在于解决效率和正确性上的割裂问题，尤其是在金融等对数据敏感性要求极高的行业。

最早的DevOps实践是为解决开发与运维之间的沟通障碍而生。比如在监管有严格的数据安全要求的金融行业，开发人员被限制访问生产数据，造成了开发和运维效率的极大降低。而DevOps实践在保障生产安全的前提下使开发与运维能够更高效协同。

但大家逐渐又发现在业务与研发之间也存在显著的隔阂。业务团队关注如何推动产品增长与创新，而研发团队则更关注如何高效完成功能开发和问题修复。这种目标和视角的差异往往导致误解和效率损失。BizDevOps由此诞生，它主张将业务拉入研发和运维管理的价值链中，形成一个业务和技术双向融合的管理模式。

业界最近对BizDevOps比较热，主要也是由于市场环境导致的投资谨慎，企业越来越重视投资方向的精准度和效率，自然也会关注研发投入的业务价值，不仅关注“正确地做事”，更关注“做正确的事”。

整体来看，目前BizDevOps实践落地最多的行业还是泛金融。在2022年初时，央行发布的《金融科技发展规划（2022-2025年）》中就明确提到了这个概念，鼓励金融机构借用这种方式搭建低成本试错、快速迭代的交付模式。现在BizDevOps也已有了相关国家标准。

组织怎么去落地BizDevOps呢？我们认为重点从四个关键点着手来逐步推动业务、研发和运维的深度融合：一是建立多维度的管理视角，二是构建统一的管理概念模型，三是梳理全流程管理规则，最后是打通从业务到研发到运维的工具链条。

建立多维度管理视角

组织首先应该转变意识，接受管理本身就是多维的，避免“万物皆项目”的单一管理模式，所有的管理流程、管理工具的设计都需要考虑到不同的管理视角。

对于研发组织来说，需求是管理的“原子”，围绕需求管理，组织应建立产品、项目、系统和团队等不同视角，来进行对应维度的管控和能力建设。

产品视角：研发团队不仅要完成业务方的需求，更需要构建面向未来的产品化能力。产品视角要求研发人员深入理解业务需求的核心动因，考虑需求的延展性。例如，业务部门提出一项需求时，研发团队不能只考虑当前的实现，还要基于对业务的理解预估未来的需求，以此为基础设计实现方案，给未来留下可能性的同时提高后续的响应能力。如果业务方提什么就做什么，就很容易形成“被动挨打”的局面。
项目视角：项目管理重在执行过程管理，确保需求按时高质量地交付。项目管理为组织提供了清晰的关注重点，能够帮助组织聚焦于少数重点项目，而不是迷失在海量的需求列表中。同时，项目视角有助于将组织的注意力集中在关键成果上，保障项目的推进。
系统视角：在系统管理层面，架构师需要关注系统的安全性、架构合理性和技术健壮性，以及划分系统之间的职责边界。这一视角确保了系统在开发和部署过程中的一致性和可扩展性，同时避免技术债的积累。
团队视角：团队视角以长效团队为基础，强调组织内的协同效率，以团队为单元进行效能的度量和评估。

这里我们说的团队，一般会有两种形式：

一种就是职能化组织，比如前端团队、后端团队，对于这种可以先尊重组织现状，因为现状一定有历史原因，实体部门相对来讲变革进程稍微慢一点。

另外一种我们叫虚拟组织，一般是研发面向业务领域的团队，比如说假设组织有10个服务财务的系统，但这些系统可能不光服务财务，也服务别的部门，这时我们提倡面向财务组建一个战队，就相当于把这10个系统的人分别抽一点，组成一个专门服务财务的虚拟组织。这有点像华为成立军团的思路，一旦面向财务的战队出来了，那这个战队的负责人自然就非常关心财务的体验，他对财务领域的学习、规划就自然会加强。

团队视角本身其实也是一个多维视角，组织内还可能存在COE、行会等形式的虚拟组织。比如说有两个前端部门，但组织对于前端这个职能的人还是希望拉通管理，并不希望因为实体部门的割裂带来整个职能的割裂，所以组织会从这个角度建立产品经理行会、项目经理行会，或者说产品COE、项目COE等虚拟组织，作用就是把同样工种的人拉到一起，可以统一做职级评定、工具建设等等。

构建统一的管理概念模型

明确要观察和管理的视角后，构建一个统一的管理概念模型能够帮助组织内的不同角色在同一框架下进行沟通和协作。不同组织的管理术语和概念存在差异，需要对管理概念的系统化梳理，以消除内部沟通障碍。

我们举一个组织的管理对象模型作为例子，如下图所示，可以将管理对象划分为以下四个领域：

组织架构领域：包括实体部门和虚拟团队的多维组织架构。
产品系统规划域：明确组织内部产品和系统的情况与布局。
需求任务域：将需求由来源到落地的过程层层拆解为子需求、开发、测试等具体任务。
交付管理域：负责项目的进度追踪和产品、系统版本的交付上线管理。

在梳理过程中，重点要识别和定义出研发端与业务端衔接的管理对象，这其中核心的就是需求任务管理体系，将需求从业务规划向下逐层拆解或向上关联，使得需求向前延伸对齐业务价值。拆解完了再去关联别的管理领域：

关联组织架构就是明确分工的过程——这个事谁来负责？
关联产品和系统就是与长期的产品系统规划做关联——这个能力应该放到哪个产品、哪个系统里实现？
关联交付管理域就是在管理成本——这个需求在不在项目范围内？有没有超期或超成本？计划在哪个版本上线？

其实在大部分研发组织的需求体系中，能够确保后半段的研发交付，却很难向前延伸到业务价值。所以这里我们特别提出的是要从业务规划开始，大事化小、逐层分解，向上承接战略，向下落地需求，如下图所示（在不同组织内需求体系和叫法可能都不同，以下名称仅为示例）：

在业务规划层先结合企业整体战略和财务预算制定业务目标，再将目标分解为几件大事，转化为业务主题，然后将所有的业务需求关联到业务主题，来分析这个需求的重要性和优先级。

这些大的工作事项罗列出来，更容易监测和管理投资回报。在我们既往的客户案例中，一种实践经验就是IT定期与业务召开月度或季度检视会，分析和反馈IT这个周期交付的需求、质量等，同时也要求业务反馈需求的价值，并探讨改进。这样的反馈闭环会让业务对科技的投入也逐步建立成本意识。

有了业务主题后，再拆解到业务需求，业务需求就是客户最原始忠实的需求记录，由产品经理转化为产品需求。这种方式也有利于产品经理的培养，产品经理需要学好对应领域的专业知识，对业务需求进行翻译，促进其提升对产品的规划能力。接下来，产品需求可以继续拆为系统任务，这一步考验的是产品的架构能力、设计能力，需要识别确定出最适合承接这个需求的系统。

对组织整体管理概念与需求的层级体系的梳理，其实就是对组织关注点的管理，每一个领域、每一个层级都有对应的管理重点，越大型复杂的组织，管理模型就越复杂、管理层级越多。

梳理全流程管理规则

有了管理概念模型，明确了需求体系，组织需要进一步制定贯穿全流程的管理规则，即建立每个管理对象的价值流，并明确其状态切换的责任人和准入准出标准。这些匹配价值流的细致规则我们也把它叫软件研发的工艺。

由于软件研发相对于制造业来说柔性更强，所以设计这个流程规则时掌握好平衡点很重要，既不能没有管理规则也不能过分精细死板。标准化不能以牺牲柔性为代价。我们目前推荐的做法是针对每个重点管理对象设计一条单链价值流，以此为基础明确重点价值流状态的准入准出标准，但对于每个环节的执行过程中可能存在的不同情况不进行详细约束，而是通过指南或者checklist等灵活方式引导执行，而不是用过于细致的规则束缚团队。

在流程规则的建立过程中，建议组织成立EPG或流程委员会，组织大家讨论并进行决策，以问题驱动的方式进行持续迭代，逐步完善研发工艺与流动规则。

打通Biz-Dev-Ops工具链条

BizDevOps的有效落地离不开工具的支持。统一管理概念模型后，组织需要将管理规则落实在工具上，保障管理流程的执行。

在这个过程中，组织也需要梳理工具体系，明确各系统的定位，确定每类数据的主数据源和同步方式，通过工具链条拉通从业务到需求、开发、测试和部署过程，确保数据的有效沉淀。与此同时，跨部门的数据同步与共享视图使得业务、研发和运维可以实时跟进任务状态，减少不必要的重复工作，促进线上化高效协同。

在数据沉淀的基础上，组织可以通过数据度量进一步优化管理规则，通过不断的反馈与改进，提升整体效率。

结语

BizDevOps将业务、研发和运维深度整合，代表着打通全链路协同的美好愿景，能够帮助企业优化投资方向，从业务价值出发实现更高效、精准的资源配置。这个全链路的打通最终需要通过工具来落地，实现数据的串联以支撑决策。

随着DevOps工具链的普及，研发和运维相关工程域的自动化工具已经非常成熟，但是延伸到业务端，业务和管理的复杂性导致了组织间存在极大的差异，很难直接复用现成的管理工具。所以在本文我们探讨的思路中，需要先从管理理念、管理概念、管理流程和规则进行系统化梳理和统一，再来思考如何整合组织内部工具体系，实现数据和信息的流通。

END