在数字化转型的浪潮中，越来越多的企业开始关注数字化建设对企业效能的提升。在这一趋势下，比心技术中心通过推进降本增效等措施，为提高研发交付效率创造了良好的条件。 因此，在年初的讨论中，研发效能的提升也成为了一个重要的议题。为此，我们希望通过数字化建设，深入评估和发现效能瓶颈，从而进一步提高研发交付效率。 本 文将通过项目流程优化、研发效能度量、数据报表分析以及过程复盘，浅谈研发效能在比心直播的实践。
研发效能的定义
管理大师彼得·德鲁克曾说过：效率是“把事情做对”，效能是“做对的事情”。研发效能是指研发团队在特定时间内完成产品开发的能力和效率。蚂蚁集团 CEO 在总裁会上提出：任何事情不能被衡量，就不能被改善，研发效能需持续建立指标体系，收集数据，识别问题，再通过自动化工具、服务体系等去解决研发问题，用赋能的思想，最终让研发工程师高质量、高效工作。
研发效能的目标：就是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能。
影响研发效能的三个核心因素： 1. 做高价值的事：我们的研发资源是否投入在了更有价值的需求上，核心是洞察高价值的需求以及资源投入与需求匹配情况。2. 正确的做事：通过采用更加合理的方式提升研发效率、质量，减少资源、时间的浪费，最终提升需求吞吐，降低成本。3. 可持续的顺畅交付：让交付过程顺畅、稳定、可持续，能够持续保障高的需求吞吐。
当前问题
- 研发过程中的可视性差：每个业务线都需要多个团队的协作，涉及产品、设计、开发、测试、风控、支付和运维等角色。在这个过程中，任务处理的进度、依赖关系、瓶颈以及潜在的风险都难以直观观察和监控。
- 用比心直播举例，在推行研发效能之前，需求的交付时间长，粗略统计到的平均交付周期是 4-6 周；
- 需求也会因时间而发生价值上的变化，便可能导致设计、研发等资源的浪费；
- 现有流程在感官上的等待时间多：等待内审、等待设计、等待排期、等待研发、等待测试等等；
基于当前的痛点和问题，希望通过改进流程、优化工作效率、降低人力浪费，以及度量研发效能来提高交付效率，让过程更加可观测、可分析、可提高效率。
现状分析
在业界，一般用三个指标来衡量研发效能：交付效率、交付质量和交付能力。此外，基于需求管理工具的数据收集，可以拆分出三个关键点：需求创建时间、V2 评审已通过、需求完成时间。通过统计这些数据，可以得出需求的交付周期、研发交付周期以及需求吞吐量等指标数据。
根据各业务线拉齐的三个关键点，处理并绘制出最初的图表数据（如下图），可以很明显地看出几个问题：
- 四周以上交付的需求占比达到了60%；
- 关键数据缺失：中间状态-已V2评审，导致创建-V2 和研发交付周期（V2-交付）的数据失真；
- 无法详细地分析过程问题；
以上数据反映出了我们在流程迭代方面存在一些问题。为了解决这些问题，我们将采取一系列优化措施，包括制定标准化的流程，并使用科学的数据度量方法进行阶段性检查，以提升团队效能。
接下来我会从这两方面分享我们的实践经验：
流程迭代优化
为了让高价值的需求更快地交付，我们主要在当前中流程做了以下方向的优化：
- 优化流程规范
- 提高需求门槛：通过数据分析和价值预测来筛选需求；
- 细化需求颗粒度：确保每个需求的大小适中，使预估排期时更为清晰；
- 增加每周优先级更新流程：定期更新优先级，确保团队专注于最有价值的需求；
- 周期缩短：排期周期从2周变为1周，有效提升人力排布；
- 信息清晰：TPU拉齐横纵，加强需求沟通，提升工作积极性；
- 分享成果：上线后实时分享数据，获得成就感。
2.单周发版的时间轴
举个例子：一个标准大小的需求：整体规划排期 3d，设计 4d，研发 3-4d，测试到提审 2d；周四新需求内审通过后，会进入设计排期，一般会在下个周三拉上研发测试开 V2 评审，周五确认排期，并再到下一周完成开发测试和集成，这样平均一个需求 2.5 周可以完成交付。
除此之外，还优化了一系列的流程规范，如：每周窗口固定原则、需求管理工具的流转规范等。
研发效能的度量
通过对当前业务价值流的分析，设计了合理性高的度量指标，以此来评估产研效能。同时，我们也遵循了 SMART 原则，确保指标具有明确的含义、单位、计算公式、优先级和分类等属性，以保证指标的有效性。最终，我们选择了以下几个核心度量指标，涵盖了效率、质量和能力三个方面，对产研效能进行了全面的量化评估。
交付效率 目标是促进端到端、及早的交付，用尽可能短的时间顺畅地交付价值。具体可细分为以下指标：
- 需求交付周期（创建到交付）
- 技改需求占比
- 需求交付周期（创建到交付）
- 技改需求占比
- 需求在各阶段的停留时长
- 需求变更数/估时
- 需求变更率：统计周期内，发生变更的需求数与需求总数的占比
- 临时需求/插入需求
- 需求目标占比
- 需求按时交付率：统计周期内交付的需求中，满足业务方期望上线日期的需求个数占比
- 需求规模分布：统计周期或每个迭代内需求预估大小的分布
- 研发交付周期（V2 到交付）
- 需求吞吐量：统计单位时间交付的需求个数
- 需求吞吐率：周期内交付的需求个数 / 统计周期（月度/季度/半年/年度）
交付质量 目标是促进端到端高质量交付，避免不必要的错误和返工。具体可细分为以下指标：
-
线上质量
- 线上 bug 有效数
- 线上 P1、P2 故障数
- 客户端质量
- 服务端质量
- H5质量
-
过程质量
- 需求质量
- 研发质量
- 测试质量
- 发布质量
在过去一年中，我们成功落地了质量运营，并在今年新增了一些度量指标，以进一步优化质量管理过程。我们持续推进这些改进，以确保我们的产品和服务质量始终如一。
交付能力 目标是建设卓越的工程能力，实现持续交付。具体可细分为以下指标：
- 发布次数/频率：平均多长时间发布一次需求
- 发布前置时间：从代码提交，到功能上线所需要花费的时间
- 发版次数
- 发版类型
- MTTA
- MTTR
这张全景图清晰地展示了业内效能研发专家绘制的效能度量指标、软件研发周期以及业务结果之间的关系。通过提高交付效率、质量和能力，有助于推动整体研发效能的提升，并且研发流程的高效迭代也能为组织效能的提升和优化业务结果做出贡献。
度量数据分析
在执行一系列推进措施后，尽管需求交付周期和研发交付周期均有所改善，但在推行了一个半月后，需求交付周期为四周以上的占比从 60%下降到了 40%。基于当前状况和数据分析，我们有望将这一比例进一步降低至小于 20%。
根据目标，我们对最近一个月的需求交付数据进行了拉取和分析。发现需求的交付周期普遍较长，主要原因是在需求创建早期就被收集到需求池中，并需要经过内审、交互设计、需求 V2 和研发估时等一系列环节才能进行排期开发。因此，我们还需要结合实际流程，增加相关的度量指标来设计研发效能度量体系，以便直观地分析研发流程的问题。
参考业界常用的价值流图（如上图），我们可以看到在需求受理前，有一个等待时间的 backlog，于是我们把需求池的数据做了划分，避免每次重复的分析，将需求交付周期（创建-交付）拆成了产研交付周期即需求内审通过后到交付完成的数据（如下图）。
除此之外我们还绘制了各种图表，并采用了趋势图分析、下钻分析、区域图分析、关联性分析等方法进行数据分析，从宏观到微观一层层地钻下去，找到那些影响效能的阻碍因素，针对性地采取改进措施，让效能真正地提升。
趋势图分析 在度量研发效能的指标时，随着时间推移的变化趋势会比绝对值更有意义。下图是在比心直播中推进研发效能分析时绘制出来的趋势图。从下面的趋势图能大概看出，整体的交付周期在缩短，且每周承接的需求增加，并趋于平稳。
下钻分析 下钻分析可以帮助我们从宏观到微观，从表象到根因逐层排查问题，找到影响效能的瓶颈点。
分析统计周期内的等待状态耗时数据，可以查看具体需求每个等待状态的时间，从而找出异常需求，做针对性原因分析。
区域图分析
关联性分析
之前在对一段时间内的技术需求进行统计分析后，我们发现其中有一些技术需求的占比偏高。为了深入了解这个问题，我们详细地分析了技术需求数据和人力投入度，发现客户端的投入度有所下降。经过进一步的分析，我们认为这个问题的主要原因是产品侧的需求池不够，特别是那些侧重于客户端的需求。
过程复盘
虽然现有的度量指标和图表可以发现一些问题，但距离我们定下的交付周期四周以上的需求小于 20%的目标仍有很大的距离。因此，我们组织了一次深度复盘。采用 GQM（目标-问题-指标）方法，我们聚焦特定的目标，提出相关问题，找到能反映核心问题的指标，自上而下层层推进，以驱动研发效能度量。
除了以上复盘得出的度量指标，我们还与业界相关的指标维度做了比对。价值流是指从最初的需求提出到最终交付给用户的整个过程，包括所有涉及到的价值创造和浪费。我们通过收集和分析软件交付中的数据，可以获得端到端的可见性，识别瓶颈所在，驱动优化改进。下面我们介绍价值流分析中的三个流动指标。
- 流动效率：处于活跃状态的时间占总时间的比例，可以帮助团队可视化等待时间，以便找出导致流动停滞的问题。
-
从下图可以看出，在我们推进研发效能后，迭代过程中交付流动效率为 34.38%，在业界属于较为理想的值。
- 根据业内某位效能研发专家的统计，流动效率能够达到 30%-40%已经是很理想的状态了。如果流动效率过高（超过 40%），就要考虑是否存在数据的失真，有可能将等待的工作时间也算成活跃的时间了。流动效率低，会导致流动负载的增加，出现更长的等待队列。
-
流动负载：价值流中的制品数量，包括已开始和未完成的工作量，包含了状态为活跃或等待的流动项的数量；
- 如果流动负载低，代表有潜在的人力资源浪费，不一定是好事；如果流动负载高，则可能存在过多的在制品所导致的交付延迟、成本增加、质量下降、员工抱怨等情况，长期超过实际产能安排工作将导致倦怠。*
- 如果流动负载低，代表有潜在的人力资源浪费，不一定是好事；如果流动负载高，则可能存在过多的在制品所导致的交付延迟、成本增加、质量下降、员工抱怨等情况，长期超过实际产能安排工作将导致倦怠。*
-
流动分布：通过计算给定时间内完成的流动项的比例，来衡量在不同产品发展阶段中各种类别工作的实际投入情况。
- 这里我们从需求的分类上做了拆解统计，需求类型分为：产品需求、活动需求、设计需求、技术优化等。统计近一个月的需求类型分布占比，技术需求对比 5 月份从 20%降到了 7.5%，使资源和时间都更聚焦于业务上。
思考总结
根据持续改进的理念，团队需要停下手头的工作，定期回顾团队内存在的问题，思考如何改进。持续改进是为了让团队不断进步，提高竞争力，防止现存问题影响团队的发展。研发效能提升也是持续改进思想的具体体现，旨在让团队更快地交付客户想要的产品，提升研发效率。随着度量体系的逐步成熟，我们开始引入效能分析和提升的实践分享，创建效能度量指导手册、效能提升案例库和专项解决方案知识库，将过程资产沉淀下来，将度量、改进和提升效能融入日常工作。
注意事项
-
避免度量的平均值陷阱
- 在软件研发领域，从数据统计的角度来看，需求交付周期这类指标通常符合韦伯分布，这是一种连续的概率分布，类似于一种向左倾斜并带有长尾的正态分布。所以，对于需求交付周期，推荐的度量方法不是平均值，而建议使用第 85 百分位数。其原理就是将一组数值从小到大排序，处于 85%位置的那个数值，就称为第 85 百分位数。
-
把度量引导到正确的方向上
- 如果度量指标仅仅作为 KPI 来进行考核，员工可能会更加注重完成这些指标，而忽略了实际工作的价值。这样的情况下，团队的工作效率可能会下降，并且数据也可能会出现问题。数据不是武器而是持续改进和学习的工具，我们度量的是工作而不是工作者。
