独家图解：用看板玩转约束理论，识别和管理瓶颈

如何用看板方法识别和管理瓶颈，从而提升组织和团队的效能？本文为你揭开约束理论神秘的面纱，独家图解在看板里如何应用约束理论。

~~晕，用最少的笔墨，既要讲圆一个理论，而且要落地到具体实践，并且反复具栗子，吐血啦~~

先唠叨几句：约束理论到底是啥玩意？

以色列物理学家高德拉特博士（Dr.Eliyahu M.Goldratt）创始了约束理论（Theory of Constraints，TOC）。基本思想是：

限制系统实现企业目标的因素并不是系统的全部资源，而仅仅是其中某些被称之为“约束”的个别资源。

具体点：系统中的每一件事都不是孤立存在的，一个组织的行为由于自身或外界的作用而发生变化，尽管有许多相互关联的原因，但总存在一个最关键的因素。找出制约系统的关键因素加以解决，起到事半功倍的作用。

管理的艺术就在于发现并转化这些约束，或使它们发挥最大效能。

约束理论是一种帮助找出和改进瓶颈，使系统（系统可以是项目、组织、企业）效能最大化的管理哲理，是事半功倍的管理哲理。

那么“约束”是个啥？

TOC认为，对于任何一个由多个过程构成的系统，整个系统的产出水平是由其中产出率最低的环节所决定的。这些环节就是约束。“约束”是一个广义的概念，通常也称作“瓶颈”（Bottleneck）。

用一句话概况：高德拉特的著作《目标》中有这样的比喻：一个链条的承载能力是由它最薄弱的环节来决定的。

约束理论的五步法

约束理论（TOC）有五大核心步骤(Five Focusing Steps) 来识别约束，提升系统的效能，这五个步骤具有普适性，是一种思考和持续改善的流程，适合任何行业（注：包括咱们IT行业哦）。这五大核心步骤是(有众多翻译版本，笔者喜欢自己的这一版)：

Identify the system's constraint(s). 识别约束（瓶颈）

Decide how to exploit the system's constraint(s). 决定如何最大化利用约束（瓶颈）资源。

通俗点就是：
将瓶颈用到极致！

Subordinate everything else to the above decision(s).所有其他活动服从于第二步的各种措施。

说得透彻点就是：
其他环节利益服从瓶颈的利益！

Elevate the system's constraint(s)。

提升约束（瓶颈）的效能

Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint. 如果约束（瓶颈）已经突破，回到步骤1，别让惰性成为约束，持续不断地改善！

约束理论五步法听起来这么美妙，为啥在IT行业没有普遍应用？

笔者认为，因为抽象，大家不懂。此外，高德拉特大师也没有讲解过在我们这样的行业具体怎么玩。幸运的是，看板方法提供了承载的手段。笔者结合自己的经验，给大家讲解一下，如何用看板识别系统瓶颈，提升团队效能？

看板如何运用约束理论五步法

第1步：识别瓶颈

栗子：

如下图，你能看出瓶颈在哪里吗？

目视，测试环节貌似工作很多，感觉测试是瓶颈。但是还不足以下结论。

只有把每个环节精细可视化，看出这些堆积的工作到底是正在进行中，还是已经完成而是由于下游没有人力拉动。所以看板里的每个环节都细化为进行中、完成两列。像下图：

记住，判断瓶颈的秘诀：上游堆积，下游饥饿。

如上图，大量工作堆积在Review Ready，等待测试开始。而测试Done这一列没有卡片; Accept列只有一个卡片，因为大部分没有流入Accept。从而，可以判断测试环节为整个价值流的瓶颈。

第2步：将瓶颈用到极致

识别瓶颈后，我们常规的习惯是提升瓶颈的效率，比如，追加投入，加人，加设备资源等，或者像咱们苦逼伟大的IT行业，没人没资源，那就只好让瓶颈资源加班啦！于是你就会发现，团队里有的的同事永远是加班最多的人，好像这是由他们的工作性质决定的。

约束理论是反直觉的。识别出瓶颈后，不应该马上尝试提升瓶颈的效率，而是最大化利用瓶颈资源，即：将瓶颈用到极致。比如，上图已经识别出测试环节是瓶颈，不是马上调配更多的测试人员，而是可以从这几方面下手：

让瓶颈资源保持繁忙，上游队列一直有任务流向瓶颈。
对于上图看板的情况，保持Review Ready有卡片时刻准备好，等待测试人员随时拉入到测试中。如何做到这一点？Small batch, small batch, small batch, 重要的事情说三遍！对软件开发来说，将需求拆小，拆小，再拆小！要不断给瓶颈准备好食物。

减少或消除对瓶颈资源的打扰，减少瓶颈的非增值活动
对于上图看板，团队要努力让测试人员聚焦。

栗子：

比如，各种不必要的会议，不需要让测试工程师参加，确保他们手里的工作项在处理中。

再比如，观察测试工程师的工具环境，是否需要他们做上下文切换、重复做测试环境的准备等浪费性的工作。要瓶颈不停地做增值性活动。

解决影响瓶颈资源工作的阻碍，不让瓶颈资源等待
每天早会上，团队审视看板，如果出现多处阻碍，要优先解决瓶颈环节的阻碍，不要让工作项在瓶颈环节停滞，因为瓶颈决定了整个系统的效率。

排优先级，保证瓶颈资源时刻在处理最重要的工作项，并且使上游任务均匀流入瓶颈。
在很多团队，笔者发现看板上的工作项优先级不清晰。问起团队，大家说，在团队Leader的脑袋里。如果瓶颈在做低优先级的工作项，这影响着整个系统里高优先级工作项的效率。

此外，要避免将工作项以小瀑布的方式推送给瓶颈，让瓶颈保持稳定的节奏处理工作项。均匀、稳定的输入是确保均匀、稳定的产出的前提。

第3步：其他环节利益服从瓶颈的利益

具体说，可以从以下几方面着手：

系统其他部分支持对瓶颈的保护，实现瓶颈资源最大化利用
栗子：

笔者曾经在一家通信企业做咨询，团队的测试人员人力配置不足：7个开发，1个测试，而且几乎没有测试自动化。同时团队共享硬件资源，于是经常产生资源竞争的情况。开发工程师经常为了解bug, 在测试工程师正在使用硬件的时候将硬件拿走。如果测试环节已经是瓶颈，那么开发工程师的产出再多，也会堆积在测试环节之前无法启动。

系统的其他部分，支持局部效率优化服从于瓶颈效率优化的原则。
栗子：

拿刚才举例的团队来说，测试人员配置不足是个已知的问题，能否尝试将一些测试工作前移，比如开发人员做一些代码和模块级甚至story级的测试，而测试工程师专注做系统级的验证？

质量内建，使流入瓶颈的工作输入量最小化。
拿刚才举例的团队来说，在测试已经成为瓶颈的情况下，代码质量又差，简直是屋漏又遭连夜雨，造成不断有阻测的bug产生，导致测试人员不停地返工测试，无形中让瓶颈的工作输入量加倍。

限制在制品数量，减少浪费。
栗子：

在步骤1的看板里，各个环节都没有限制在制品(WIP)，导致每个环节都无限地堆积工作项。如果采取了下图的做法，首先在瓶颈环节限制在制品(WIP)，从而立竿见影，为瓶颈起到了保护作用。

但是，这还不够，因为瓶颈的上游Review环节会继续堆积在制品。因此，需要给上游Review环节、上游的上游Coding、一直到上游的上游的上游Aanalysis&Plan环节都限制在制品（WIP），才能确保每个环节不会堆积，做到缩短反馈环，减少浪费，缩短交付周期时间（Lead Time）.

于是，如下图才是正确的看板：