突破效能瓶颈，详解价值流分析的五大流动指标｜直播回顾

9月21日，ONES 研发管理大师课第五期课程正式开课，我们很开心再次邀请到 DevOps 与研发效能资深技术专家张乐老师，给我们带来《通过价值流分析⽅法有效洞察和解决研发瓶颈》的精彩分享。借助价值流分析的五项流动指标，剖析研发团队遇到的效能瓶颈问题及解决策略，助力团队优化改进效能，实现可持续的提升和发展。

在上期课程里，重点解读了效能度量的五项精进，分别是建设度量的基础设施、设计度量指标体系、提炼洞察分析模型、落地洞察产品，并且要有数据驱动的实验思维。

这节课，在效能度量的五项精进基础之上，我们详细拆解其中的「洞察分析模型」这部分内容，重点讲解基于流框架的价值流分析模型。价值流是从最初的需求提出到实现价值的过程中，为客户增加价值而采取的一系列行动，通过收集和分析软件交付中的数据，可以获得端到端的可见性，识别瓶颈所在，驱动优化改进。

价值流分析的五大流动指标

价值流分析有五大流动指标，分别是流动效率、流动时间、流动速率、流动负载和流动分布。综合利用好这五项指标，可以去讲述一个关于软件交付价值流的完整的故事，也可以回答软件交付效率如何提高这个本质问题。

流动速率
流动速率是在给定时间内完成的流动项（如需求、缺陷等各种类型的工作）的数量，用于衡量生产力，预测研发团队到底可以交付多少工作。流动速率高，代表交付价值正在加速；流动速率低，代表最终成果物很少，交付过程阻塞，或是在制品过多导致的工作切换。

那么，流动速率与敏捷速率是什么关系？敏捷速率是一种敏捷规划工具，一般用一个团队完成了多少故事点来衡量。虽然流动速率是从敏捷速度的概念改编过来的，但是两者不完全一样。流动速率是一个全局性的指标，不依赖于工作量大小、工作范围和优先级的估算指标；它是基于对价值流的直接观察，按照完成的流动项的数量来计算，而非按故事点去估算。

还有一个常见问题值得探讨：流动速率为什么要按个数计算，而不是按故事点算？用故事点估算容易引发规模冲动。如果我们拿故事点来横向对比，比如团队中有人做 20 个故事点，有人只做15个故事点，就会人为地造成压力；这种压力让成员在估算故事点时有多算一些的倾向，反而更不准确。也就是说，我们不希望让故事点成为业务产品和研发之间做数字博弈的一种工具。

流动时间
流动时间指的是从流动项被接受并进入价值流到其完成所花费的时间，包括活跃时间和等待时间，用于跟踪流动时间，以帮助交付过程变得可预测。

如果流动时间低，在表面看来是件好事，但在实际工作中会出现「后补需求」的情况（在需求接近完成时再补充和追加需求），所以流动时间的计算有可能是失真的；相反，流动时间高，是一种不好的状态，有可能是在制品过多导致的工作切换，有可能是工作被阻塞，或是员工工作效率低等等。这时，我们要再结合流动负载、流动效率等其他指标，做进一步细化分析。总体来说，我们希望流动时间的指标是偏低的，但是也不应过于低，失真的数据没有价值。

流动负载
流动负载指的是价值流中在制品的数量（已开始、未完成，即正在进行中的工作），包含了状态为活跃或等待的流动项的数量，是一个先导性指标。

如果流动负载低，代表有潜在的人力资源浪费，不一定是好事；如果流动负载高，则可能存在过多的在制品所导致的交付延迟、成本增加、质量下降、员工抱怨等等情况，长期超过实际产能安排工作将导致倦怠。

同时，流动负载高也分两种情况：如果流动负载高，并且流动时间长，可能是在制品过多导致的工作切换；如果流动负载高，但是流动时间是短的，则有可能是有很多需求被搁置了，成为「僵尸需求」，这时候就要综合判断是将这些需求继续推进还是干脆把它挪走，不要让它们一直停留在交付管道中占用交付的带宽。

那么，流动负载到底如何计算？如果我们把交付过程想象成一个管道，进入管道的部分才会产生管道内的压力；对于尚未进入管道的部分，虽然在前面排队，但是不计入流动负载。所以，流动负载衡量的是管道内的工作单元数，而不是两端的情况。

流动效率
流动效率指的是流动项处于活跃工作状态的时间占总消耗时间的比例，可以帮助团队从瓶颈中可视化等待时间，以便找出导致流动停滞的问题。在实际的工作中，要想需求交付得快，很多场景下不是靠做得快，而是等待更少，因为很多团队的需求交付过程中绝大部分的时间花费在等待上，这就是度量流动效率的作用所在。

流动效率能够达到30%-40%已经是很理想的状态了。如果流动效率过高（超过40%），就要考虑是否存在数据的失真，有可能将等待的工作时间也算成活跃的时间了。流动效率低，会导致流动负载的增加，出现更长的等待队列。

价值流分析的这五项指标是一套体系，流动效率是端到端、全局性的指标，不能只看开发阶段的流动效率，而是看整个交付过程的流动效率。

流动分布
流动分布是通过计算给定时间内完成的流动项（特性、缺陷、风险和债务）的比例，来衡量在不同产品发展阶段中各种类别工作的实际投入情况。

产品在不同的阶段应该选择不同的流动分布，例如公司的产品处于初创阶段，就要快速试错，可以将所有时间投入在业务需求上；当产品的用户越来越多，就要重视口碑，要快速解决技术问题并满足监管要求；当产品进入成熟期后，更关注的是稳定性和质量的情况；最后，在产品的衰退期，绝大部分工作就是修复缺陷，做好运维和运营。

所以，我们不能一刀切地去考虑问题，而是根据产品当前所处的阶段，灵活选择恰当的、让企业实现利益最大化的流动分布。

研发过程中的常见瓶颈及应对策略

在研发过程中，度量指标的下降，有可能是研发瓶颈导致的。到底有哪些研发瓶颈？这些瓶颈又如何去解决？我在这里总结了四种常见的研发瓶颈：

第一，稀缺的专家资源，导致流动受阻。它的现象是，某个活跃状态（如「开发」）存在瓶颈；并且在此之前的等待状态阶段（如「待开发」），出现大量堆积工作（在制品数高、周期长）。

解决的方法有三种：

• 在存在瓶颈的活跃状态阶段，增加有技能的资源，比如增加人手；
• 对团队成员进行专业技能培训，或是跨专业的横向培训；
• 还可以通过自动化、自服务、流程优化或规范简化解决。

第二，缺乏自动化或工程能力落后，导致效率低下。这指的是有些流程必须由人来完成，无法用机器做。比如，代码想要在预发环境进行验证，但是没有资源和机器，要靠员工申请提单、去买机器和部署；部署之后再要去验证，大量需求在待测试状态，只能相互等待。

对于这个瓶颈，解决措施是：
实现自动化流程，引入自服务机制，提升工程能力；
通过自动化手段提升吞吐量，不依赖于资源或专家就绪，从而提升效率；
不依赖于某个中心化的团队按优先级完成工作，如发布审批、环境申请等。

第三，繁琐的流程，导致等待和长耗时。举个例子，在晚上，路上只有一辆车，但也需要等待红绿灯，这就是过于繁冗的流程反而限制了我们的效率。

这个瓶颈解决的措施是：
以高水位线（最大制品数量）为线索，找到瓶颈点问题所在，即使当前数值已经回落，也依然可以做分析；
自动化变更审批流程，识别出高风险变更的标准，哪些是必须要走的审批，哪些是低风险变更可以自动化验证、直接部署。

第四，过多的依赖，导致工作流动停滞。依赖就是要等某人或某事完成之后才能继续工作。解决策略是对依赖建模（如使用依赖矩阵），与依赖方沟通，探索解决方案；长期来说，要花时间去除依赖，而不仅仅是管理依赖。

一般情况下，依赖总共分为三种：架构依赖、组织依赖和活动依赖。架构依赖的解决重点是找到系统的断裂面，将系统分成两个或多个部分；组织依赖的解决重点是建立跨职能团队，每个团队有专业知识、能力和权限去满足客户需求，不需要升级和复杂的跨团队沟通、排期、协调；活动依赖的解决重点是自服务与自主性的提升。

建立业务价值指标与研发指标间的映射

我们讲完价值流分析的五大指标，那么究竟如何将效能度量指标与业务结果关联在一起呢？这是非常重要的，二者关联才能使用真实数据来确定相关性，并不断地学习和调整。业务指标一般分为三类：价值、成本与满意度，我们来看看二者之间的关系吧：

流动速率的增加说明交付的产品多，有可能会促进潜在的收入增长；
流动时间的延长，导致功能交付延期，有可能会导致用户活跃度下降；
流动负载过高，在制品过多，员工工作压力高，有可能会导致满意度降低；
流动效率的提升，有助于解决价值流中的浪费，有可能会降低工作成本；
在流动分布中增加解决缺陷和技术债务占比，有可能会降低质量问题的返工成本。

因此，我们一定要想办法，在研发指标与业务指标之间建立映射，不断实验和探索相关性，从而建立 IT 交付和业务结果之间的那一层缺失的连接。

本期课程到此结束，希望带给大家更多收获，感谢聆听。

- Q & A -

Q1：需求价值流分析中很多都需要依赖完整的数据，如何确保数据的实时性和准确性？

张乐老师：数据时效性和准确性必然会影响度量结果。我的观点是，度量指标不在多，而在于准确，度量的数据需要是全量的、全要素和实时的。

举个例子，需求交付周期的指标有很大一部分依赖于需求本身的数据，什么时候处于开发阶段、什么时候处于部署阶段，都需要通过自动化的、实际发生的工程活动去联动，而不是靠人为的沟通。在 ONES 也可以实现数据联动的功能，在工单管理功能里提交工单后，可以把工单转译成需求，并拆分成多个用户故事，再拆分几个任务，这些信息在同一个项目以及跨项目之间的联动都是可以自动流转的。

所以，效能度量数据的准确性一方面可以靠流程、靠人、靠机制去解决，但更好的方法还是要靠工程上的状态联动，自动化地实现数据同步，从而提升准确性。

Q2：在效能度量实践中，如何去判断哪些关键因素、环节是需要进行提升的呢？

张乐老师：这与我们上节课讲的「GQM」分析模型（向目标对齐，做到以终为始的度量）不谋而合。对于这个问题，一方面，要和目标对齐，目标和实际情况的差距就形成了一个很关键的判断依据。另一方面，我们还可以用数据去观察它。比如趋势分析，看这次的度量数据和历史平均值相比是升高还是降低，和基线相比是超过还是低于基线。这些都能够决定这个指标是否需要改进，以及哪些关键因素需要提升。

Q3：做度量也是要投入的，拿到度量结果是一方面，还要解读和改进。整个过程如此复杂，这不是和实现速度和敏捷性的目标相违背吗？

张乐老师：首先，需要明确一个观点，效能改进其实并不来自于度量本身，而是源于改进的行动。所以对于度量来讲，它更多的是告诉你问题在哪里以及应该如何去做，但最终一定要采取具体的行动，效能才能得到实际的提升。

那么，如何去降低度量过程中的复杂性和成本呢？借助度量产品或平台的帮助会好很多。它不仅仅能帮助我们自动产出图表、汇集数据，省去人工加工数据的时间成本，还可以实现自动化洞察的技术：如趋势洞察、正负贡献度分析等等。所以，度量复杂性的问题慢慢都会被自动化能力和算法去解决的。

Q4：外包公司有时候很多项目一起进来，导致资源严重冲突，哪个项目经理嗓门大就容易获得资源。对于解决研发项目资源紧张有什么好建议吗？

张乐老师：谁嗓门大就可以获得资源，这一定是非理想状态。比较好的做法还是要和企业的阶段目标去对齐。资源紧张的问题，最重要的是将数字化链路（从前期的目标设立，到需求或项目的设立，再到人力资源的安排）打通；融会贯通后，自然能知道人力投入和预期投入以及最终目标之间的配比关系是否正确。有时候，通过一个图表就能看出是否应该投入更多资源给某项目或产品，或者要检讨一下某项目/产品是否已经过度投入。

Q5：对于不同的研发团队，管理流程，要求都不一样，如何能够在较小的改变研发人员工作习惯的情况下统一度量出来？

张乐老师：从技术角度来看，需要在度量基础设施层面支持建模和模型配置的能力，把异构的研发流程和数据模型，向标准化的模型去做配置和映射，这样就可以得到跨不同流程和不同类别团队的统一度量。另外，从管理角度来看，也有一个颗粒度的问题，在一些高阶流程和粗粒度的阶段上，应该是可以做对齐的。

Q6：度量太散，理念差别比较大，该如何整合呢？

张乐老师：上次课程也讲到，度量需要以终为始，从目标出发寻找问题，然后再确定指标（「GQM」方法）。以此为指导，可以在度量的目标、维度上先达成共识，而不是直接沉降到具体的指标上。当然，我们日常中的很多底层思维方式，还是需要不断升级并达成共识的，比如能够较为深刻地理解精益思想、价值流管理的方法，对有效开展研发效能提升工作，都是很关键的。

ONES 研发管理大师课第一季课程仍在火热进行中，下节课（10月19日，19:30）我们继续邀请到 ONES 研发效能改进咨询顾问董晓红老师，为我们系统性地讲解500强企业提升研发效能的实践案例。请大家搬好小板凳，关注 ONES 视频号按时听课吧～