Q1：近年来众多软件企业纷纷投身“效能革命”，降本增效的呼声越来越大，背后的原因是什么？

变化与成本+方法论进步，点燃研发效能。

“狂飙”踩下刹车，“湖水岩石效应”加速显现。

Q2：当我们谈研发高效能或者精英研发效能时，到底在谈论什么？

既要做正确的事，也要正确地做事。

研发效能是企业在不确定事件里应对外部变化的响应力。

Q3：效能不高的原因有哪些？想要实现高效能离不开哪些核心动作或要素？

过程规范 + 流程清晰 + 工具支撑。

上线不再如上刑，享受优雅上线。

研发就像马拉松，良好节奏 > 短时冲刺。

高效能研发离不开“研发效能黄金三角”。

Q4：在实际落地中，Code Review 效果如何？如何才能真正做好 Code Review ？

找“技术洁癖”的人帮助 Code Review。

Code Review 很耗人工，但不能不做。

建立规范并以工具倒逼，做最“Real”的 Code Review。

Q5：研发效能管理实践过程中可能遇到哪些坑？请分享一些避坑经验。

既要抬头看天，也要低头赶路。

从无到有、从有到优。

粗暴的效能度量，只度量了苦劳，而非功劳。

Q6：AIGC 浪潮翻涌，相信能够给各行各业带来颠覆，在研发效能上也一定大有可为，对此有什么样的期待？

未来我们只需关注软件开发流程的“一头一尾”。

未来所有人都是超级个体，并有自己的数字分身。

“研发效能”真的火了。为帮助企业一起找到最适合的研发效能提升之路，近日， InfoQ 联合极狐GitLab 邀请到来自腾讯、卡斯柯、众安的研发效能专家和实践者，从 6 大问题出发，共同拆解“研发总是追不上业务需求，除了买工具，还能做什么”之问。以下是本次圆桌的精华回顾，Enjoy～

Q1：近年来众多软件企业纷纷投身“效能革命”，降本增效的呼声越来越大，背后的原因是什么？

变化与成本+方法论进步，点燃研发效能。

张扬极狐 GitLab 解决方案团队负责人

我第一次接触“效能”一词，是在 DORA（DevOps Research and Assessment，一个致力于 DevOps 调研与研究的组织）发布的 DevOps 报告中。自 2014 年起，DORA 每年发布一份行业报告，分析高效能团队与低效能团队在 DevOps 实践上的差异。

当时，我和张乐老师一起参与翻译 DevOps 报告，其中提到了“Software Delivery Optimization Performance”，我们非常纠结“Performance”应该翻译成什么？经过长久的探讨，我们发现在业务场景中，它是“绩效”，在软件交付的改进与优化的场景中，把它译为“效能”更为妥当。

为什么“研发效能”今天这么火？我认为有两个原因：

第一，市场变化和成本。数字化进程中，传统企业要做数字化转型，数字原生企业要做数字化提升，而外部环境变化非常快，要求企业迅速响应市场的变化；另外，软件投入非常高，如何衡量 ROI ，如何降本增效，是研发效能需要解答的命题。

第二，研发方法论和实践的进步。随着瀑布模型 → 敏捷开发 → DevOps 理念的普及和发展，软件研发管理和工程领域已取得显著效果。此时我们想进一步了解自身实践处于什么水平，如何支撑业务发展等问题，这也需要研发效能来尝试解答。

“狂飙”踩下刹车，“湖水岩石效应”加速显现。

张乐腾讯研发效能资深技术专家

研发效能被越来越多人认知和认同，与大时代背景相契合。

过去一二十年是互联网、软件行业“狂飙”的黄金时期，数字化红利推动了一波波增长。为了更早或更多地占领市场，很多企业通过大量堆砌人力、资源和时间，俗称“快糙猛”的开发方式，让业务先跑赢，而后置了发展模式是否健康、科学、可持续等问题。

现阶段经济下行，企业经营压力大，这种不健康的发展方式注定无法长久。

这个过程叫“湖水岩石效应”————当一个湖中有很多水，水面很高时，湖中的石块都被水所覆盖，此时即使有很大的暗礁，人们也看不到。但是当水量减少，水面降低时，一些暗礁就暴露出来了。

如同现如今企业经常碰到这样的现象：相比前几年，人员数量已经翻倍，但因系统架构越来越复杂，微服务数量越来越多，导致交付的业务量和需求量并没有同比增加，甚至下降。这在一定程度上说明，在过去一段时间里，快速增长掩盖了一些真实问题，即研发效能并没有上升，可能持平甚至下降。

所以我们今天提效能革命或降本增效，其实是强调在新时代下，研发如何从“快糙猛”转变为更高效、更持续的方式。

Q2：当我们谈研发高效能或者精英研发效能时，到底在谈论什么？

既要做正确的事，也要正确地做事。

张乐腾讯研发效能资深技术专家

2021 年，我和一些专家、实践者，提出和发布了“研发效能宣言”，既是对敏捷宣言的致敬，也是对我们的信念和价值观的呼吁和声明，代表了我们的立场，以及我们认为对研发效能而言什么才是最重要的。

图片来源：书籍《软件研发效能提升实践》

我当时画了一张图，上面是业务目标，下面有两个要素，左边是“理想的功能和质量”，右边是“理想的工作量”，即我们希望用什么的代价实现什么的功能和质量。但我们会发现理想和现实之间经常存在差距，要么是效率上的差距，要么是有效性上的差距。

所以，研发效能 ≠ 研发效率，我们既要关注效率，也要关注有效性，或者说既要关注做正确的事情，也要关注正确的做事情，并追求效率。

如果用这个一句话来表述研发效能，我认为这句话就是：研发效能就是更高效（即效率）、更高质量、更可靠、可持续地交付更优的业务价值（即有效性）的能力。对于大型企业而言，还要关注规模化问题，考虑如何管理复杂性。

💡欢迎点击此处获取 5 本《中国企业研发高效能白皮书》（ CI/CD、ChatOps、企业级软件架构、Code Review、从价值流管理到研发效能管理）完整版合集，开启高效能研发之旅。

研发效能是企业在不确定事件里应对外部变化的响应力。

张扬极狐 GitLab 解决方案团队负责人

首先，原生的研发效能一定是软件的研发效能，不是硬件或者是其他业务的研发效能。

其次，我个人定义研发效能，是数字化企业在不确定事件里应对外部变化的响应力。质量有多高，成本有多低，时间有多好，工具有多强，将这些因素串联起来，形成一个高速流转的业务交互价值流的能力，就是研发效能流转。

Q3：效能不高的原因有哪些？想要实现高效能离不开哪些核心动作或要素？

过程规范 + 流程清晰 + 工具支撑。

朱锁明卡斯柯信号数据化转型部门负责人

以卡斯柯的研发需求架构为例。当我们在讨论需求收集 → 分析 → 规划 → 决策 4 个环节时，发现可以提升空间很大。例如有时候客户需求来了，研发团队就优先处理客户需求，可能就影响了原来的研发版本火车。

那么这个需求如何决策呢？我认为要把研发过程规范化、流程清晰化，以及工具和系统起到有效支撑非常重要，并且减少中间环节的开销，整体才能更加清晰高效。

上线不再如上刑，享受优雅上线。

张扬极狐 GitLab 解决方案团队负责人

成功都是相似的，失败则五花八门，研发效能也是一样。我分享一个比较普遍的问题：重管理、轻工程。

现如今我们管理手段、流程、方法、工具特别多，但在工程层面，比如单元测试、代码评审、持续集成等做的并不够，导致技术债务越来越多，祖传代码如同“屎山”，无法执行功能演进。

我们需要把工程实践要提高到和管理相匹配的程度。以 GitLab/极狐GitLab 为例：诞生 12 年，上千名研发人员共同开发。如今，GitLab/极狐GitLab 后端单元测试覆盖率仍能够达到 90% 以上，前端达到 80%，每月如期发版上线。而且，我们的研发团队不存在“上线如上刑”的情况，取而代之的是优雅上线。

因此，我呼吁大家要把工程能力提升起来，而不仅仅是管理。

💡欢迎点击此处获取 5 本《中国企业研发高效能白皮书》（ CI/CD、ChatOps、企业级软件架构、Code Review、从价值流管理到研发效能管理）完整版合集，开启高效能研发之旅。

研发就像马拉松，良好节奏 > 短时冲刺。

高文涛众安 ZA Tech CTO

研发就像一场马拉松，不在于短时间内能冲多快，而要确保在漫长的研发过程中有很好的节奏，确保团队各个角色在不同的研发流程、不同环节都清晰知道应该做什么。

如果失去节奏，就需要花大量时间处理各种突发情况，而无法把精力放在真正产生价值的事情上。因此，让团队形成良好的节奏，像一台充分润滑过的机器，才能迈向高效能研发。

高效能研发离不开“研发效能黄金三角”。

张乐腾讯研发效能资深技术专家

我认为效能不高是因为没有做好“研发效能黄金三角”，即效能实践、效能平台、效能度量。

效能实践上，忽视了软件工程最根本的方法，包括管理维度如需求分析等，工程维度如单元测试、Code Review、代码分支模型等。我认为这些基本功非常重要，而且是效能提升的关键点；
效能平台上，没有用好工具。没有工具，很多事做不了；工具没有有效结合场景，行之无效；
效能度量上，缺乏用数据驱动持续改进。正确区分过程指标、结果指标；让指标发挥真正的价值，而不是变成内卷的工具；基于客观数据，进行场景指标洞察和效能分析。

Q4：在实际落地中，Code Review 效果如何？如何才能真正做好 Code Review ？

找“技术洁癖”的人帮助 Code Review。

高文涛众安 ZA Tech CTO

众安在重度实践的 Code Review，所有代码提交都需要经过 Tech lead 和 Peer 审核。在我看来这么做有两大好处：

真正实践质量内建和质量左移。越是研发早期发现问题，越容易解决，成本越低；
团队知识分享。大规模团队精细化分工，每个人只专注在细分领域，借助 Code Review 能够让团队或跨团队之间熟悉彼此在做什么；Code Review 也创造了集他人之所长的学习机会，吸收多方意见，帮助团队成长。

我分享几个好的实践：

整个研发团队采用相同代码规范，让评审人高效发现问题，提升 Code Review 效率；
提交之前先自查，确保内容完整、单元测试已通过等；
小批量提交；
最找有“技术洁癖”的人帮助评审，获得中肯意见。

Code Review 很耗人工，但不能不做。

朱锁明卡斯柯信号数据化转型部门负责人

Code Review 的重要性不容忽视，早期修复问题的成本和上线发布后的修复成本天壤之别。

我们团队也踩过坑，比如最初推行 Code Review 时，总想让个别经验丰富的技术大拿亲自评审。但让几个人去看全团队的代码，成本太高也不现实；另外是我们开发人员有一个共同特点：代码写得特别快，然而写文档、写注释、写规则，对他们而言就是一件痛苦的事情。

这几年我们做了一些调整，团队反馈很好，和大家分享：

通过工具倒逼 Code Review 落地，并与企业微信相集成，将评审消息推送到项目经理或技术负责人手上，及时处理；代码规范性检查交给工具自动化完成；
构建学习型研发团队，通过协作、分享，达到全员知识增长的目的，这样的团队战斗力是最强的。

💡欢迎点击此处获取 5 本《中国企业研发高效能白皮书》（ CI/CD、ChatOps、企业级软件架构、Code Review、从价值流管理到研发效能管理）完整版合集，开启高效能研发之旅。

建立规范并以工具倒逼，做最“Real”的 Code Review。

张扬极狐 GitLab 解决方案团队负责人

我幸运地经历过 Code Review 各种主流方式，如

线下形式：下班前半个小时，团队成员把今天写的代码讲一遍，大家一起评审；
结对编程：我和我的 Peer 在一个计算机上共同工作，一人输入代码，另一人审查对方输入的每一行代码；
基于工具的线上异步代码评审：这是极狐GitLab 提供的能力和自身正在实行的。

Code Review 能够实现质量内建和知识共享，这是大家的共识。我看到很多企业在推行 Code Review 时的主要问题是流于形式，例开发者如自提自合，既是裁判，也是运动员。

很多时候我们一边苦于招不到牛人，一边又惆怅于团队效能无法提升。我建议加强 Code Review，坚持实践，现有开发团队本身就会更加优秀：

建立规范：无论是基于编程语言规范，还是基于团队或企业的实践标准，建立了规范，大家才知道怎么做。
规范规则落到工具上：如果只是落在纸面上，就需要很高的管理成本，以工具倒逼 Code Review 落地是更加高效能的做法。在极狐GitLab 上推荐这些方式：

代码责任田机制：自定义规则，如 Code Owner 必须 Code Review 所负责的代码；
代码评审人推荐：极狐GitLab 支持通过 Review 代码量、时长、Bug 拦截率等客观数据表现，结合模块特点、开发者本身任务等维度，选择最优评审人，用数据驱动“专家经验”的积累与共享，让 Code Review 更到位；
和 CI 工具集成：研发人员每一次提交代码都会触发 CI，CI 基于单元测试、安全工具等扫描代码，并出具结果报告，帮助研发人员提高评审效率，把好第一道关；
合并请求：我认为最卓越的追求是当每一次合并请求添加到新的分支上之后，编译出来的就是一个 Production Ready 的软件。所以这个过程不仅是 Code Review ，不仅是开发人员参与，测试、运维可能都参与其中。

Q5：研发效能管理实践过程中可能遇到哪些坑？请分享一些避坑经验。

既要抬头看天，也要低头赶路。

张乐腾讯研发效能资深技术专家

坑挺多😄，挑几个比较有意思的和大家分享：

1. 规范与灵活度的失衡

每个团队面临的问题不一样，要解决的这种瓶颈不一样。如果事无巨细和过于追求用一套规范去“框住”所有人，反而适得其反。

因此，既要有规范，有粗线条的规范、大纲、结果导向的指标；也要有灵活度，给一线研发必要的自由。

2. 忽视一线工程师的声音

推行一个管理规范，首先需要老板买单，但如果不听一线工程师的声音，过分强调管控，而不去深入一线解决具体问题，可能变成“两张皮”。

3. 关注局部优化，忽视全局优化

工程师很容易在某个具体细节做局部优化，比如将编译构建速度从 3 分钟提升到 2 分钟，将部署成功率从 95% 提升到 98%等，尽管这些事情非常重要，但它仍是一种局部优化。也许一个需求在某个阶段停留了三五天，而 3 分钟到 2 分钟的局部优化在结果贡献上微乎其微。

因此，我们首先要看全局优化，而不是局部优化，从整体看问题，而不是只着眼局部。

从无到有、从有到优。

朱锁明卡斯柯信号数据化转型部门负责人

我从数字化转型角度来分享：

一是研发效能管理实践本身是偏向管理，不能过于追求繁琐的流程，流程太复杂就转不起来。

二是从无到有、从有到优，先解决痛点问题，解决根本问题，发现提升当前效能最有效的方法，再逐步优化。

粗暴的效能度量，只度量了苦劳，而非功劳。

张扬极狐 GitLab 解决方案团队负责人

首先，我认为研发效能管理分为两个重要的部分：

研发效能度量；
研发效能改进或提升。

没有度量，只能凭经验做改进，可能发现不了核心根因和痛点。

我提炼两个研发效能度量的关键点：

1. 管理者意识

将软件研发与工业生产相比较：工业生产流水线通过公式可以得知 8 小时有多少产出；软件研发中，开发者一天 8 个小时，能够恒定的产出相应的价值吗？我认为不是，因为写代码有些时候是靠灵感。而管理者可能用一些容易获取的指标做度量，这种粗暴的度量方式，很多时候度量的只有苦劳，没有度量出功劳。

例如代码量指标，如果只用这个指标去衡量开发者贡献，其引导的方向就是错的。所以做效能度量时，要注重一线开发者的体验，做有效的度量，进行正确引导。

2. 数字游戏

我见过很多企业并不是拿不出指标，而是指标太多。这对管理者而言，解读和可视化数量繁多的指标，复杂度非常高；而基于这些指标工作的团队，也非常辛苦。

我建议响应张乐老师“研发效能宣言”中提到的“全局流动优于局部优化”，不要以一个指标去评价一件事情。定指标的时候，北极星指标可以用单一的指标，而且有时间线，比如本月想改进的是需求分析的前置时间；但是评价指标，比如评价团队产出、个人贡献、产品价值，建议使用组合指标，避免片面评价。

Q6：AIGC 浪潮翻涌，相信能够给各行各业带来颠覆，在研发效能上也一定大有可为，对此有什么样的期待？

未来我们只需关注软件开发流程的“一头一尾”。

张乐腾讯研发效能资深技术专家

现在，AIGC 已经有一部分是生产级的，可以应用于当前软件开发专业分工和流程基础之上，增强每一个环节的能力，即 X + AI。例如基于注释生成代码，基于代码生成注释信息，解读代码，被测代码生成测试代码；通过大模型做需求分析、竞品调研、完善格式化需求文档、辅助编写用户故事、生成验收条件等，已经相对落地，可以直接使用。

我们看到在一些局部领域里，X + AI 能获得 20～50% 甚至更高的效能提升。但如果想有颠覆性突破，例如是否能够把当前软件开发的模式或范式进行根本性重构？这种方式可能难以实现。

我畅想在未来，人可能更重视一头一尾：

一头：人成为一个需求的提出者和一个任务的分发者，中间过程由大模型重构掉设计、开发、验证性的工作；
一尾：人去做结果的判断。大模型的本质是基于概率，和我们追求确定性的结果之间，还要找到一个平衡点。

未来所有人都是超级个体，并有自己的数字分身。

张扬极狐 GitLab 解决方案团队负责人

今天 AIGC 能力在软件交互场景下，能够辅助我们更加高效和高质量地局部提升研发效能。

下一个阶段，我更倾向于研发效能是一个全局优化的过程，极狐GitLab 也在基于用户旅程即整个软件研发流程，内嵌 AIGC 能力，加速全流程，而不仅仅是编码。

现阶段主要是人机交互，未来实现机器和机器之间的交互，如张乐老师所说，人只需把控一头一尾；甚至未来所有人大概率是一个超级个体，甚至每个人都有自己的数字分身，遨游在 AIGC 的世界里。

💡 技术服务的边界不断拓展，技术服务体系在不断完善，高效研发的产品层出不穷，中国企业正在高效能研发的路径上快速前进。

为了解读市场中具有代表性的高效能研发解决方案，极狐 GitLab 联合 InfoQ 研究中心，以中国企业研发高效能为研究对象，发布了 5 本《中国企业研发高效能白皮书》（ CI/CD、ChatOps、企业级软件架构、Code Review、从价值流管理到研发效能管理），期待可以帮助中国企业研发团队获得高效能方法论、工具、最佳实践的新认知。