团队的价值流，应由团队成员共同识别并达成共识，这一过程一般需要在一个工作坊进行，由团队面对面讨论，共同完成价值流映射。为了提高效率，团队成员也可以在线下根据自己对团队价值流的理解画出草稿，带到工作坊，然后团队成员就草稿内容相互讨论。最终定稿的价值流应该是每个成员都认可的。

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

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

在精益生产过程中，鉴于生产系统本身的特点，团队经常采用比较复杂的符号和工具来映射价值流。而在知识工作领域，价值流映射要简单得多，只需如下四个步骤。

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

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

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

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

第二步：列出选定工作项从诞生到交付的各个环节

这一步需要遵循以下两个原则。

• 工作项的环节需要反映价值流的主体活动。所谓主体活动，指的是分析、设计、测试脚本开发、编码、测试、验收等。做价值流映射要以价值流的活动为中心，而不是以人的角色为中心。比如，测试工程师在测试过程中发现了缺陷后，将缺陷传递给开发工程师修复，这时价值流的主体活动仍旧是测试，而不是开发，即使是开发工程师在解决缺陷问题。此外，软件开发过程不是像工厂的流水线那样串行的活动，而是不断迭代的过程，因此，一些活动的并行和重叠是正常的。比如，开发工程师在编码的过程中可能会发现接口设计内容有遗漏，于是找架构师提供接口设计，这时价值流的主体活动仍旧是编码，而不是设计。
• 价值流映射要体现出团队的真实价值流，而不是团队期望的目标价值流。如果团队不知道现在是如何工作的，就无法判断从哪里下手优化价值流。映射价值流的目的是清晰地理解现在的工作流程和价值流动效率。不管当前的价值流是多么的混乱不堪，浪费多么多，流动效率多么低，也要保持真实性。
  

第三步：分析哪些环节是增值环节，哪些是非增值环节

凡是那些“等待”的环节都是非增值环节。比如，等待评审会议举行，等待环境就绪，等待人力分配，等待接口联调，等等。

第四步：估算每个环节的耗时

虽然现在团队还没有用度量工具系统采集数据，但是可以根据团队日常的工作经验来估算每个环节的耗时。虽然估值未必精确，但是相对准确，能够达到分析的目的。

第五步：将以上步骤的分析结果绘制成价值流图（如图7-1所示）

通过价值流图，可以达到以下目的：

• 让团队对产品真实的价值流达成共同的认识和理解；
• 让团队对浪费环节有明确的理解，对价值流动效率有量化认识，并将其作为驱动改进的起点；
• 为下一步设计看板系统提供输入。
  

如果团队不导入看板方法，只是将价值流图作为工具来识别和减少过程中的浪费，那么下一步就是设计目标状态的价值流图，并做出从现在的状态到目标状态的行动计划。如果团队是在现有的价值流状态下导入看板方法，则不需要设计目标状态，而是将现有的价值流呈现在看板上，根据看板暴露的问题有针对性地改进。

团队的价值流，应由团队成员共同识别并达成共识，这一过程一般需要在一个工作坊进行，由团队面对面讨论，共同完成价值流映射。为了提高效率，团队成员也可以在线下根据自己对团队价值流的理解画出草稿，带到工作坊，然后团队成员就草稿内容相互讨论。最终定稿的价值流应该是每个成员都认可的。

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

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

在精益生产过程中，鉴于生产系统本身的特点，团队经常采用比较复杂的符号和工具来映射价值流。而在知识工作领域，价值流映射要简单得多，只需如下四个步骤。

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

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

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

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

第二步：列出选定工作项从诞生到交付的各个环节

这一步需要遵循以下两个原则。

• 工作项的环节需要反映价值流的主体活动。所谓主体活动，指的是分析、设计、测试脚本开发、编码、测试、验收等。做价值流映射要以价值流的活动为中心，而不是以人的角色为中心。比如，测试工程师在测试过程中发现了缺陷后，将缺陷传递给开发工程师修复，这时价值流的主体活动仍旧是测试，而不是开发，即使是开发工程师在解决缺陷问题。此外，软件开发过程不是像工厂的流水线那样串行的活动，而是不断迭代的过程，因此，一些活动的并行和重叠是正常的。比如，开发工程师在编码的过程中可能会发现接口设计内容有遗漏，于是找架构师提供接口设计，这时价值流的主体活动仍旧是编码，而不是设计。
• 价值流映射要体现出团队的真实价值流，而不是团队期望的目标价值流。如果团队不知道现在是如何工作的，就无法判断从哪里下手优化价值流。映射价值流的目的是清晰地理解现在的工作流程和价值流动效率。不管当前的价值流是多么的混乱不堪，浪费多么多，流动效率多么低，也要保持真实性。
  

第三步：分析哪些环节是增值环节，哪些是非增值环节

凡是那些“等待”的环节都是非增值环节。比如，等待评审会议举行，等待环境就绪，等待人力分配，等待接口联调，等等。

第四步：估算每个环节的耗时

虽然现在团队还没有用度量工具系统采集数据，但是可以根据团队日常的工作经验来估算每个环节的耗时。虽然估值未必精确，但是相对准确，能够达到分析的目的。

第五步：将以上步骤的分析结果绘制成价值流图（如图7-1所示）

通过价值流图，可以达到以下目的：

• 让团队对产品真实的价值流达成共同的认识和理解；
• 让团队对浪费环节有明确的理解，对价值流动效率有量化认识，并将其作为驱动改进的起点；
• 为下一步设计看板系统提供输入。
  

如果团队不导入看板方法，只是将价值流图作为工具来识别和减少过程中的浪费，那么下一步就是设计目标状态的价值流图，并做出从现在的状态到目标状态的行动计划。如果团队是在现有的价值流状态下导入看板方法，则不需要设计目标状态，而是将现有的价值流呈现在看板上，根据看板暴露的问题有针对性地改进。