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 视频号按时听课吧～
发表回复