“研发效能”真的火了。为帮助企业一起找到最适合的研发效能提升之路，近日， 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、代码分支模型等。我认为这些基本功非常重要，而且是效能提升的关键点；
2. 效能平台上，没有用好工具。没有工具，很多事做不了；工具没有有效结合场景，行之无效； - 效能度量上，缺乏用数据驱动持续改进。正确区分过程指标、结果指标；让指标发挥真正的价值，而不是变成内卷的工具；基于客观数据，进行场景指标洞察和效能分析。
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、从价值流管理到研发效能管理），期待可以帮助中国企业研发团队获得高效能方法论、工具、最佳实践的新认知。