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

2021-06-10 09:00:00
敏捷助理
原创
1315
摘要:限制系统实现企业目标的因素并不是系统的全部资源,而仅仅是其中某些被称之为“约束”的个别资源。

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


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

先唠叨几句:约束理论到底是啥玩意?

以色列物理学家高德拉特博士(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年的著作《人月神话》里的经典观点:给一个已经延期的项目投入人力,会让这个项目更延期。想提升组织的效能,需要运用像约束理论等系统的方法,而不是盲目开枪,哪有敌人打哪。
联系我们
联系人: 田老师
电话: +86 135 5227 9573
Email: clientservice@hardenx.cn
地址: 北京市朝阳区福码大厦B座17层1705

加微领1G资料