优化价值流动的过程，就是在提升研发效能

本文主要是介绍优化价值流动的过程，就是在提升研发效能｜ONES Talk，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

8月26日，2022 China DevOpsDays · 北京站在线上举行，DevOpsDays 是风靡全球的 DevOps 顶级峰会，聚焦自动化、测试、安全、持续交付、持续集成等多领域的最新动态与最佳实践。

作为企业级研发管理工具的领军者，ONES 受邀出席本次大会。ONES 研发总监陈亮宇发表了题为《渐进式变革：应对价值流中的瓶颈效应》的演讲，分享 ONES 在 DevOps 实践中的洞见及思考。

自创立之初，ONES 就积极拥抱 DevOps 文化，据不完全统计，前30号员工有一半都是 DevOps Master。在规模化发展和服务客户的过程中，ONES 仍然在持续积累 DevOps 实践经验。

以下是陈亮宇演讲的精华内容。

重新认识价值流

在落地 DevOps 实践的过程中，我们经常会听到大家聊「价值」，但我们真的理解「价值」的含义吗？「价值流」表达的到底是什么？

首先，「价值」和「价值流」并不是 DevOps 首创，如果追根溯源，我们会发现 DevOps、敏捷、看板等在 IT 领域广泛传播的思想，都来自于传统制造业中的精益思想。精益思想的五大原则也被反复修改和验证，最终重新表达，使其更适合应用在 IT 领域。

精益思想的第一步就是明确什么是企业的核心价值。精益思想里提到，价值体现在具有特定价格、能在特定时间内满足客户需求的产品上。这简单的一句话里有三个很关键的要素。

价值是由客户决定的，了解客户需求是生产者的基本要求，能满足客户需求的产品才具有价值。因此，我们需要明确客户是谁，他们的需求是什么？
价值是有时间要求的，客户的需求不会一成不变，时间点、时长都会影响客户的需求，比如，为双十一准备的系统，一旦未能在双十一如期交付，该系统就失去了它本身的价值。
价值是有特定价格的，任何产品都需要明确的价格，只有当客户愿意以产品价格进行购买时，产品的价值才能被体现。另外，不存在完全免费的产品，它的价值只是被更复杂的商业体系给隐藏了。当我们是生产者的时候，要非常清楚地知道每一件产品的价格。

‍

定义价值是需要企业不断审视的活动，它能帮我们快速识别：哪些活动是不产生价值的浪费行为，哪些才是我们真正需要关注的价值活动。

当我们达成了价值共识后，就需要了解价值从需求录入到交付上线的全流程，也就是我们前面提到的价值流。怎么理解流动的概念呢？

价值流的流向是从左到右的、端到端的完整流程。如价值定义中所说，只有产品真正交付到客户手中，并且被客户认可其价值才被体现，脱离最终交付去聊价值流中的任何单一环节都是片面的。
价值是需要连续不断地流动起来的。传统的生产中，流程永远是批量完成一个环节的工作之后，再流入下一个环节。这里面有两个问题。第一个是，会产生大量的等待环节，资源没有得到最大化的利用。第二个问题是，客户会为流程中的等待时间去买单。只有让生产节奏与客户需求的节拍对应起来，并且让价值不断流动，才能让企业生产力最大化输出。
价值是需要被客户拉动的。我们常说，做对的事情比做对事情更重要，我们试想一下，如果生产一个对于客户来说毫无用处的产品，所耗费的成本更大。

在 IT 领域，价值流动的过程就是产品研发的流程，优化价值流，就是在提升企业的研发效能。那我们应该怎么做呢？

通过价值流图和价值流分析，我们能轻易地发现价值流动过程中存在的浪费，消除浪费是优化价值流的重要手段。在研发管理领域中，常见的浪费分为三种。

（1）事务性浪费

什么是事务性浪费？我举个简单的例子。比如说，我们需要刷墙，刷墙前，我们需要购买刷子、油漆、工装等物品，并了解刷墙的具体步骤和方法，这些计划和准备动作就是前置事务性成本；当刷完墙后，我们需要收拾，打扫，甚至发个朋友圈，展示自己又学会了一门新技能，这些在完成之后的总结性和收尾性工作，称为后置事务性成本。

这些工作并不会真正产生价值，但是必不可少的，我们需要审核这些投入是否过多，防止浪费。

（2）协调性浪费

那什么是协调性浪费呢？还是以刷墙为例，这次不是一个人刷墙，而是一家人一起刷。当涉及团队协作时，必然会在沟通协调上花时间。比如，刷墙前要分工，保证大家都理解了各自的工作；刷墙过程中，要沟通各自负责事项的进度，这些沟通成本都属于协调性成本。同样的，协调性成本也不会真正产生价值，我们需要谨防它变成浪费。

有个简单的办法能帮大家分析，什么活动能真正产生价值。我们可以反问自己：「如果这项活动是产生价值的，那我们原则上应该希望它多做。所以，我们真的希望这个活动多做吗？」比如迭代早会，早会是很重要的，但如果一个早上要开两次早会，相信大部分人都不会愿意，因此，我们可以断定早会是一个协调性成本。

（3）返工型浪费

返工意味着浪费。任何角色，任何环节都需要关注自己的返工情况。返工不仅仅是缺陷，像产品设计的缺陷、性能问题、安全问题，都会导致返工，最终产生返工成本，而大部分的返工都是浪费。

如果按照这三种类型的浪费去分析我们的价值流中的活动，我们可能会发现，浪费无处不在，那么，我们应该如何通过改革来优化价值流，消除浪费，从而提升研发效能呢？

如何优化价值流？

我们先看一个很有意思的理论：萨提亚模式，它原本是用来分析人在遇到变故时候的心理反应，我们可以将萨提亚模式应用到企业变革中去。

按照萨提亚模式的描述，企业变革分为5个阶段：

第一个阶段：旧常态，指的是未遇到变故时的状态。
第二个阶段：引入变革，指的是当人们发现有新的外来因素试图改变现状时，有人会观望，有人会反对，有人会拥抱新的变化，而持反对意见的人会形成一股阻力。
第三个阶段：混乱阶段，在这个阶段，有些人可能会担心变革对他们造成影响，有人可能还在消化变革带来的新信息，有些人可能在尝试融入到变革后的情况中去。总之，团队处于一个相对混乱的状态，其产能会大幅下滑。
第四个阶段：接受变革，大家享受到了变革带来的好处，此时大家会放大变革的正面影响，团队效能持续提升。
第五个阶段：新常态，当变革的动作接近尾声，大家已经完全接受了变革，组织会重新进入新的稳定期。

通过下面的图，我们可以看到，混乱阶段是变革引入后效能下降的阶段，遇到的变革越大，混乱阶段越长，效能的下降幅度也就越大。

为什么一个心理学模式可以用于企业的组织变革？其根本原因是，组织是由人构成的，变革最大的阻力也是由人的主观心理反应造成的。我们需要以渐进式的变革方法，来减少人带来的阻力，防止企业效能长时间处在混乱的时期。

回到问题的根本，我们需要优化价值流。价值流中存在很多浪费，我们需要找到最先需要解决的浪费。

实际业务中，瓶颈节点的节拍决定了整个流动过程的速率。我们需要以渐进式的变革，不断地识别并解决瓶颈处的问题。

（1）变革开始前：工作可视化

看不到的流程是无法分析和查找的，最终找到的也只是主观的判断，无法在团队之间达成共识。因此，变革之前，我们需要将万物可视化。我们可以将传统制造业的生产流水线和看板改造应用到研发管理领域。

明确订单的开始点和完成点。订单开始代表客户提出了需求，订单完成代表了将需求交付给了客户。这两个环节均依赖客户，不受我们控制。看板是一个受限的系统。我们需要将这两个环节可视化出来，并且明确说明，在这两个环节之间，就是我们价值流转的看板。
分析客户需求。按照前面的价值定义的方法，我们需要知道，客户的原始需求是什么样的？有哪些类型？到达时间是什么？时间节拍怎么样?客户对于这些需求的交付周期如何？当我们了解完客户的需求后，需要明确我们提供的服务有哪些？紧急服务？固定交付时间的服务？还是常规服务？客户对于不同工作项类型会需要什么样的服务？
了解团队的生产能力，并且根据生产能力和需求节拍制定在制品限制。如同价值流分析一样，在可视化过程中，我们需要反复核对是否已经将万物可视化，如果还有隐含的工作，需要继续将其补齐。在这个过程中，可视化的颗粒度可以进行取舍。

用 ONES 快速构建可视化看板

（2）进行渐进式的变革

构造完可视化看板后，我们就可以开始渐进式的变革了。如前面提到的，渐进式变革的根本方式是持续不断地识别并解决瓶颈，我们可以将渐进式变革分为五个步骤：

第一步：识别瓶颈

当完成了可视化后，这件事就变得非常简单。瓶颈的特征是，上游堆积，下游饥饿。如下图所示，工作堆积在研发完成的区域，但测试完成的区域却是空的，所以，我们可以很清楚地知道，这张图里，测试是瓶颈资源。

用 ONES 看板快速识别流水线瓶颈

第二步：用尽瓶颈

回顾一下前面提到的浪费类型，我们现在可以更加专注地分析，瓶颈处资源的事务性成本有哪些？协调性成本有哪些？返工成本有哪些？有哪些成本我们没有控制好，导致其转变成了浪费？在返工上，我们有什么优化手段？

通过审视这些浪费，我们可以保证瓶颈处的资源最大限度地投入到了价值生产的活动中去。

第三步：配合瓶颈

当我们用尽瓶颈资源后，还需要调整价值流中其他环节的策略，来真正保证瓶颈环节的最大化利用。

减少上游的工作，瓶颈处的工作流速决定了最终的产出速度。价值需要流到客户手中，才能真正被体现出来。所以，上游的工作内容在瓶颈处堆积，本身就是一个浪费。

我们应该保证上游的生产节拍与瓶颈处最大化的生产节拍保持一致。我们关注的是价值的流速和生产的可预测性，而非资源最大化利用。在上游输入减少后，上游可以开展一些真正对后续生产有提升的优化工作。

当然，总会存在一些变异性导致瓶颈资源出现短暂的限制。例如，上游的关键人员家中临时有事请假了，上游给的在制品变少了，下游的部署部门遇到机房故障，导致无法正常消耗瓶颈完成的在制品。如果上下游经常产生变异性，就可以设置一些缓冲区来保障瓶颈资源最大化利用，这可能会导致流速变慢，但它却更稳定。

第四步：突破瓶颈

当瓶颈疏通后，瓶颈处的流速依然决定了流水线的生产力，这时，我们可以进一步突破瓶颈。突破的手段比较简单粗暴：

有节奏地招人：首先我们要知道的是，招人是会导致流速变缓的，我们需要评估招人的节奏和影响，来保证招人的影响降低最低。
自动化：这也是 DevOps 里最最重要的话题，把人能完成的机械工作交给自动化来处理，是 IT 领域突破瓶颈资源的终极手段。

第五步：循环改进

当我们突破了瓶颈资源，我们会很自然而然地发现下一个瓶颈。但经过上面的变革，效果如何，又该如何度量呢？我们完全可以使用价值流最经典的指标来衡量变革的情况，如前置时间、周期时间、流动时间、%C/A 率等等。

但我们怎么分析呢？如下面两张图，左边是我们某次优化前的前置时间分布图，右边是优化后的，变好了还是变坏了？没有固定的答案，大家需要找到适合自己企业的分析方法。

几个关于度量的 Tips：

可预测性有时比单纯的前置时间变短要好。打破部门墙的不是高层的压力，而是部门间彼此的支持和信任。可预测性是信任的基本条件。
全局胜利比局部胜利更重要。很多时候，我们特别喜欢在某一个环节上进行度量。举个例子，ONES 曾经有一次测试部门效率优化，给出了一个非常漂亮的答卷，测试时间大量缩减。但放到全局分析后，才发现测试部门的效率虽然缩减了，但是研发和产品的效率却下降了。最终我们发现，整体的前置时间更长了，这无疑是一次令人沮丧的、失败的优化。度量的目标是优化，而非考核。如果度量的结果直接和考核结果挂钩，它或许对全体流程有优化，但优化的力度不会太大。
度量是为了帮助我们了解现在，确定未来的优化目标，并指引我们找到下一个优化点的。如果真需要数据考核，可以更多地关注数据的提升，而非单纯的数据量。