一体化协同平台助力企业回归生产本质，创造价值

---

核心观点

• 单点工具的串联无法有效解决研效痛点问题，企业需要通过一体化协同平台提高端到端价值流动效率。
• 一体化协同平台的价值是软件工程理念最大化落地、数字化研发管理、沉浸式研发体验。
• 一体化协同平台集成需要评估闭环效率杠杆，确定集成边界和集成深度。
• BizOps 和 FinOps 的出现，代表一体化协同趋势正在回归“生产本质”，创造价值。

一体化协同平台概述

“妥协式”研效治理

目前，越来越多的企业选择通过数字化转型应对市场的不确定性。软件作为数字化的直接载体，软件研发效能治理（简称为研效治理）成为企业数字化转型的关键，企业期望通过引进优秀的研效文化、方法论、技术，重塑组织职能边界，优化分工效率；通过创新软件研发流程，面向“价值”协同；通过引进自动化工具链，优化价值流转效率。

然而，市场竞争是残酷的，软件研效治理也一直在进行，开展新的软件研效治理不得不向“业务连续性”和“IT 固有资产妥协”，研效治理变为“妥协式”研效治理，落地效果大打折扣，如图 10.7.1 所示。

业务连续性妥协

大多数企业都缺乏渐进式研效治理的经验，如何小规模试点，从边缘业务向核心业务推进，是摆在企业面前的难题。为了保障业务的连续性，不对现有组织结构和业务流程造成影响，在软件研效治理的过程中，往往会牺牲“组织变革”和“流程创新”。

图 10.7.1 “妥协式”研发效能治理

IT 固有资产妥协

研效治理对企业来说是贯穿“整个生命周期”的使命，为了保障自动化需求，需要购买和维护大量的自动化工具。在新一轮研效治理中，为了不造成IT固有资产的浪费，企业常常选择补齐面向职能单点的自动化工具，提升单一职能的工作效率。如图 10.7.2 所示，企业已经存在客户管理、项目协同、代码仓库等工具，痛点在代码的集成和应用发布上，考虑到已经发生的工具采购成本，企业通过引入 Jenkins 和 ArgoCD 提高 CI/CD 单点效率，这种情况即为 IT 固有资产妥协。

图 10.7.2 IT 固有资产妥协

“妥协式”研效治理的痛点

“妥协式”研效治理仅引入新单点工具，通过自动化手段提高单一职能工作效率，而单点工具之间的串联大多是通过 Webhook 机制在 backend 级别打通的，而账号、权限、交互没有被打通，如图 10.7.3 所示。基于这个客观事实，单点工具在研效治理中存在职能内工具使用不标准、跨职能协同效率低、跨工具切换成本高和维护成本高等痛点，如图 10.7.4 所示。

图 10.7.3 单点工具

职能内工具使用不标准

单点工具解决单一职能内的工作效率问题，不解决单一职能内标准化作业问题，如果工具不能被标准化使用，则意味着团队与团队之间、员工与员工之间存在使用效率和交付质量的高低问题。

图 10.7.4 单点工具痛点

跨职能协同效率低

单点工具之间的信息传递是不标准的，但跨职能之间的协同依赖于上游信息传递的标准化，比如信息的有效性、完整性、及时性，否则就可能存在需求已确认，但研发人员、测试人员、设计人员、运维人员都不知道，无法开展自己的工作，研发工序与工序之间存在大量的前置等待时间，这些时间最终会变为工作流中一个又一个的效率“洼地”。

跨工具切换成本高

在研发工作流中，单一职能的生产者需要横跨多个工序完成工作，比如研发人员需要从项目协同（Jira）领取需求、代码仓库（GitLab）完成编码、持续集成（Jenkins）查看构建结果、持续部署（ArgoCD）确认发布物料、发布之后需更改项目协同（Jira）的需求状态，完成一个需求需要跨多个工具，切换成本非常高，这使研发人员无法专注于价值创造，单一工具的引入从研发赋能变成了研发“负”能。

维护成本高，管理难度大，无法有效度量

维护成本高：在单点工具自研或采购后，企业需要安排 IT 资源运行和运维，而稳定性的保障工作成本较高。

管理难度大：单点工具之间是有限串联的，这也就意味着企业需要在不同工具之间维持账号和权限的一致性，一旦出现不一致，其影响可能是灾难性的，比如项目协同工具中不属于某项目的成员，可以在发布工具中执行该项目的发布。

无法有效度量：单一工具的数据是相对完整的，但由于工具使用的不标准、跨职能协同等待时间无法度量、工具切换消耗了大量时间等因素，因此度量失去了参考意义，企业无法有效地洞察效能瓶颈、持续改进研效治理。

组织职能僵化，无法应对软件复杂性的挑战（图 10.7.5）

图 10.7.5 应用复杂性对软件工程的挑战

软件的微服务化大大增加了运维人员的工作量，如果还只是依靠运维来负责整个软件的发布，则运维人员的规模无法匹配软件微服务的规模，于是软件发布这一工序会成为效率卡点。然而软件的微服务规模通常和研发人员的规模成正比，如果能重塑研发和运维之间的职能边界，将软件发布左移至研发，则可大大缓解软件微服务化对发布的挑战。

从制造业看生产理念和流程创新

制造业生产方式的演进，如图 10.7.6 所示。

图 10.7.6 制造业生产方式的演进

在制造业生产方式的演进历史中，福特汽车的流水线和丰田汽车的精益生产理论分别代表了流程和生产理念创新，两者为提升企业生产效率、改善产品质量、降低制造成本做出了巨大贡献。相比制造业数百年的历史，软件工程的发展还不到 60 年，如今的成熟度还远远不及制造业，从福特和丰田的创新带来的巨大价值看，软件研发流程重构和面向价值协同的生产理念同样非常重要。

基于对“妥协式”研效治理痛点的分析，企业需要的不是单点工具，而是能闭环研发活动的一体化协同平台。一体化协同的本质是企业面向价值的协同文化统一、优化价值流转效率的软件研发流程重构、提升资源效率的自动化工具链建设，其中任何一项都是不小的投入。那么，一体化协同平台到底能为企业带来什么价值呢？

一体化协同平台的价值

图 10.7.7 所示为一体化协同平台的整体价值图。

最大化落地软件工程认知

“锅碗瓢盆的拼凑，不会解决做饭的问题”，同样的，单点工具的串联也不能解决软件研效治理的问题。一般企业是先通过对精益、敏捷、DevOps 等卓越工程理念的学习；然后结合对企业研效痛点及内部业务模型、组织模型、应用模型的思考，完成企业组织自上而下的软件工程认知升级；最后通过工具落地企业对软件工程的全新认知，包括软件研发统一管理、端到端的协同方式、质量内建、度量、合规生产、双态多端治理等问题，这些问题绝不是开源单点工具能够落地的。很难想象，ArgoCD 面向单一场景的工具会考虑企业的软件工程认知如何沉淀、如何落地。比如，发布之后自动修改项目协同的需求状态、自动归档代码仓库的发布分支、修改制品的元数据、记录发布信息。

图 10.7.7 一体化协同平台的整体价值图

不同于单点工具，一体化协同平台的核心价值是最大化落地企业的软件工程认知，无论是质量内建，还是重构端到端的协同方式，都不会受限于单点工具的能力，并且企业可通过一体化协同平台产生的全链路软件研发数据，持续升级软件工程认知，持续改进软件研发效能。

数字化研效管理

一体化协同平台需要实现研发流水线的工业化，其特征是信息化、自动化、标准化、流程化，信息化保障了全链路数据的完整性；自动化和标准化拉平了因人而异的效率差异，保证了数据的客观可信；流程化则抹去了单点工具切换引发的前置等待时间，保障了数据的有效性。这些工业化特征数据，使企业软件研发的价值、过程、成本变得可被度量，企业研发管理人员可依据这些度量结果展开数字化研效管理活动。

沉浸式研发体验

一体化协同平台通过重构软件研发流程，实现了统一编排和配套工具链的深度整合，研发流水线协助研发人员实现了自动化的上下游协同，使研发人员专注于应用编码，无须在多个系统之间切换，真正实现了沉浸式研发体验，提高了研发效率。

举一个研发上下游协同的例子，在产品经理将某个需求分配给研发人员后，一体化协同平台会根据需求名称自动创建特性分支，分支被创建后会自动通知该研发人员，其仅需要本地 checkout 该分支即可开始编码。代码一旦提交，持续集成的测试环境流水线会自动触发执行代码 clone、构建和运行单元测试、代码扫描、制品推送、测试环境部署。流水线运行成功后，需求状态自动修改为「待测试」，这时平台会自动通知需求的关注人，测试人员收到通知开始测试工作。整个流程中如果没有质量门禁不通过或者测试失败的情况，研发人员仅需要关注应用编码和代码提交，真正做到了工具服务于人，而不是人服务于工具。

一体化协同平台的实现

设计思路

端到端闭环

端到端闭环是指一体化协同平台重构软件研发流程，集成软件交付过程中的主要活动和工具，统一单点工具的账号和权限，解决研发过程中工具频繁切换和工具之间信息割裂的问题。为提高软件交付端到端流动效率和软件交付质量，企业需明确集成边界和集成深度，以及工具分工边界。

（1）集成边界和集成深度：评估闭环效率杠杆，确定集成边界和集成深度。

一体化协同平台对单点工具的集成并不是越多、越深就越好，需要拉通软件交付整条链路，评估集成对闭环效率高低的影响，确定是否集成和如何集成。如果我们把一次端到端软件交付当作一次交付闭环的话，则闭环效率杠杆是指集成工具对闭环效率影响的大小。下面以设计工具、CMDB、项目管理为例，通过对集成效率杠杆高低的分析，分别采用不集成、部分集成和完整集成的方案。

首先是不集成，以设计师常用的设计工具 Figma 为例，设计活动主要由产品经理、设计师、前端工程师、测试工程师参与，Figma 本身已经为跨职能场景提供了协同能力，因此设计活动能够在 Figma 中完成闭环，这时一体化协同平台无须集成 Figma，因为集成的核心价值在于完成全链路的协同闭环，而现在这个闭环已经实现，任何投入只有成本而没有收益。因此，一体化协同平台仅需要在需求中关联 Figma 的设计稿即可，以保障需求信息的完整性。

接下来是部分集成，以运维人员维护IT资源信息的 CMDB 为例。在软件研发过程中，存在大量的机器资源依赖场景，比如持续构建机器资源、代码扫描机器资源、制品扫描机器资源、自动化测试机器资源、发布机器资源等。运维人员一般会先在 CMDB 中维护这些资源，比如资源规格、资源业务归属、资源应用归属、供应商、采购成本等，然后按资源使用权限（业务和应用隔离）交付给对应的研发人员。在这种场景下，由于 CMDB 影响闭环效率的是资源交付活动，因此 CMDB 的集成仅需完成资源交付的集成即可，资源维护的功能还是在 CMDB 中完成。资源交付会通过一体化协同平台的 OPEN API 和 CMDB 完成集成，提高资源交付效率。

最后是完整集成，以项目管理工具 OmniPlan 为例。OmniPlan 可以帮助项目管理人员完成任务划分、里程碑制定、项目排期等工作，在可视化和信息结构化上做得不错，但是由于 OmniPlan 和研发活动中其他工具之间的割裂，直接降低了闭环效率，比如和代码仓库与测试管理工具的割裂，导致研发人员和测试人员不得不通过在多个系统中切换来完成任务状态修改，这种情况就需要考虑完整集成，提高闭环效率。

（2）工具分工边界：标准的交给工具，不标准的交给人。

其是指把重复的、标准的活动交给工具，如需求状态流转、上下游信息协同、单元测试执行；把非标准的、具有价值创造性的活动交给人，如代码编写、任务拆分、测试用例编写，以最大化价值流动效率和资源转换效率。要做到这一点，就需要一条工业化研发流水线引擎，其需要串联软件研发所有活动及其配套工具，并为每一个活动设置活动标准执行规范、活动状态上下游流转规则、活动上下游信息同步规范，如图 10.7.8 所示。

图 10.7.8 工业化流水线

质量内建

丰田的流水线相比福特的一个重要创新，就是加入了质量检查和快速止损的环节。福特的流水线一旦运行，质量问题只能在最后被发现，造成流水线的良品率较低。而丰田的流水线，加入了质量检测环节，并配有“安灯”按钮，一旦流水线上发现质量问题，即可通过“安灯”按钮中断生产，修复产品质量后再运行流水线生产，大大提高了良品率。

而在软件研发流水线中，也需要将代码扫描、单元测试、接口自动化测试、制品扫描、制品依赖分析等质量检测能力有机地整合在流水线中，并且将这些质量检测的结果标准化，再配合质量门禁配置规则实现质量问题的快速拦截，早发现，早修复。

扩展性

平台的集成是有边界的，往大了看，研发一体化协同平台也只是企业数字化转型中的一环，因此在企业数字化业务场景中，一体化协同平台会存在大量集成、被集成、定制化的需求。我们可以从 webhook、OPEN API、UIKit 三个维度建设系统的扩展性，以应对扩展性的挑战，比如不同部门希望有不同的度量大盘，而依靠平台统一建设会非常缓慢，此时平台只需要提供统一的UIKit和数据拉取 OPEN API，最后的度量大盘可交由部门内部闭环建设。

可度量

德鲁克说：“如果不能度量，就不能有效管理”，可见度量的重要性。基于闭环工作流引擎产生的完整数据，企业可从价值流动分布、价值流动效率、资源消耗三个维度，对软件价值交付、过程管理、研发成本进行度量，达到资源优化配置、研效持续治理、持续优化软件研发成本的目的。

高可用

一体化协同平台直接影响企业的 SLA 和产品交付效率，如果平台不稳定，则会对企业的市场造成非常恶劣的影响。比如，金融公司受股市周期影响，一般发版时间都会在周末，周一到周四为研发时间，周五下午休市后为集成时间。如果周五平台的持续集成模块出现故障，导致无法构建，将会直接影响周末两天的产品发布。最恶劣的情况是，线上有故障需要 hotfix，但是平台停止运转，这时靠手工几乎无法快速恢复生产。以持续部署为例，现在很多企业都是混合云部署，即一次发布可能要跨多个云厂商、可用区和集群，为了保障交付的可靠性，中间可能还要执行各种发布策略，这绝不是靠人工可以完成的动作。那么，如何保障平台的 SLA 呢？

首先，建议把 IaaS、PaaS 的稳定性交给云，专业的“人”做专业的事。

其次，控制软件复杂性，尤其是微服务的规模和中间件的技术选型。微服务的出现对平台型产品的演进速度有较大帮助，因为平台的功能模块多，微服务可以帮助模块独立演进和独立交付，但是一旦出现微服务规模爆炸，其本身对架构的挑战将会非常大，故障排查和发布物料组织都会非常慢。另外是中间件的选型，笔者曾经看到过一款 B 端软件的数据存储方案就有 MariaDB、MySQL、PGSQL、MongoDB、Redis5 种，这些中间件的功能存在大量的重复建设，且最终运行的稳定性缺乏兜底策略，直接影响平台的稳定性。

最后，建立完整的可观测性和灾备。没有故障的平台是不存在的，出现故障快速恢复才是王道，因此建议除考虑平台功能外，也需要考虑监控、日志、告警、调用链追踪等可观测工具的建设，优化故障排查效率，早发现，早恢复。如果实在不能恢复，则建议为平台建设灾备能力，如跨云、跨区准备灾备实例，一旦出现问题可以快速切换灾备系统，恢复生产。

实现方式

一体化协同平台的功能全景如图 10.7.9 所示，提供从项目协同、开发、构建、测试、制品、部署的全流程协同及研发工具支撑。

图 10.7.9 一体化协同平台功能全景

目前，搭建一体化协同平台的主要方式有采购商业方案和自建平台。这里以腾讯云 CODING 的商业方案为例，从投入产出、回报周期、维护成本等多个维度与自建平台做差异对比，如图 10.7.10 所示。

两个方案的差异非常明显，相对于自建，商业方案的投入产出比更加清晰可控、回报周期更短、后期维护成本更低。企业在两个方案之间的选择本质上是研效治理预算，即在商业方案的“确定性”和自建方案的“不确定性”上进行选择。

图 10.7.10 商业方案VS自建方案

商业方案一般都会积累很多企业研效治理的经验，产品形态更加成熟，一般都会提供 SaaS 和私有化交付两种方式。企业可根据自身需求进行交付方式选择，如无数据隔离和行业合规强制要求，建议选择 SaaS，其交付周期更短，后续维护成本更低。另外，商业方案也可以对企业的特殊场景提供定制化服务。对于企业而言，标准需求通过标准功能匹配，非标准需求通过定制需求匹配，最终投入产出比“确定性”是比较高的，且交付周期更短，维护成本更低。对于 SaaS 形态的交付，企业几乎没有维护成本。

而自建方案受限于企业的研效认知和团队成熟度，企业需经历一个较长的心智爬坡和试错周期，才能找到正确的研效治理路径，资源投入和试错成本都比较高，投入产出比的“不确定性”也较高，短时间内无法预估一体化协同平台生产可用的时间。笔者曾经见过企业投入 100 多人的团队自研一体化平台，每年的投入在 1 亿元以上，而受疫情影响，核心业务收缩，平台建设叫停，期间高昂的投入没有产生任何收益。在头部公司都在讲“聚焦”的时代，如果把这些预算投入到核心业务上，则更能帮助企业提高市场的竞争力。

最后，如果企业的研效治理需求大部分可通过商业方案匹配，建议选择商业化方案，其投入产出比会更加“确定”；如果需求匹配度不高，且企业有充足的研效治理预算，对研效治理的失败有足够的包容预期，也可以尝试自建。

一体化协同平台发展方向

近两年，BizOps 和 FinOps 的出现代表一体化协同平台正在从关注软件研发内部的流程化、自动化、标准化，向打通业务和优化云成本方向发展。如果从经济学“生产”的定义来看，一体化协同正在从软件研发内部（生产过程），向整合市场需求及生产要素的方向发展。可以说，一体化协同平台的发展趋势正在回归“生产本质”，即生产创造价值。

BizOps

一体化协同平台通过打破“组织墙”和“工具墙”，使软件研发变得高效有序，但高效并不解决有效的问题，企业期望能将软件研发和组织战略、市场需求、用户反馈打通，使软件研发不仅高效而且有效。

2020 年，BizOps 宣言提出了业务驱动研发、研发价值数字化、数字化驱动业务增长的核心理念，打破了业务与软件研发之间的隔离，使软件研发过程中的业务价值流动变得清晰透明。企业可以通过洞察业务价值流动速率和业务价值流动分布，提高战略业务的资源投入，降低无效业务的资源投入，实现资源优化配置；通过研发价值的数字化，评估软件研发对业务价值的贡献，比如业务策划的“拉新”活动上线后，通过运营系统和一体化协同系统的打通，企业可根据新增用户的规模变化，直观评估软件研发对业务的贡献，软件研发人员的价值举证也将变得简单可信；通过业务和软件研发的全流程数字化，企业提高了业务全流程“生产数字”的能力，再配合大数据及人工智能技术，提高“消费数字”的能力，最终实现数字驱动业务增长和数字驱动软件研发效能升级的目的。

FinOps

今天，云计算的趋势已势不可挡。Gartner 的调研报告显示，2022 年年底，全球企业的云计算支出将约为 3300 亿美金，但受限于企业对云计算本身的认知及自身应用模型的特征，大量企业存在云计算预算超支和资源利用率严重不足的情况。

FinOps 打通软件研发、财务和业务，使企业的云计算成本分布变得清晰透明，并可借助软件线上运行历史数据，自动预测负载波峰和波谷，实现云计算资源的弹性扩缩容，将云计算使用方式从“按使用量付费”变为“按业务需求量付费”，优化企业云计算成本。

2021 年，腾讯云推出的云原生成本管理产品“成本大师”正是 FinOps 的典型代表。“成本大师”从成本洞察、成本优化、成本运营三个层面来协助企业做更好的成本管理，具有全链路的成本优化能力，能够精确、智能地进行成本洞察，一分钟发现资源浪费并提供 8 种弹性策略组合，满足任意场景的弹性需求。其核心能力 qGPU 是强隔离的 GPU 虚拟化技术，该技术在业内首次实现了 GPU 算力、显存和故障的强隔离，支持算力精细切分共享和多优先级混部，GPU 利用率最高可提升 230%。

作者：吴海黎

本文章节选自 QECon 出品《软件研发效能权威指南》一书，《一体化协同平台》章节。

好书推荐