5月20日，贝壳找房研发效能专家乔晓琳在由中国信通院和 QECon 组委会联合举办的技术沙龙活动中分享了贝壳研发效能实践经验。

• 产业背景：研发效能的新形势与新挑战

• 历史演进：贝壳找房研发效能之路

• 效能基建：业务研端到端协同平台 & DevOps 工具链平台建设

• 效能实践：深入业务多场景多角色效能实践

• 效能沉淀：将方法论和实践经验沉淀到研发效能洞察平台

• 效能展望：“度量——平台——实践”正向飞轮

以下根据乔晓琳老师分享内容整理：

1. 产业背景：研发效能的新形势与新挑战

作为互联网房产行业的一员，贝壳同时面临着互联网和房地产行业背景的变化所带来的挑战。首先是降低成本、提高效率的问题。其次，我们的业务已经进入了一个从扩张期向平稳期过渡的阶段。在这个研发和业务阶段中，我们需要更加专注地发现和改进问题，精耕细作。

另外，贝壳本身倡导合作共赢和协同提效的理念，这也是我们的背景之一。在工程师文化方面，我们也正在经历从追求时间长度到追求时间效率的变化，这是一种价值观上的转变。这三个挑战和形势的变化，意味着我们的研发效能实践正从初级阶段迈向更为复杂的深水区。这并不是说之前没有进行过研发效能的实践，而是我们对自身提出了更高的要求。

在我们开始解决这些问题之前，我们需要回答哪些关键问题。首先是关于研发效能的本质是什么，我们需要对其进行明确定义吗？这个问题可能有些人会认为并不需要提出，因为无论是公司的高管还是一线的研发管理人员，可能都已经设定了一些与研发效能相关的目标，例如 OKR 或提高效率的目标。

然而，接下来可能会有更多问题浮现出来。特别是当我们深入到各个业务领域时，人们会问研发效能是否可以被度量。相较于生产标准化产品的流水线上加工过程，研发效能可能不是一个简单的累加产出。所以，我们需要思考这个东西是否可以被科学地衡量。如果可以的话，我们又该如何度量所提供的研发效能指标，以免陷入纯粹的数字游戏。在面对这样的背景变化和挑战时，我们遇到了这些问题，接下来我将在我们的实践中与大家分享，我们是如何解决并回应这些问题的。

2. 历史演进：贝壳找房研发效能之路

从2017年开始，当我们的业务真正进入研发阶段后，首先我们在一些关键领域进行了自动化框架的引入和单点能力的建设。这些包括发布能力和测试能力等，在当时是迫切需要进行自动化和提效的领域，因此我们进行了一些专项的建设。

大约两年后，我们整个研发流程有一个需求，即建立一个一站式平台。在这个一站式平台上，我们将整个需求流程线上化。这个需求流程涵盖了项目管理、迭代管理以及需求和缺陷管理等方面。这就涉及到流水线的建设和BI能力的引入。从2021年开始，我们通过项目制的推动，规范了流水线，从工程能力和工程卓越的角度出发，通过代码工程的实践，落地了持续交付和效能健康度的建设。在这个过程中，我们也开始探索一些规范和科学度量的方法。

进入2022年，我们进入了效能深耕的阶段。效能深耕涉及两个方面。首先是需求通路。对于贝壳找房的产研背景来说，我们面临着业务研发链非常长的特殊业务特征。换句话说，我们的真正用户可能涉及多个城市的多个网点，人数可能达到几十万甚至更多，但他们的一些需求通常不被充分考虑，透明度较低，也不被充分感知。

我们可以理解为，贝壳找房在2017年和2019年已经相对快速地实现了效能的落地，但在之前的更长一段时间里，效能可能相对较低。我们在这方面实现了业产研的端到端衔接。最终，进入到2023年，基于之前的需求、价值交付、DevOps工程卓越的建设，以及业产研全流程的衔接，我们的效能终于在业务中实际落地。因此，我今天的分享主要是对之前的基础和背景进行简要介绍，并重点介绍了从2022年下半年到2023年的实践落地情况。

这是整个贝壳一站式业产研效能平台的基础架构。我们可以对应到之前提到的时间段，2017年主要是在底层进行了一些专项能力的建设，包括与研发紧密相关的代码管理、单元测试提效等等，还有各种UI自动化测试和发布能力的建设。在这个基础上，我们扩展到与研发的日常工作更相关的活动，如会议评审和值班等，以及其他研发相关的专项治理。然后就是规范和流程的建设。我们都知道，如果没有规范，流程就无法实施和落地；反之，如果没有流程，规范也无法发挥作用。

因此，在2019年到2020年期间，我们在项目管理、需求管理、编码规范和发布规范等方面实施了一套规范，其中包含了18个环节和60多个操作步骤。在这个基础上，我们建立了一个效能度量体系。这其中包括哪些内容呢？我们可以从多个角度进行建模，例如从项目角度来看，我们可以通过项目立项制度来统一大家对项目管理的认知。从资源交付和人力投入的角度，我们可以建立组织效能模型。基于我们的价值交付模型，针对业务方，我们可以建立业务的体验度和真正的价值交付模型。基于研发自身管理，我们可以建立研发效能模型。这里只是列出了我们最常用的几种模型，基于这些模型，我们建立了一个完整的研发效能协作平台。

从不同的视角和不同的角色来看，无论是平台的管理者、研发的高管还是一线的产品经理或测试人员，每个人都可以根据自己的视角和能力来使用这个平台，并为其做出贡献。这个平台可以为他们带来价值。通过以上的介绍，我们简要概述了贝壳找房在研发效能方面的发展道路和整体系统架构。接下来，我将简要介绍我们的业产研端到端协同平台和DevOps工具链的建设，这是我们效能实践的基础。

3. 效能基建：业产研端到端协同平台 & DevOps 工具链平台建设

首先，我之前提到贝壳找房是一个具有长链路特征的业务。从业产研的角度来看，需求从提出到交付的过程可能非常漫长。自从我们在2020年建立了这个业产研端到端协同平台后，我们可以产出许多效能指标。例如，我们的交付比例在14天内已经达到了相当高的70%甚至80%以上。

从这些数字看起来，我们的交付效能似乎已经很高了。然而，实际上当我们与一线用户进行交流时，发现他们对我们的满意度并不那么高。为什么会这样呢？后来我们发现，一个明显被忽视的问题就像房间里的灰犀牛一样。例如，我们一线的作业人员可能会遇到一些问题，但是他们报告问题的方式类似于说从业务到产品这段路需要走很长的一段路。比如产品到研发交付上线可以类比于高速公路，我们的时速已经达到了80到100甚至更高。但是从业务到产品的这段路仍然是一条土路。我们不知道要走多久，要走多远，甚至不知道是否会遇到什么情况。

为什么我要重点提及这个实践呢？因为它是我们效能提升的一个重要基础，同时也给了我们一个重要的提醒，那就是我们在追求效能时一定要避免陷入局部优化的陷阱。我们应该以真正的客户价值、他们的收益和满意度为导向。

从需求的角度讲，我们实现了一个端到端链路的建设。从工程卓越的角度来看，我们建立了一个DevOps工具链平台。去年我在这个时候曾来到新通院向大家汇报，我们的工具链平台建设也获得了新通院优秀级的认证，这是对我们多年工作的认可，同时也有助于在公司内部推广持续集成和持续交付的实践。

我们自建了一个贝壳的流水线，通过吸附式和积木式的特性，将各个研发团队和工具团队建设的专项能力和单点能力集成起来。这个流水线拥有至少60个独立功能节点，其中一半以上是我们自己建立的，另一半通过统一的规范方式接入到流水线中，从而实现了工程能力的落地。

将这两部分结合起来，就形成了现在流行的价值交付和工程卓越的双流模型。在上面，我们以需求价值流为导向，通过每个需求状态的流转，可以了解当前的研发管理状况。而在下面，通过研发人员使用DevOps工具链平台，以代码变更为触点，串联起整个持续集成和持续交付的流程。这个双流模型看起来简洁，但实际上要真正落地需要做很多工作。首先，我们需要确保能力建设到位；其次，尽量实现每个状态流转的自动化，并尽量减少人为操作，或者实现某些节点数据的自动采集。这一部分也在2022年完成了一部分工作。

4. 效能实践：深入业务多场景多角色效能实践

这一部分主要与大家分享我们如何深入业务，并进行多场景和多角色的效能实践。当然，这是建立在我之前提到的业产研端到端协同平台和DevOps工具链建设的基础上的。首先，我通过一个实际案例向大家介绍。这个案例是关于贝壳找房的一项新兴业务，整个团队设定了明确的目标，即在2023年实现10%的人效提升。我们将分享如何介入这个团队，如何进行设计、验证实现，如何反馈问题并进行修正的过程。

首先，这个团队的规模大约在200人左右，其中前端和QA各约有50人的支持团队。该团队处于一个新赛道的核心业务中，正处于扩张期，并从0到1的开发阶段逐步进入稳定的迭代阶段。对于这个团队来说，降低成本的可能性较小，因此我们的目标放在提效上。我们与业务进行了沟通，了解他们的技术栈、迭代周期以及其他方面的细节，以及他们过去的效能经验。例如，在某个小团队内部进行的一些技术和组织上的提效，以及质量建设等。这些是整个项目的背景。在了解了这些情况后，我们按照效能实践的流程进行了规划，大致分为以下几个部分：首先是模型的设计，然后是提效措施的量化。接下来是研发规范的宣导和研发行为的观测。最后，我们通过一些效能结果数据和过程数据来验证我们的模型设计的可行性，并确定是否能够达到效果。

首先，我们的第一步是基于贝壳的效能专家对团队的需求提出一些通用的效能模型。例如，如果团队是一个后端团队，主要使用Java技术栈，并采用双待双周迭代模式，我们会提出一个通用的需求价值交付模型，从交付效率、速度、质量、满意度和成本这五个维度来评估该业务的交付能力。每个关键模型维度都会提供2到3个可选择的指标，并给出业务参考和建议。

这部分工作既包括我们的方法论和效能专家的经验，也包括通过模型数据建立一个基线，让业务了解自己的现状。同时，我们还引入了一些第三方效能咨询服务，例如思码逸，他们在效能领域具有丰富的经验和专业知识，可以提供客观公正的第三方数据。这两部分咨询服务为业务方提供参考，帮助他们思考自己的提效目标是什么。在了解了基线和已有效能实践之后，业务方可以确定自己的重点提效方向。

完成了这一部分后，我们可以看到，基于贝壳的效能专家和思码逸提供的咨询服务，业务方在已有的效能实践基础上建立了一个模型。这个模型考虑了业务体感和研发效率两个方面，同时关注内部和外部，以实现效能的落地。从外部角度来看，业务方可以说他们对业务方的交付需求快且多，因此他们的业务体感应该有所提升。而从内部角度来看，我们考察了研发团队，如果他们的交付量增加，即规模扩大，效率和人效也提升了，那我们可以认为内部研发效率也得到了提升。在这两个维度的提升的基础上，我们增加了一个约束条件，即质量。我们的前提是，如果你的工作量增加，速度加快，质量不能降低，这作为约束条件来设计我们的模型。完成了这一步之后，接下来我们考虑有哪些提效的举措可以实现这个目标。

我们提出了四个研发提效的举措。首先是一个低代码平台项目，其次是代码质量的提升，即将研发自测和测试左移。第三个是技术架构复用项目，即将业务抽象出一些通用的内容，进行技术中台的建设。第四个是组织和规范的提效，包括项目和人员管理以及会议管理。首先，每个举措都是可量化的，以人天为单位进行估算，基于历史数据进行估算。另外，提效结果需要与最终的效能指标建立相关性。具体来说，我们首先将研发提效的最终目标拆解为10%，然后根据估算的情况，将这10%的目标分解为各个项目的目标。例如，如果低代码平台承担了1%的目标，我们需要完成多少个低代码平台的建设，才能实现人力节省和效能目标。

代码提升的项目是基于2022年业务团队在缺陷测试方面的情况。我们的目标是降低15%的缺陷率，对于测试和研发团队来说，这将带来约1001200个人力的节约。第三个项目是技术架构复用，如果我们将技术架构提炼为一个技术中台，并让多个业务使用它，那么每个业务使用它可以节省多少人力资源呢？最后一个项目是组织规范的提效，这个项目可以重点讲解一下。组织规范在之前的团队已经试点过，并取得了良好的成效。它包括两个方面，首先是降低项目人员的离散度。这是什么意思呢？对于研发人员来说，最讨厌的事情可能有两个，一个是开会，一个是被打断。

在一线研发的体验和研发效能方面，我们希望尽量让一个人在同一时间专注于尽量少的项目。如果有10个项目同时进行，最理想的情况是每个项目都有专属的开发人员。如果无法实现这种状态，我们希望在一个迭代周期内，每个人同时参与的项目数量能够降低，并且这种降低是可量化的。这样一来，他们被打断的几率就会减少，同时会议的参与频率也会降低。另外，针对同一个项目，内部会议的频率也需要明确记录和量化，以及设定提效目标。对于一些非必须参加的会议或者不是每个人都需要参加的会议，也要制定明确的规定和实施。在数据采集方面，我们希望尽量避免让大家填写更多的数据，因为数据采集一方面可能不准确，另一方面也增加了人工操作的成本。尽量采用自动采集数据的方式来完成这四个提效举措，这样加起来大概可以达到10%的目标。也许你会问，我们能够这样精确计算吗？每个数据都能够实现1%、2%或3%的效果吗？实际上，我们并不是说最终一定要减少30个PD或50个PD，这只是一个设计模型，我们的目的是实现真正的提效效果。至于具体能减少多少个PD，我们可以事后进行回顾和评估。

这一部分的举措量化之后就是研发规范的宣导。在我之前的介绍中，不论是会议管理、低代码平台建设还是缺陷量化，都存在一个很大的问题，那就是我们所度量的对象是否具备规范化的特性？如果这些对象是比较随意甚至离散度很高的话，那我们的度量算法就不够科学。因此，在项目的迭代和需求管理方面，我们需要非常细致和明确的文档作为规范的载体。

在2022年的中国软件研发效能报告中，我们也可以看到流程规范成为阻碍效能的主要因素。无论是企业还是其他组织，可能并不缺乏研发规范管理的文档。更困难的是如何将这些规范性的文档真正落地。因此，我们首先提供的文档要求具备原则性和可操作性，符合一线人员的实际需求。其次，所有重要的、需要被管理和观测的研发活动都可以进行纠偏和观测。

接下来，针对这些较为规范化的动作和措施，我们进行了研发流程和平台的改造。我将以一个例子简单介绍一下我们是如何实现这一目标的。一个经常被问到的问题是需求颗粒度的问题，因为在我们之前的效能模型中，无论是价值交付模型还是其他工作流模型，需求颗粒度经常会受到挑战。大家认为需求有大小之分，交付100个大需求和小需求是不同的，交付周期也会不同。然而，如果我们只是进行数字游戏而没有实质意义，那又有什么意义呢？因此，我们以需求颗粒度作为一个案例，来讲解如何落地需求规范化。

首先，我们建议采用业界权威的 Invest 规则，并重点介绍了其中的三个要点：独立性、可单独上线、可单独测试和可评估性。对于测试上线和研发团队来说，这三点已足够让他们了解原则的含义。在这个原则的基础上，我们进一步说明了实际业务需求案例。以跨越多个小组的需求为例，我们解释了如何创建、拆分和关联各个业务，并流转这个需求。这是一个实际可参考的案例。

第三部分，我们会基于历史数据，例如需求的排期、参与人数、中位数和平均值等。根据贝壳的业务特性和权威的业界建议，我们提供了一些建议的数值。例如，建议每个角色的排期不超过10 PD，这是一个相对合理的值。

这是第三步，即颗粒度的建议，但它并不强制要求。在此基础上，我们如何确保实际落地呢？我们参考了思码逸提供的代码当量度量，以了解代码开发工作和排期工时是否匹配。最终，我们落实了一个结果，即90%以上的需求落在0-100的范围内。因此，我们只关注主体部分，而不苛求百分之百的完美度。因为首先，百分之百的完美是不可能实现的，其次，也没有必要。我们只需确保主体部分按照要求的范围进行即可。

通过前面的几个流程，我们从模型的设计、量化、宣导到观测，我们可以看到规范的落地情况。在观测方面，我们针对每个研发管理流程都有相应的数据看板，用以观测研发行为是否符合整体效能设计的要求。我在这里截取了一个项目管理的截图供大家参考。类似于迭代和需求，我们也有类似的看板来观测，这也是我们 BI 效能平台建设的一部分。

接下来，我们通过验证效能数据是否达标，来总结前面的几个流程。首先，我们设计了一个效能模型，通过规模和时效提升业务体感，以及通过规模和当量提升研发交付。最后，以质量作为底线约束，确保我们的代码和软件质量没有下降。我们将效能目标拆分为四个举措，以节省 PD 的方式推动这些举措的落地。我们认为，通过积极的方式推动事情会带来更积极的效果，而不是采用消极的方式。通过这四个举措的落地，我们提升了业务体感和研发交付的效能。最终，我们可以看到从2023年1月到现在，大约五个月的时间里，已经取得了明显的效果。我们以月报的方式查看效能数据的结果，并以双周的方式回顾和提升每个双周迭代中出现的问题。

通过这个新兴业务的效能实践，我向大家介绍了我们在贝壳内部如何实践效能度量。当然，还有许多其他场景和业务的试点，由于时间有限无法一一介绍。我在这里简单列举一些，比如从业务视角来说，除了服务端业务场景外，我们还有一些面向C端业务的场景，但可能难以从交付时长的角度衡量，因为它们的迭代非常稳定。因此，我们可能会提出一些基于版本和大迭代维度的效能指标。另外，对于前端业务场景，对于贝壳来说，它是一个大前端的BP方式，支持各个业务线。

从组织团队的角度来看，我们关注资源和人力的分配，战略项目的投入，以及一些专项领域的建设，包括低代码项目和质量专项。从研发工程师的视角来看，我们关注代码当量的产出、代码质量饱和度，甚至包括智能编码的效能指标，以及业界流行的DORA模型，它们也是我们在持续交付中落地的一些视角。

5. 效能沉淀：将方法论和实践经验沉淀到研发效能洞察平台

刚才我向大家介绍了如何在不同的业务场景和不同的视角下实践研发效能的落地。我们可以看到，这里面有许多经典的行业方法论，也包括我们自己的实践经验。在这两个基础上，结合我们之前的页产研端到端协同平台和DevOps工具链平台的建设，我们通过效能平台的方式将这些知识进行沉淀。

我们从去年下半年开始做这件事，底层是我们所有研发平台和研发数据的接入，左边是创建一个指标库，这个库可能有多个维度的建设量非常大，但对于具体的指标来说，在公司内部定义和口径是统一的，每个业务根据自己的实际情况选择关注的效能指标和效能体系。

在右边这一部分，我们建设了许多效能模型，并将其产品化。这包括生成可视化工具和效能诊断分析。最上层是用户场景的使用情况。刚才我介绍了一些我们在实践中遇到的模式和反模式，其中一些是单独的点，但我认为它们有实际落地的意义。首先，从问题出发紧抓重点要好过全面撒网。对于那些刚开始进行效能实践的企业来说，这点可能更有意义，因为研发流程非常复杂，如果全面抓取可能会无从下手，因此我们从问题出发解决问题会更好。第二，业务价值高于职能，产出工程卓越高于工具平台。在效能建设过程中，我们可能会陷入一个陷阱，即将工具平台建设视为更重要的事情，但实际上，实现业务价值并帮助业务真正提升效能才是更重要的事情。第三，谨慎创造效能指标。这并不是说每个公司或企业不能有自己的计算方式和效能指标，而是要谨慎使用。如果有类似的指标存在，建议优先使用业界通用的指标，这样在成本解释和推动落地方面相对容易。第四，不要急于建设可视化的BI平台。我们在2022年下半年开始进行了平台的建设，但之前我们已经尝试了许多年可视化的工作，如BI看板的建设、基于通用数据产品的数据中台驾驶舱等，最终我们才将经验和已有平台的建设应用到BI的可视化平台上。因此，在前期，我们可以使用一些通用的数据工具，快速尝试并实现其价值，待成熟后再考虑产品化。

下面是一些经验点。首先，效能平台的定位是辅助研发管理，避免与绩效考核挂钩。我们也不会提供与个人绩效相关的数据。最后，避免单一指标错误引导，以免导致研发行为的扭曲。

5. 效能度量：“度量—平台—实践”正向飞轮

在效能平台的建设中，我刚才画出了一些红色的部分，这些是我们目前已经在做或已经完成的部分，接下来我们将补充其他部分，重点关注几个事情。在右侧是我个人非常认同的效能实践的黄金三角。我们需要度量我们的实践，我们的度量和平台希望成为一个飞轮，产生正向循环的效果。这个正向循环的效果的结果就是体现在产品化的东西上，也就是我们的效能平台，它将整合效能专家的知识、我们的效能实践经验以及所有用户的使用场景，这是最终目标。

接下来我们要做的事情，首先是洞察分析。目前，我们只进行了一些简单的趋势分析和异常报警，类似于简单的洞察分析。但是我们已经开始尝试使用一些统计学方法，结合效能专家的经验和新技术探索，如GPT等，将分析做得更深入。我们希望能够通过自动化的方式，真正提供改进和建议给研发团队。

另一个是文化运营。对于效能实践来说，运营和技术文化是非常重要的一部分，因为通常人们对这部分不太了解，不见其真实面貌。我们目前已经开始通过撰写科普文章，并在公司内部进行宣传，持续输出这些内容，将这些概念推广给一线研发团队、研发主管和公司高管等。大家对这个事情都有一些需求和焦虑，通过持续输出，我们可以缓解这种焦虑，最终实现我们的目标。