【VSM每周观点】偷走你时间的第一只“黑手”——在制品过多 ｜第2期

本文目录

正文

01 偷走时间的5只黑手

我们总是抱怨时间不够用，然而每个人每天都只有24小时，你是如何安排这24小时的呢？在每天24小时中，完成了哪些活动呢？你知道你的时间都去哪里了吗？

作者 多米尼加·德格朗迪斯在书籍 《将工作可视化：利用看板优化工作流动，并节约时间》中揭开了 偷走你时间5只黑手的真面目，他们分别是：

1. 在制品过多：在制品（WIP）也称为半成品，是指已经开始但未完成的工作，如：开发中、测试中和等待中的需求。
   

2. 未知的依赖关系：必须在任务完成前发生，但你却不知道完成该事项需要依赖哪些关系。

3. 计划外工作：妨碍你完成某事或导致你无法实现里程碑的干扰事项，如临时会议、紧急故障修复等。
   

4. 优先级冲突：相互竞争的项目和任务，当你不确定做什么事情是最重要的时候，就会加剧这种冲突。
   

5. 被忽视的工作：在完成了一部分后被晾在一边的工作，这些工作会导致过多的WIP和任务切换。当重要非紧急的工作长期被忽视时，这些工作在某一时间点就会变成紧急工作，典型的例子就是我们常说的“技术债”。

需要注意的是，这5只黑手之间是会相互影响的。例如，后面的4只黑手（未知的依赖关系、计划外工作、优先级冲突和被忽视的工作）都有可能造成过多的WIP。

02 WIP过多有什么不良影响

影响1: 价值延期交付，客户满意度下降

根据利特尔定律（Little‘s Law），任务完成的平均时间等于平均WIP数量除以平均吞吐量。这意味着当团队产能（也就是吞吐量）不变的情况下，WIP越多，工作完成的时间也就越长。这不难理解，想象下节假日的高速公路，同样一条高速路的吞吐量是有限的，当进入的车辆越多时，你通过的耗时也就越长。

在软件价值交付过程中，过多的正在进行中的需求，意味着更长的需求交付时间（即前置时间，Lead Time），客户需要等待更长的时间才能得到功能，客户满意度下降是必然的。

此外，在快速变化的数字化时代中，软件本身的价值会随着时间的推移而有所下降，这个时候我们还得考虑对延迟成本（CoD，Cost of Delay）的影响。延迟成本（CoD）是一个产品（机会点、项目）因为延迟而给组织带来的成本或是对收入的影响。对于软件产品或电子产品来说尤其明显，在今天价值10万元的产品在一年后也许只值1万。

影响2: 内容切换成为常态，影响工作效率

影响3: 影响员工情绪和阻碍创新

1. 存在瓶颈：过程中的瓶颈是造成WIP过多的主要原因之一。假设当编码阶段成为瓶颈时，那么将有更多的需求在排队等待开发；同理，当测试阶段成为瓶颈时，将有更多的功能在排队等待测试；这些需求和功能就成了在制品，随着时间的推移，累积的在制品也就越多。

2. 依赖过多：当你的工作或任务需要依赖第三方才能完成时，这就容易产生等待，进而产生过多的在制品。第一种情况是架构的依赖，假如A功能已经开发完成，但是无法独立部署、测试和发布，而是需要依赖B功能才能发布上线。另外一种情况是流程的依赖，假设B功能已经完成开发和测试了，但是在发布到生产环境之前需要等待变更委员会对本次发布进行评审和排期。

3. 临时任务：也称为计划外工作。临时的会议、新增的文档和紧急的需求均会导致计划内的工作延迟和等待，从而产生在制品。

限制和减少WIP的关键法则之一是将工作可视化、停止启动聚焦完成、有节奏频繁地交付最小业务增量，从而优化工作的流动。

第一步，将工作可视化

正所谓“你无法度量，就无法管理”。我们在减少和限制进行中的工作时，首先要做的是将当前的工作进行可视化。从可视化中发现在制品堆积在哪个环节，分析是由于什么原因导致的堆积。工作可视化的实践和方法有很多，比如价值流映射（Value Stream Mapping）和看板方法等。

正如我们在第1期的VSM每周观点谈到的，通过价值流映射练习绘制的价值流图可以提供直观的数据，包括每个环节处理中（下图中圆点图标）和等待中的数量（下图中三角形图标）和时间指标。

通过这些数据指标，我们很清晰地看到有15个需求在等待投产评审，为什么会有这么多需求的等待呢？或许是因为每2周才有一次的评审会议，既然如此，我们是否可以考虑更频繁的举行评审会议（比如：每周1次）呢？对于低风险的发布变更是否可以跳过评审会议这个环节呢？

唯有将工作可视化，通过定性或定量的数据发现问题所在的环节，方能“对症下药”。

第二步，停止启动，聚集完成

在日常生活中，当高速公路上堵得不行的时候，通常会暂停新的车辆进入高速，优先让高速公路上的车辆流动起来，否则只会加剧公路塞车的程度。

在软件价值交付过程也是如此，假设太多的需求在等待开发和测试中，此时我们就应该暂时停止接收新的需求，而将精力专注于当前工作的完成。

但是，这个实践很容易受到业务团队或需求提出方的挑战。

我们需要与业务或需求方更好的沟通协作，并建立一定的共识。在团队已经处于满负荷工作的状态下，接收更多的工作只会带来频繁的内容切换，进而导致更多的需求“堵塞”在价值交付过程的“高速公路”上，最终的结果是所有的需求都将停滞不前，陷入困境。

第三步，频繁地交付最小业务增量（MBI）

我们可以采用敏捷迭代式开发方法，在一个2-4周的迭代周期内专注于特定的需求的实现。同时，我们也要将需求拆分到合适大小，使其具备独立开发、独立测试、独立部署和独立发布。从而在一个迭代周期内交付最小业务增量（MBI）。

频繁地交付最小业务增量要求尽可能减少完成工作项的第三方依赖，包括架构层面依赖和流程层面的依赖。

通过对一个迭代周期团队能够完成的工作项数量，我们可以评估并承诺在接下来迭代周期能够完成的工作项数量。当经过一段时间的承诺都兑现时，与各个团队的信任关系也逐步建立起来。这个时候我们就可以和业务方一起，根据团队交付效率来平衡需求的输入和优先级的排序。