我引入看板系统的目标是：防止过载，控制流的波动性，以及触发渐进式变革。--看板方法的发明人David J. Anderson
一、为什么要映射价值流？
常踩的坑：很多企业一谈到提高研发效率，首先想到的是提高开发者的效率,于是在开发环节做了很多提升销量的工作，但是最终对产品交付效率的成效没有那么显著。
想提高开发者的效率没有错，但是首先需要思考的是：影响整个TTM(Time To Market：上市周期时间)的价值流动效率的关键因素是什么？真的是开发吗?要分析这个问题，需要对价值流做映射。
在大多数现实情况里，开发只占整个产品研制周期的一小部分。只关注开发者的效率相当于对系统做局部优化。价值流映射能够打开整个系统的价值流动过程，看到浪费和等待在哪里。
案例：图（1）是某互联网企业一个产品的价值流映射图，从一个创意提出来，到给用户上线的整个周期的价值流动过程，如图（1）所示。
图（1）价值流映射示例
图（1）所描绘的价值流动过程是：
一个需求由市场人员收集上来，经过10天后产品经理终于有时间开始分析需求。产品经理花了1天分析后，决定上报到产品管理组评议；
等待5天后，产品管理组召开评审会议，需求评审通过；
UED（User Experience Designer:用户体验设计师）花了3天时间做完了原型设计，设计稿提交给产品管理组评审；
等待3天后，原型设计评审会议召开，评审通过。但是还不能开始开发，因为开发工程师在忙着做其他的需求。所以，这个需求只能放在产品Backlog（待办事项列表）里排队；
等待15天后，前台开发工程师开始开发，花了8天时间开发完前端页面。但是还不能上线，因为后端还没有提供接口。
等待3天后，后端接口开发完成。又花了2天做前后端联调和自测试；
但是还不能上线，因为需要第三方组件，等待5天后第三方组件到位；又花了2天与第三方组件集成联调，然后花了5天做系统验证；
系统验证发现了缺陷，于是花了5天修复缺陷。最后，花了1天时间将产品发布上线。
因此，这个需求的研制周期共花了64天，而其中只有22天在从事价值产出活动，在精益里称为“增值活动”，其他的42天或者在等待下一步工作的开始，或者修复缺陷，并没有价值产出，在精益里称为“非增值活动”。
由此可以看出，价值流图是一个简单有效的工具，能够帮助团队形成以价值的视角来观察和思考流程，分析价值流动过程的每个增值和不增值的环节。那么如何衡量价值流动的快慢呢？用流动效率来度量，计算方法如下：
其中，增值活动时间由需求在价值流动过程中所有增值活动所耗费的时间之和计算得来；非增值活动时间由需求在价值流动过程中所有非增值活动所耗费的时间累计得到。周期时间，是从需求提出到发布给客户或用户为止的整个过程所耗费的时间，也就是增值活动与非增值活动时间的总和。通过流动效率，可以计算出团队的增值活动时间占比情况，从而判断价值流中的浪费情况。
对于图（1）的互联网项目，其价值流动效率为：
团队按照这样的价值流动效率工作，花了整整68天的周期时间(Lead Time)，其中开发占用了8天的时间，加上需求分析和联调等活动，增值活动时间总共22天，46天时间耗费在等待中。因此，很多团队只关注提升开发环节的效率是远远不够的，必须关注全价值流的效率。对于客户或用户而言，他们最关注的是需求的周期时间（Lead Time）越短越好。那么如何缩短期时间(Lead Time)呢？依据公式：
要缩短周期时间可以分两步走：
第一步：通过流程改进、组织调整等手段，减少等待、交接等非增值活动的时间。比如6.1节介绍的，组建跨职能团队。
第二步：在第1步的基础上，提高团队的工作效率，减少增值活动时间。比如，导入工程实践以提升团队的开发、测试和运维效率。
常见疑惑：价值流映射对团队有什么起点要求吗？
答：没有什么要求。任何团队只要存在，就已经在围绕着价值流工作，不论团队映射后的价值流是敏捷模式还是瀑布模式。经常听到团队说，“我们没有什么价值流啊。”其实团队想表达的是：“我们没有显式的、大家共识的价值流。”
二、怎么做价值流映射？
团队的价值流，应由团队成员共同识别并达成共识。因此，映射价值流一般需要召开一个工作坊，如图（2）是某团队价值流映射的现场，由团队面对面讨论，共同完成价值流映射。为了提高效率，也可以由团队的一个成员在线下根据自己对团队价值流的理解画出草稿，带到工作坊上，然后团队讨论这个草稿是否与大家理解得一致。最终定稿的价值流应该是每个成员都认可的。
