精益产品开发︱为什么要映射价值流及其实践应用

对于几十人甚至上百人的大型产品线，将所有人集中到一起做价值流映射是开销很大，也不现实，因此可以选择价值流的不同环节的相关代表，这些代表对自己所参与的环节比较熟悉。比如，测试经理可以带上一名测试工程师代表测试团队来参加价值流映射，介绍测试环节在整个产品价值流中的运作方式，以及与上、下游的衔接方式。
 
无论是哪种情况，价值流需要反映真实的价值流动过程，因为价值流映射是全团队共创的活动，不是由个别人凭借自己的猜测和理解绘制出的。在这个过程中，大家可能会惊讶每个人对工作流程的理解差异之大。具体来说怎么来做呢？在精益生产里，鉴于生产系统本身的特点，经常采用比较复杂的符号和工具来映射价值流。在知识工作领域，价值流映射要简单得多，只需要四个步骤：

1.分析工作项的类型：
工作项指的是交付价值的单元。不同类型的工作项其价值流动过程很可能不同。比如图（1）中以需求为单元绘制了价值流，如果是以一个线上缺陷为单元绘制价值流，会经历与需求不同的流动过程。比如，大部分的线上缺陷不需要经过需求评审和用户体验设计，一般也不需要在产品Backlog里等待15天。在这一步需要遵循的原则是：价值流映射的单元是价值，即：从客户的视角思考，什么东西对他有价值，什么东西对他没有价值。典型的映射单元是产品的特性，因为每个交付特性都为客户或用户提供价值。
 
那么线上缺陷是否对客户有价值呢？应该说，线上缺陷给客户产生的是负向价值，即：如果不修复，或修复周期长，会让客户不满意，甚至产生经济损失。因此线上缺陷也可以做价值流映射。但是有些工作不应该做价值流映射，典型的是技术实现任务，比如前端开发、后端数据表等，这类任务属于特性开发中的技术任务，对客户不直接产生价值。

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

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