嘉宾 | 吴骏龙 Wish China QA Director
编辑 | 严强
为了提高业务产能，不少互联网企业都寄托于加人加班和拼工时的“996”工作制。不过，这样的做法在热烈的讨论和实践中已经被证明了不仅收效甚微，而且还会降低员工的积极性，甚至起到反向效果，让整个研发效能不升反降。因此，近年来不少大中小企业开始纷纷布局研发效能。
企业和团队刚开始接触研发效能的时候，或多或少都会产生这些疑问：研发效能具体指的是什么？研发效能的实践能够帮助企业解决哪些问题？曾经大力推行研发效能的企业如今怎么样了？研效问题到底解决了吗？研发效能是否会掉到“搞垮团队”的怪圈呢？
基于以上这些问题，我们邀请了研发效能专家吴骏龙老师，来分享一下他在研发效能领域的探索。
以下是对吴骏龙老师的专访：
InfoQ：你最近在做什么工作？
我目前在一家跨境电商公司负责国内测试团队的组建、运营和提效工作。这是一家中小型的互联网公司，国内主要负责跨境物流，业务有一定的复杂度，但是技术团队整体规模并不大，因此效能提升是比较重要的工作。我个人主要聚焦于质量提效，即如何又快又好地保证产品的交付质量，这也是我的职业生涯的一个长期追求。
不同规模的公司推动质量提效的难点是不一样的。对于大厂，难点往往在于如何打破组织壁垒，需要平衡各方的利益；而在中小型团队，难点更多在于基础设施的不完善，以及团队资源的问题，需要平衡质量和效率的关系。对于后者，我的团队目前正在通过数据驱动的方式，实现质量数据的可视化，挖掘效能低下的根因，并推动改进最“痛”的问题。通过半年多的努力，交付吞吐量提升了近 2 倍，线上漏测率从 10% 下降到了 3%，基本达到了预期。
InfoQ：你是怎么对研发效能产生兴趣，并走上这条职业道路的呢？
我是做测试开发工作出身的，最早在 eBay 中国，那时研发效能在国内还没有兴起，但是在国外已经不是新鲜事了。我所在的团队最初叫 QE Infrastructure Team，做自动化工具为主，这些工具平台的受众基本都是测试人员。后来我们开始做测试执行平台，它可以和持续集成流水线结合起来，便于提交代码后快速得到质量反馈，我们也可以通过在流水线中设置各式各样的质量门禁，方便开发人员管理质量，这样就和开发人员的工作联系起来了。之后，我们的工具又集成了发布平台，可以做制品传递和版本管理，这样又和运维人员的工作联系起来了。
这些工具的覆盖范围，基本上就是现在业界所公认的研发效能提升的切入点。你可以对照下面这张图看一看，这是来自阿里云效的一张截图。后来，我们团队被改名为 Productivity Team。类似 Productivity 的还有 Efficiency 这些单词，其实就是我们现在所说的效能的意思。在这方面，确实国外领先很多。
研发效能提升的切入点
有了明确的组织定位，有了完善的工具体系后，我们开始倒逼流程改进，平衡质量和效能的关系，比如：代码扫描没有 Blocker Issue 才能合并代码；Smoke Test 通过才能提测；Full Regression Test 通过才能发布，除非 Leader 特批；Canary 环境 Smoke Test 通过才能切正式流量，等等。到了这个时间点，我，包括我们整个团队，都已经不是以最初测试开发的角色去工作了，而是以效能驱动者的身份去赋能每个团队的日常工作。
之后的几份工作，我待过阿里本地生活（饿了么）这样的大厂，也在初创公司工作过。除了质量基础设施建设以外，我也负责容量保障，也带过业务测试团队，但是提效这个思维，是我始终贯穿在日常工作中的关注点。看着大家的工作效率提升，是一件既有幸福感又有成就感的事。
InfoQ：在你的研发效能提升的工作历程中，有遇到过什么刻骨铭心的困难吗？有哪些总结沉淀和启发？
困难是非常多的，我相信每个研发效能的从业人员都有一肚子的苦水。上面提到的利益冲突、基础设施不完善、团队认知不够，甚至是管理层认知不够，都不是一时半会能解决的事。
从我个人的经历来说，遇到的最大困难并不在于技术和管理，而是如何拉齐一个组织对研发效能目标的共识。我问一个简单的问题，你觉得研发效能提升应该得到什么样的结果？是你的工作更轻松了，还是你能干更多活了？对于管理层来说，是团队不需要加班了？还是产品交付更快了？如果在同一家公司的不同群体间有着大相径庭的答案，那么众人就很难形成合力，有的人想轻松，有的人想折腾，这件事自然就难了。
因此，当你准备建设工具和优化流程前，不妨先深度思考，我们在这家企业推动研发效能的目的究竟是什么，并和你的管理层保持沟通，达成共识，再去影响你的团队和客户，这是所有研发效能提升工作的根基。否则，你在工作中一定会遇到各种不理解和各种委屈。
InfoQ：关于研发效能的定义和说法有很多种，从你个人来看，你怎么理解研发效能呢？它有哪些关键的要点？
确实，研发效能的定义很多，而且有些定义非常学院派。比如“研发效能是指使用行为目的和手段方面的正确性与效果方面的有利性，在软件研发过程中的体现。”这样晦涩的定义，估计大多数人都看不懂。
我想分享一个我个人比较喜欢的研发效能定义，叫做“顺畅、高质量地持续交付有效价值的能力”，短短 10 几个字，但是信息量很大。我谈谈我的理解：
- 顺畅：表示价值的流动过程是没有阻碍的，这对应了流动效率，即制品不能在一个环节上阻塞太久。这是非常重要的一点，阻塞往往意味着某个环节出现了瓶颈，不及时干预的话会影响到下游的其它环节。
- 高质量：提升效率不是以牺牲质量为代价的，两者是既要也要的关系。
- 持续交付：高频且小批量地交付价值，以便项目的所有干系人能够及时获悉项目进度，识别风险并应对变化。通俗地说，就是“小步快跑”。
- 有效价值：聚焦于真正对目标用户有用的产品和功能。
相信你也看到了，上面谈到的这些点，最后形成的是一种能力，所以研发效能更多的也是一种长期的能力建设，而不是短期的结果。不是说现在我做的很好就可以，而是要可持续地发展下去。
InfoQ：企业或团队在度量研发效能的过程中有哪些注意点呢？
我们先要回答一个问题：软件研发效能究竟能不能度量？
这是一个很深刻的问题，而且历来就有争论。管理学大师 Peter Drucker 有一句耳熟能详的金句：“If you can't measure it, you can't manage it.”这是主张度量的；另一位软件开发教父 Martin Fowler 则认为软件的生产力是无法度量的（感兴趣可以阅读原文：Cannot measure productivity）。
（https://martinfowler.com/bliki/CannotMeasureProductivity.html）
我个人认为研发效能是可以度量的，但是度量是相对的，也就是说，我们不应将重点放在度量结果这个数字上，更不要把度量指标机械地设置为 KPI，而是应该将度量结果作为一种现象，给到我们一个下钻根因的入口。这是我特别推崇的一种经济型做法，尤其是在团队资源有限的情况下。
我可以举一个例子，我在目前团队中会使用测试任务前置时间（Test Lead Time，从测试人员接到测试任务，到实际开始测试的时间）作为流动效率的一个度量指标。我们希望大多数测试任务能够在一周内完成，所以根据测试时长，倒推出前置时间要做到小于 2 天。这个指标本身并不说明问题，它的意义在于，如果前置时间远远超过 2 天，我们需要去寻找根因（注意，此时还不能得到测试效率有问题这个结论，不要先入为主给出任何绝对性的结论）。
在寻找根因的过程中，我们还可能需要设置更多的指标来佐证我们的一些猜测。例如，猜测研发人员的提测质量太差，导致无法及时开始测试，此时就需要纳入提测工单打回率这一指标；猜测测试人员的人效不高，无法支撑那么多测试需求，此时就需要纳入测试吞吐量这一指标，等等。还可以结合一些访谈和案例的形式，进一步逼近根因。
所以你看，我们通过度量指标的下钻，逐渐帮助我们找到了局部效能低下的根因，于是我们就可以采取措施去改进了，改进的结果最终也会体现到度量指标上。我认为，这种将度量指标视为引路人，而不是裁判员的思路，才是更科学的做法。
度量是相对的，还体现在一个重要方面，那就是要避免横向比较。这也是在不少企业身上所发生的度量误区，喜欢搞排行榜，去看哪个部门落后了需要改进，这就是将本应相对的度量指标在不同的团队间绝对化了。再以上面提到的测试任务前置时间为例，在我所负责的中国团队，我们需要做到 2 天，但是在美国团队，需求迭代速度较慢，5 天也不影响最终项目的按期交付。如果我们机械地以 2 天作为标准去横向对比中美团队的效能，就是不合适的。选择适合团队当前现状的度量指标，聚焦于团队自身的效能提升，也就是“自己和自己比”，是更好的实践方法。
InfoQ：很多企业或团队看到别人研发效能提升的方案效果很好，但应用到本公司之后，不仅没有很好的提高他们的研发效能，甚至让团队的研发效能降低了，你认为这种情况的问题是出现在哪里呢？你有什么建议呢？
我觉得这恰恰就是研发效能的魅力所在，这个问题的本质在于，研发效能的提升是一项需要高度“与人打交道”的全局性工作，而人是研发工作中最大的变量，难以标准化、难以度量、难以控制，自然也很难有非常具体的普适的效能提升手段。
我们都知道，软件研发是人类的智力活动，然而，这个几乎毋庸置疑的论断却是许多人共同的思维盲点。我们总是不自觉地认为我们可以依靠计算机解决所有问题。这样的例子很多，管理者喜爱推销自动化测试，认为自动化测试能够替代测试人员的工作，继而降低人员的工作强度，提升效率。但如果我们只是盲目地去引入自动化测试技术，不考虑当前团队人员的技能水平和接受程度，那么结果很有可能是，在自动化测试上投入的人力成本比手工测试还高，不仅没提效，还降效了。
我并不否认自动化测试的价值，但在落地时要考虑团队的实际情况。研发效能提升也是同理，很多时候，我们都在讨论流程要标准化，讨论研效工具要具备普适性，但是这些流程和工具是不是适合我们这个组织，是否对用户友好呢？这方面的关注和思考还是太少了。
解铃还须系铃人，既然软件研发工作是人类的活动，那么在此之上的所有效能提升工作，都要顾及人的基本感受和合理需要。因此，对于研发效能建设，我的建议就是四个字：以人为本。转换到具体工作中，我们可以积极借鉴同行的优秀实践，但同时更应该去了解这些实践背后的上下文（目标团队规模和特点，目标人员技术水平和基础，公司文化和价值观，管理者的风格，等等），再结合自己所在团队的现状去分析是否适用，或要做出什么改变，只有摸透这些背后的逻辑，我们才能真正的将研发效能工具和流程有效落地。
InfoQ：你觉得在未来，进一步提升研发效能，行业有哪些发展趋势？
我认为研发效能的发展趋势主要有两个方向，一个是技术层面，尽可能为“人”多做一些事情，让“人”少做一点事情，比如低代码、AI 技术等；另一个是管理层面，将人与人之间的协作方式不断优化，尽可能没有阻塞、没有重复工作。你看，不论怎么发展，以人为本的实质还是没变。
我对技术层面的发展相对乐观。现在的年轻人很少见过使用纸条打孔的编程方式吧，它是在 1946 年第一台计算机 ENAC 身上应用的方式。过了不到 10 年，第一种高级编程语言 Fortran 就诞生了（是不是第一种有争议）。再看看如今的编程语言，小学生都可以轻松上手，这在以往是完全无法想象的。
回到研发效能领域，低代码甚至无代码的理念，也就是最近几年冒出的名词（虽然这个概念早就有了），现在都已经有了成熟的商业级产品。通过拖拖拽拽，一个不会写代码的人也能完成简单应用的搭建。未来是否能够拓展到更复杂的应用搭建上是个看点，我们保持关注。
在管理方面，以往我们看到的都是比较笼统的敏捷方法和精益管理等等，现在不少企业也开始尝试看板方法、需求实例化等更细分的实践，这是好事。对于研发效能这样正处于发展阶段的概念，怕的不是折腾，而是没人折腾。
InfoQ：最后，和对研发效能感兴趣的小伙伴和想要尝试提升研发效能的管理者们说些什么吧！
坦白讲，在研发效能领域，国内企业总体还是落后的。我们经历过很长一段时间靠烧钱、人海战术换取更高的市场占有率，从而达到赢者通吃的岁月，研发效能可以用人、用钱填上。现在发现政策不一样了，人也没那么好招了，再开始节流就比较被动。我个人的感受是，很多公司还处于被迫去推动研发效能提升的阶段，不是真正为了提效，而是为了省钱。
微软现任 CEO 萨提亚·纳德拉说过这样一段话：“There cannot be a more important thing for an engineer, for a product team, than to work on the systems that drive our productivity. So I would, any day of the week, trade off features for our own productivity.”翻译过来就是“对工程师和产品团队来说，没有比构建一个能够提升研发效能的体系更重要的事了。为了提升研发效能，我愿意随时舍弃某些功能的交付。”
时代不同了，“大鱼吃小鱼”已经逐渐成为了历史，“快鱼吃慢鱼”才是如今时代的主旋律。我们的管理者应该将研发效能的提升视为关系到公司命运的战略级目标，这是保持企业竞争力的关键钥匙。
对于从事研发效能工作的个人，我也给到三个建议（关键词）：耐心、好学和开放。研发效能提升是不容易的，不要急功近利地试图一刀切解决所有问题。如果你遇到一家重视研发效能的公司，踏踏实实的多干几年，耐心沉淀出属于自己的方法论，这是你的价值，也是行业的价值。此外，研发效能作为一个热门领域，知识量是非常大的（当然，也会出现很多偏见），希望你能够保持学习，尤其是向同行学习，多多思考。最后，我想引用爱因斯坦的一句名言：“要解决我们面对的重要问题，不能停留在当初制造它们的思维层面上。”我们应该抱有开放的心态，尝试突破自我，用创新思维推动研发效能提升。
众人拾柴火焰高，希望我们能够一起努力，为研发效能的发展和革新添砖加瓦。
嘉宾简介
吴骏龙 Wish China QA Director 前阿里巴巴本地生活高级测试经理，毕业于中国科学技术大学，硕士学位。在软件质量体系、服务容量保障、服务稳定性建设、软件研发效能等领域深耕多年，善于通过创新手段解决质量和效能难题，拥有多项国内外专利。多次受邀于业界各技术大会发表演讲，传播先进理念和方法论。极客时间《容量保障核心技术与实战》专栏作者，畅销书《软件研发效能提升之美》作者。
