DevData Talks | 金融大咖说：金融企业如何持续提升研发效能

在 5 月 24 日的 DevData Talks 直播活动中，我们在数字化转型的大背景下聚焦金融行业的研发效能，邀请到了微众银行研发效能负责人余伟老师、某银行组织级转型负责人余宇老师、国金证券企业研发效能负责人杜铁绳老师几位大咖，共同探讨金融企业在做研发效能提升过程中的实践过程，以及迈坑经验。

嘉宾简介

余伟：微众银行研发效能负责人。先后在腾讯、阿里负责研发质量相关工作，有十多年金融、互联网行业经验，专注于研发效能、质量管理领域，推动研发效能提升，《软件研发效能权威指南》联合作者。

余宇：某银行组织级转型负责人。EXIN DevOps Master、DEC、CSM，参与过信通院 bizDevOps 标准编制工作。目前负责全行敏捷 &DevOps 实施指导，统一研发效能工具平台建设，全行信息科技标准规范编写。

杜铁绳：国金证券企业研发效能负责人，研发管理部负责人, 国家互联网数据中心产业技术创新战略联盟专家委员会专家。先后曾任外企高级项目经理、敏捷 &DevOps 业务线负责人。负责 AI 技术应用，项目（群/集）管理、敏捷能力、DevOps 能力、开源治理以及与之相关的工具平台建设。

以下内容根据交流分享内容整理：

🎙️微众银行余伟

我首先来介绍一下微众银行在微众银行方面的研发效能。这个工作已经进行了相当长的时间，从微众银行在 2014 年开始投入科技能力建设和启动，到现在最初关注研发质量和需求交付，再到 2019 年正式提出研发效能这个概念，并专门进行了一些提升。

在这样的历史背景下，我们的研发效能不能说做得很好，但我们积累了一些宝贵的经验，也踩过一些坑。希望能够与大家进行良好的交流，互相学习。在我们理解研发效能这个领域时，实际上更多关注两个方面，一个是研发质量，另一个是研发效率。那么金融行业的研发指标该如何理解？实际上，我们回过头来看，金融行业具备一定的特点。可能我之前在互联网企业工作过，现在在微众银行工作，所以我对这两个行业做了一个简单的对比，可以看出金融行业目前的三个特点。

第一个特点是科技部门相对独立。在互联网行业中，产品经理是提出需求的人，也可能是客户，他们可能会提供一些需求或改进点，然后根据这些需求进行开发、测试，最终实现并上线运营，以满足用户需求。然后我们再根据用户的反馈进行改进，这是互联网行业的正常流程。而对于金融行业来说，实际上更多是由业务部门提出需求。业务部门可能有多个，包括个人业务和企业业务，涉及存款业务和贷款业务等。当他们有需求时，他们会找到科技部门，确定将该业务交由哪个科技团队来实现。各个团队可能有一定的分工，所以基于这个分工，会将需求交给 IT 部门来实现。IT 部门将业务交付给客户，他们可能作为客户接洽人、前线调研员或直接接收客户反馈的人，然后将反馈传达给科技部门。

第二个特点是进行科技输出。可以看到许多金融行业不仅面向自身内部业务，还将业务作为科技能力对外输出。例如，像微众银行这样的机构提供了一些刷脸服务，他们将这些服务提供给其他业务机构。当他们从事一些面向企业的业务时，可以利用刷脸技术来提供更好的刷脸体验。

第三个特点是金融行业的 IT 部门为整个机构提供服务，而非特定小团队。例如，如果我负责基础架构，那么我们会有一个专门的团队负责基础架构，并为整个机构提供基础架构相关的服务和规划。因此，金融行业的 IT 部门具备一定的特点。在这样的特点下，我们可以看到研发效能的建设。那么，如何进行建设呢？实际上，相对于互联网行业，金融行业对我们提出了更高的要求。我们不仅要满足内部业务部门的质量要求和业务交付需求，还要满足科技输出的要求。当我们的科技输出不满足对方的要求时，可能会给整个团队甚至整个银行带来一些损失。因此，质量和效率是我们自始至终要关注的点。

接下来给大家分享一个案例。大家都知道我们需要建立一个闭环：通过一些手段和数据发现问题，然后对问题进行量化，形成一些指标来驱动团队进行改进，改进完成后，再通过监控手段来确认问题是否完全解决。这是一个相对简单的闭环，但在实施闭环的过程中会遇到一个问题。我今天要讲的案例是在整个研发过程中，除了新产生的问题外，还有很多历史问题存在。当你加入一个团队时，这个团队可能已经积累了几年的历史问题，由于各种原因，业务正在发展，突然出现一个契机需要清理历史债务。今天我要分享的案例就是是如何处理微众银行的研发历史债务。

在整个研发过程中，大家都使用了一些静态代码扫描的方法。这是比较常见的做法，我们之前也在使用。但是，目前市面上比较知名的扫描规则有很多，甚至我们自己定义了一些规则。每个团队使用的规则都不太相同，根据这些规则进行代码提交的质量要求也不同，因此随着时间的推移，就会积累一些问题。

此外，除了静态代码扫描，我们还进行了代码安全扫描和组件安全扫描。这引发了许多问题，我们如何在迭代中推动改进呢？首先，我们需要寻找触发点，即为了清理彼此债务而产生的契机。这个契机可以来自行业的要求，我们需要遵守这些要求并采取一些惩罚措施。另一个契机是内部在发现薄弱环节时，主动要求我们推动改进。另外还有一种契机比较特殊，即可能是由于某个特殊的组件或原因引起的特殊事件驱动，需要我们进行全面的审视和检测，然后提供改进方案。

遇到这类问题，我们直接告诉大家我们现在有多少历史债务。比如我们收到了多少个扫描问题，然后业务团队需要评估这些问题，考虑如何改进，以及需要多久完成改进。基于现有规则，这对业务团队来说很麻烦，因为他们已经承受着很大的业务压力，需要他们去改进很难实现，所以进展很难推动下去，陷入了僵局。

作为研发效能团队，我们该如何处理这个问题？我们当时采取了一个很好的方法，就是组织了一批专家，他们是代码方面的专家，请他们评估历史债务的严重程度和影响范围，以及我们团队中存在的问题比例。然后给出如下修改建议：

首先，对于比例较高、难度较低或没有风险的问题，建议大家优先修改，然后通过自动化手段或简单的自测后，将其推向市场。而对于比较困难和特殊的问题，我们组织了一群攻坚力量，共同扫描并给出合理的修改建议，以便大家能够方便地进行修改。最后，我们将新发现的问题和历史问题分开处理，每发现一个新问题，就解决一个，不允许将带有新问题的代码上线。至于历史问题，我们通过刚才的手段解决掉它们。通过这种修改历史债务的事件反馈，我们回头反思这个过程，这是一个很好的推动方式，整个团队在研发质量方面得到了很好的提升。

第二个建议是采用一些推动改进的方法。我们首先要彻底了解问题，调研出最佳解决办法，并告诉大家这种改进是没有风险的，甚至可以用其他方式进行改进，在改进后进行验证。同时，要定期告诉大家修改进度，并采取一些适当的激励手段，对于改进较快、质量较高的人进行奖励，让大家知道在研发效能团队中，只要把自己的工作做好，就能获得相应的认可。最后，我们要评估风险，以及改进后可为长期发展带来的价值，让团队明确改进可带来的收益。这样，我们就形成了一种有效的处理历史债务的方法论。我认为这个方法论可以在很多团队中得到应用。这是一个微众银行研发效能团队中做得比较好的案例。

微众银行的研发效能团队或者说研发效能团队在整个发展过程中也经历了很多挑战和变化，但只要我们坚持初衷，确保产品质量，确保研发团队保持较高水平的质量，满足业务交付的要求，我认为这就是研发效能团队在保驾护航整个研发团队方面的责任。

🎙️国金证券杜铁绳

首先，允许我简要介绍一下目前我们的情况。我们曾经在组织方面遇到了一些挑战。在起始阶段，我们的组织结构不够统一，各个研发中心和信息技术部门之间的组织结构有些混乱。

另外一个问题是由于组织结构的混乱，各个部门都有自己独立的流程和平台，各部门对研发管理和研发效果的理解存在较大差异。在公司整体推行研发流程时，尤其是组织层面的推行过程中，这些问题就显得尤为突出。公司总部的规划也难以落地和实施。

那么我们是如何解决这个问题的呢？

首先，我们从组织结构上对整个 IT 部门进行了整合，包括研发、测试和产品相关的条线，按照组织结构的关系进行了调整。接着，我们涉及到过程和组织结构的建设，引入了敏捷流程和测试方面的整体能力，以及其他相关能力。

在此基础上，我们考虑统一研发效能和相关工作。通过整个组织的统一，我们建立了流程体系，包括开发过程的规范标准、发布流程的标准以及上线运营后的持续调整，从而实现了流程的衔接。

后来我们意识到，DevOps 并不仅仅是一套工具平台，它涉及到许多方面。其中最显著的是我们的组织结构调整，使得研发、运维等方面实现了一体化，甚至包括了产品研发、测试和运维的一体化。组织结构调整完成后，我们关注的是整个平台的基础支持。我们现在正在公司层面上监测和构建一套与 DevOps 相关的平台体系。需要注意的是，这个平台体系并非从零开始建设。之前每个部门都有自己独立的管理体系和工具，如代码管理、制品管理、代码规范和代码扫描等，只是各个部门分开建设，可能存在重复建设或者同一功能采用不同的工具实现。因此，在整体构建过程中，我们首先统一了基础工具和技术工具，然后考虑从规划到持续构建再到持续发布的顶层，通过统一的 DevOps 平台来统一下面所有工具。

🎙️某银行组织转型负责人余宇

刚刚杜老师提到的这些时事相关的工作我们也在做，同时我们也致力于做一些敏捷文化的传播。

谈到研发效能这个话题，我相信大家都不陌生。在今年的整个环境下，成本削减和效率提升已经成为我们无法回避的主题。而今天我们主要来讨论效率提升。效率提升关注的是如何在现有资源不变的情况下，通过改善研发过程、模式和工具等方面，实现更高的产出。研发效能是一个庞大的概念，正如余伟老师和杜老师刚才所讲，它涵盖了从业务构想到产品交付给用户的全流程，我们可以在后续的讨论中逐步完善这个概念。

目前，我们特别关注研发效能建设中的一个重点，即度量。我认为度量是大多数公司在研发领域都不可避免地涉及的领域。度量也是研发效能观测和运营领域的一部分，通过观察应用运行的各项指标来衡量我们的交付能力或状态。研发领域的度量同样是通过各项指标来观测，只是观测的对象是研发交付过程的能力和状态。因此，一个良好的度量系统或体系能够真实客观地反映出研发效能存在的问题，并指导我们进行改进。然而，一个不好的度量体系同样具有一定的危害性。在这里，我可以举一个我们曾经踩过的坑作为反面案例。

在我们实施 DevOps 平台或工具时，无法绕开持续集成和持续交付的流水线。在观测持续交付能力时，有一个非常经典的指标叫做红灯修复时长，我相信大家都比较清楚。这是一个很好的指标，可以反映出研发团队对流水线状态的关注程度。较短的红灯修复时长意味着团队能够更快地解决集成或部署过程中的错误，从而避免缺陷或漏洞的积累，以及对后续研发集成和部署活动的阻碍。

因此，在进行内部改进和度量改进时，我们会观测各个项目组的红灯修复时长。然而，为了在这个指标上取得好看的数据，有些项目组会逐渐将重点从如何快速反馈和修复流水线，转变为遇到问题时取消流水线或流水线未完成时返回失败状态。这是因为我们最初设计和采集这个数据时认为取消流水线可能是由非集成错误引起的，因此没有将其纳入统计范畴。

后来甚至有些团队在周期性观测这些指标和数据之前直接删除了失败较多的流水线，以便在统计红灯修复时长时不考虑这些流水线。这种现象并不能说明红灯修复时长这个指标本身有问题，而是我们以片面的方式采集和解释这些数据，导致了这个指标在研发效能领域成为一个反面案例。因此，我们对这个指标的采集和观测方式进行了调整，重新引导团队正确理解我们进行度量改进的意义。

我希望这个例子能够给大家在后续讨论中带来一些启发，并鼓励大家进行更多的分享。这个反面案例给大家带来了一些教训。这就是我要分享的内容，谢谢大家！