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

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

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

以色列物理学家高德拉特博士（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）.

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

第4步：提升瓶颈的效能

做了2-3步，应该对瓶颈环节的负担缓解了很多。这时才开始考虑提升瓶颈本身的效能。有以下几个方向可供参考：

非瓶颈资源跨职能，帮助瓶颈

比如，团队的每个人都有一个主要职责，同时开发人员可以做测试，测试人员也可以做一些开发工作。当测试成为瓶颈的时候，开发人员也认领测试任务，大家共同努力让工作项流动下去，而不是开发人员只顾把代码丢给测试。

增加瓶颈资源

这就是常说的，加人，加硬件资源等。

但是要注意的是平衡各环节的人力，否则可能会直接引入了新的瓶颈。

自动化瓶颈工作

这是个长期的必须要投资的工作，否则玩转敏捷开发只是个梦想。

第5步：如果瓶颈已经突破，回到步骤1，别让惰性成为约束！

做了以上步骤后，回到第1步，再次审视看板，重新识别瓶颈。就像一根链条一样，加强了其中最薄弱的一环，但又会有下一环成为最薄弱的，因此 约束理论是个持续改善环！

最后，不得不提起一个神话。

想起Frederick P. Brooks. Jr. 1975年的著作《人月神话》里的经典观点：给一个已经延期的项目投入人力，会让这个项目更延期。想提升组织的效能，需要运用像约束理论等系统的方法，而不是盲目开枪，哪有敌人打哪。

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

约束理论的五步法