看板加速价值流动之为什么要映射价值流

    一、为什么要映射价值流？

    常踩的坑：很多企业一谈到提高研发效率，首先想到的是提高开发者的效率,于是在开发环节做了很多提升销量的工作，但是最终对产品交付效率的成效没有那么显著。

想提高开发者的效率没有错，但是首先需要思考的是：影响整个TTM(Time To Market：上市周期时间)的价值流动效率的关键因素是什么？真的是开发吗?要分析这个问题，需要对价值流做映射。

       在大多数现实情况里，开发只占整个产品研制周期的一小部分。只关注开发者的效率相当于对系统做局部优化。价值流映射能够打开整个系统的价值流动过程，看到浪费和等待在哪里。

       C案例：

       下图是某互联网企业一个产品的价值流映射图，从一个创意提出来，到给用户上线的整个周期的价值流动过程，如图所示。

价值流映射示例

上图所描绘的价值流动过程是：

• 一个需求由市场人员收集上来，经过10天后产品经理终于有时间开始分析需求。产品经理花了1天分析后，决定上报到产品管理组评议；
  
• 等待5天后，产品管理组召开评审会议，需求评审通过； UED（User Experience Designer:用户体验设计师）花了3天时间做完了原型设计，设计稿提交给产品管理组评审；
• 等待3天后，原型设计评审会议召开，评审通过。但是还不能开始开发，因为开发工程师在忙着做其他的需求。所以，这个需求只能放在产品Backlog（待办事项列表）里排队；
• 等待15天后，前台开发工程师开始开发，花了8天时间开发完前端页面。但是还不能上线，因为后端还没有提供接口。
• 等待3天后，后端接口开发完成。又花了2天做前后端联调和自测试；
• 但是还不能上线，因为需要第三方组件，等待5天后第三方组件到位；又花了2天与第三方组件集成联调，然后花了5天做系统验证；
• 系统验证发现了缺陷，于是花了5天修复缺陷。最后，花了1天时间将产品发布上线。

 因此，这个需求的研制周期共花了64天，而其中只有22天在从事价值产出活动，在精益里称为“增值活动”，其他的42天或者在等待下一步工作的开始，或者修复缺陷，并没有价值产出，在精益里称为“非增值活动”。

 由此可以看出，价值流图是一个简单有效的工具，能够帮助团队形成以价值的视角来观察和思考流程，分析价值流动过程的每个增值和不增值的环节。那么如何衡量价值流动的快慢呢？用流动效率来度量，计算方法如下：

         其中，增值活动时间由需求在价值流动过程中所有增值活动所耗费的时间之和计算得来；非增值活动时间由需求在价值流动过程中所有非增值活动所耗费的时间累计得到。周期时间，是从需求提出到发布给客户或用户为止的整个过程所耗费的时间，也就是增值活动与非增值活动时间的总和。

通过流动效率，可以计算出团队的增值活动时间占比情况，从而判断价值流中的浪费情况。对于价值流映射示例图的互联网项目，其价值流动效率为：

团队按照这样的价值流动效率工作，花了整整68天的周期时间(Lead Time)，其中开发占用了8天的时间，加上需求分析和联调等活动，增值活动时间总共22天，46天时间耗费在等待中。因此，很多团队只关注提升开发环节的效率是远远不够的，必须关注全价值流的效率。

对于客户或用户而言，他们最关注的是需求的周期时间（Lead Time）越短越好。那么如何缩短期时间(Lead Time)呢？

依据公式：

要缩短周期时间可以分两步走：

第1步：通过流程改进、组织调整等手段，减少等待、交接等非增值活动的时间。比如6.1节介绍的，组建跨职能团队。

第2步：在第1步的基础上，提高团队的工作效率，减少增值活动时间。比如，导入工程实践以提升团队的开发、测试和运维效率。

    常见疑惑：价值流映射对团队有什么起点要求吗？

   答：没有什么要求。任何团队只要存在，就已经在围绕着价值流工作，不论团队映射后的价值流是敏捷模式还是瀑布模式。经常听到团队说，“我们没有什么价值流啊。”其实团队想表达的是：“我们没有显式的、大家共识的价值流。”

        二、怎么做价值流映射？

团队的价值流，应由团队成员共同识别并达成共识。因此，映射价值流一般需要召开一个工作坊，如图7-2某团队价值流映射的现场，由团队面对面讨论，共同完成价值流映射。为了提高效率，也可以由团队的一个成员在线下根据自己对团队价值流的理解画出草稿，带到工作坊上，然后团队讨论这个草稿是否与大家理解得一致。最终定稿的价值流应该是每个成员都认可的。

价值流由团队协作绘制

对于几十人甚至上百人的大型产品线，将所有人集中到一起做价值流映射是开销很大，也不现实，因此可以选择价值流的不同环节的相关代表，这些代表对自己所参与的环节比较熟悉。比如，测试经理可以带上一名测试工程师代表测试团队来参加价值流映射，介绍测试环节在整个产品价值流中的运作方式，以及与上、下游的衔接方式。

无论是哪种情况，价值流需要反映真实的价值流动过程，因为价值流映射是全团队共创的活动，不是由个别人凭借自己的猜测和理解绘制出的。在这个过程中，大家可能会惊讶每个人对工作流程的理解差异之大。

具体来说怎么来做呢？在精益生产里，鉴于生产系统本身的特点，经常采用比较复杂的符号和工具来映射价值流。在知识工作领域，价值流映射要简单得多，只需要四个步骤：

        第1步：分析工作项的类型

工作项指的是交付价值的单元。不同类型的工作项其价值流动过程很可能不同。比如图7-1中以需求为单元绘制了价值流，如果是以一个线上缺陷为单元绘制价值流，会经历与需求不同的流动过程。比如，大部分的线上缺陷不需要经过需求评审和用户体验设计，一般也不需要在产品Backlog里等待15天。

在这一步需要遵循的原则是：价值流映射的单元是价值，即：从客户的视角思考，什么东西对他有价值，什么东西对他没有价值。典型的映射单元是产品的特性，因为每个交付特性都为客户或用户提供价值。

那么线上缺陷是否对客户有价值呢？应该说，线上缺陷给客户产生的是负向价值，即：如果不修复，或修复周期长，会让客户不满意，甚至产生经济损失。因此线上缺陷也可以做价值流映射。但是有些工作不应该做价值流映射，典型的是技术实现任务，比如前端开发、后端数据表等，这类任务属于特性开发中的技术任务，对客户不直接产生价值。

        第2步：对选定的工作项类型，列出工作项从诞生到交付给客户或用户的整个过程中都经过了哪些环节。这一步需要遵循两个原则：

1.工作项的环节需要反映价值流的主体活动
所谓主体活动，指的是分析、设计、测试脚本开发、编码、测试、验收等等。要以价值流的活动为中心，而不是以人的角色为中心做价值流映射。比如，测试工程师在测试过程中发现了缺陷后，将缺陷传递给开发工程师修复，这时价值流的主体活动仍旧是测试，而不是开发，虽然开发工程师在解决缺陷。
此外，软件开发过程不是像工厂的流水线那样串行的活动，而是不断迭代的过程，因此，一些活动的并行和重叠是正常的。比如，开发工程师在编码的过程中可能会发现接口的设计有遗漏，找架构师提供接口设计，这时价值流的主体活动仍旧是编码，而不是设计。
2. 价值流映射要绘制出团队的真实价值流，而不是期望的目标价值流。
如果团队不知道现在是如何工作的，就无法判断从哪里下手优化价值流。映射价值流的目的是清晰地理解现在的工作流程和价值流动效率，而不是改进。不管当前的价值流是多么的混乱不堪，浪费多么多，流动效率多么低，也要保持真实。
 第3步：分析哪些环节是增值环节，哪些是不增值环节
推荐一个经验：凡是那些“等待”的环节都是不增值环节。比如：等待评审会议举行，等待环境就绪，等待人力分配，等待接口联调等等。
 第4步：估算每个环节的耗时
虽然现在还没有用度量工具系统采集数据，但是每个环节的耗时也可以根据团队对日常工作的经验来估算，即使估算得未必精确，由于这是价值流各环节的参与者依据实际的工作经验共同做出的估算，因此相对准确，能够达到分析的目的。
价值流映射完毕后，绘制效果如图，达到如下目的：
1.让团队对产品真实的价值流达成共同的认识和理解。
2. 让团队对浪费环节有了明确的理解，对价值流动效率有了量化认识，作为驱动改进的起点。
3.为下一步设计看板系统提供了输入。
如果企业不导入看板方法，只是将价值流图作为工具来识别和减少过程中的浪费, 那么下一步是设计目标状态的价值流图，并做出从现在的状态达到目标状态的行动计划。如果是在现有的价值流状态下导入看板方法，则不需要设计目标状态，而是将现有的价值流呈现在看板上，根据看板暴露的问题有针对性地改进。