运用约束理论消除瓶颈的两种方法

在实际情况下应用约束理论可能很难,但有两种简单的方法可以启动该过程。

译自2 Ways to Reduce Bottlenecks with the Theory of Constraints,作者 Steve Fenton 是Octopus Deploy的Octonaut,DORA社区指导,拥有20多年软件交付经验的六届Microsoft MVP。他撰写了有关TypeScript(Apress、InfoQ)、Octopus Deploy和网络操作的书籍......

一条链条的强度取决于它最弱的环节。这就是约束理论的核心思想。只要有几个弱环节,任何系统都会受到限制,但是通过专注于改进这些环节,可以提高整个系统的性能。

无论是软件交付流程、大型生产线还是家务,改进整个系统的唯一方法就是从瓶颈着手。

约束理论在理论上很棒

学习约束理论有两种方式。你可以阅读埃利亚胡·戈德拉特(Eliyahu Goldratt)的商业小说《目标(The Goal,)》,或者阅读配套的手册《约束理论(Theory of Constraints)》。

两者都解释了应用该理论时所采用的一系列关注步骤。

  1. 识别系统的约束点。
  2. 决定如何利用约束点。
  3. 使其他一切服从这一决定。
  4. 提升约束点。
  5. 如果约束点得到释放,返回第一步。

该理论适用范围广泛。它可以应用于任何系统,例如工厂中的生产线、管理软件交付或者一群童子军试图携带装备徒步到达目的地。由于这个原因,语言可能对你的实际情况有点抽象。

具体来说,"利用"、"服从"和"提升"这些术语可能不太清楚。

让我们稍微简化一下语言,然后看看两种实际的方法,将约束理论应用于你的工作。

利用、服从和提升

约束理论中的"约束"本质上就是瓶颈。你正在努力完成工作以获得某种价值,其中涉及许多步骤,可能也涉及许多人。如果仔细观察这一工作流程,你会发现存在一个阶段,工作会在那里堵塞。

你可能在制造计算机,显卡工作站前堆积着许多几乎完成的产品,等待有人安装显卡。好吧,显卡阶段就是你的瓶颈或约束点。

得益于堆积在显卡工作站前的计算机,你可以注意到这个问题,但你也会注意到约束点之后的工作站由于缺乏工作而闲置,而约束点之前的工作站生产了更多的笔记本电脑,只会增加队列的大小。

如果你的工作不太容易看到,像看板(Kanban)这样的可视化系统可以向你展示问题。看到工作项在特定任务前的队列中堵塞,这表明这里存在瓶颈。

当你可以看到这个瓶颈时,你就可以应用三个神秘的术语了。

你可以通过现有的人员和资源来改进约束点,以此来"利用"它。如果你可以转移某人到约束点工作,你的整体产出(完成的笔记本电脑、软件功能或干净的衣服)将增加。

然后你要使其他所有事情的节奏服从约束点。这意味着将上游过程的速度设置为与瓶颈阶段的速度相匹配。如果你一天可以组装10块显卡到笔记本电脑中,那么你一天只能组装10台笔记本电脑。从开始到结束的所有流程都以具有瓶颈的阶段的节奏运行。

一旦系统以匹配的速度运行后,你就要考虑提升约束点的方法。也就是找到方法使日产量从10块显卡提升至多于10块。假设你没有用现有的人员和资源来提升约束点,你需要衡量增加产量的成本和收益。如果你使团队规模增加一倍或引入工具以支持该过程将日产量提高至20块显卡,你将投资多少来获得额外的销售?

在约束点移动之前,你要继续应用这一三阶段流程。例如,你每天生产20块显卡,而每天只卖出18台笔记本电脑。现在你要将这些关注步骤应用于销售阶段。

这一理论可以应用于物理工作或知识工作。工作就像水流经一条有许多水闸的运河。你不能允许上游的水淹没下游,也不能允许运河的一段干枯。

让我们看看两种在现实生活中应用这些关注步骤的实际方法。

从正确的方向开始

在软件开发中,工作通常在任务板上可视化,随着工作从左至右的流动而展示。任务板上的列表示队列和工作阶段,例如"等待测试"和"正在测试"。

要应用约束理论,首先确保任务板准确地表示了你的流程中的每一个交付和队列。一旦你已经表示了工作的真实流动,任务板就会快速向你显示瓶颈所在。

你可以对瓶颈应用关注步骤,但对跨职能团队来说有一个更简单的选择。始终先处理最右边的工作项。如果一个功能已准备好部署到生产环境,在测试左边的功能之前先部署这个功能。

通过始终推进最接近完成的工作,你可以毫不费力地实现"利用"和"服从"关注步骤。你的跨职能团队是自我调节的,即使对动态瓶颈也是如此。系统的速度是自动的,团队会灵活地将时间投入到需要他们注意的任务上。

使用这种方法时,你只需确保改进过程中不会产生惰性。你不会有一堆工作来告诉你需要改进什么,所以你需要注意哪些任务必须改进------或者在约束理论术语中"提升"。

有时候,这种方法的简单性正是它如此强大的原因。

按照瓶颈安排

如果你没有跨职能团队,你可以按照瓶颈安排。例如,如果你有一个独立的测试团队,你应该只以他们可以测试的速度生产功能,而不增加队列的大小。

这就是为你的任务板添加在制品限制(WIP)可以提供帮助的地方。最重要的WIP限制是约束点前队列的限制,但你可能需要在约束点左侧的其他列添加限制。你不需要在瓶颈之后添加限制;如果你发现自己在右侧添加WIP限制,这意味着你的约束点已经移动了。

当你按照瓶颈安排时,理想情况下,你想在约束点刚需要下一个任务时为他们提供工作。然而,大多数团队使用缓冲区,以确保瓶颈永远不会闲置。

与从右边开始相比,按照瓶颈安排需要更多的努力。然而,它的一个优点是可以非常清楚地强调约束点。团队中没有人对于应该把改进工作集中在哪里有任何疑问。

强大的"啊哈"时刻

约束理论之所以具有如此大的影响,是因为它强调了你做的所有高于瓶颈所能处理的工作都是浪费的。在笔记本电脑的例子中,如果你不能用显卡完成组装,你生产的任何数量的笔记本电脑对你可以销售的数量都没有影响。

答案可以简单地把某人从组装转移到显卡安装,或者你可能需要更好的工具来支持流程中的这个阶段。约束理论会引导你走上正确的道路,并提供具体的动机来改进正确的事情。

本文在云云众生yylives.cc/)首发,欢迎大家访问。

相关推荐
心灵彼岸-诗和远方8 小时前
DevOps工程技术价值流:制品库Nexus与Harbor的实战探索
运维·devops
bigdata-余建新8 小时前
SRE 与 DevOps记录
运维·devops
魔幻云1 天前
终章:DevOps实践总结报告
devops
catmes3 天前
使用docker compose安装gitlab
运维·docker·容器·gitlab·敏捷开发·devops
ccnnlxc3 天前
git使用和gitlab部署
devops
编码浪子4 天前
devops和ICCID简介
运维·ci/cd·docker·devops
明明跟你说过4 天前
在Rocky Linux中安装【Jenkins】的详细指南
linux·运维·服务器·ci/cd·jenkins·devops
Anna_Tong5 天前
探索 CI/CD 工具的力量
ci/cd·开源·jenkins·开源软件·devops
码者无疆6 天前
Centos7下Kanass安装部署指南
开源·devops
极小狐7 天前
极狐GitLab 正式发布安全补丁版本 17.6.2、17.5.4、 17.4.6
gitlab·devsecops·devops·极狐gitlab·安全合规