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

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

译自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/)首发,欢迎大家访问。

相关推荐
XMYX-02 天前
深入理解 DevOps:从理念到实践
运维·devops
cronaldo912 天前
研发效能DevOps: Vite 使用 Axios 实现数据双向绑定
vue.js·vue·devops
联蔚盘云2 天前
阿里云 DevOps 资源安全扫描实践
安全·阿里云·devops
落非2 天前
kubesphere问题处理:devops
运维·devops
东方不败之鸭梨的测试笔记3 天前
如何建立devops?
java·运维·devops
运维&陈同学3 天前
【第三章】Python基础之元组tuple
linux·开发语言·python·运维开发·devops
思码逸研发效能3 天前
如何通过对敏捷实践的调整,帮助远程团队提升研发效能?
研发效能·敏捷开发·devops·敏捷流程·研发效能度量
霍格沃兹测试开发学社测试人社区4 天前
深入了解测试开发与DevOps体系
运维·软件测试·测试开发·devops
xcg3401234 天前
【系统分析师】-2024年11月论文-论DevOps开发
论文·devops·2024.11软考
天草二十六_简村人4 天前
jenkins用户在执行scp的时候如何做免密登录
运维·ci/cd·node.js·jenkins·php·devops