汉堡屋的故事：从系统思维、瓶颈到跨职能

本文要点

• 了解约束理论和系统思维帮助团队“停止开始，聚焦完成”（stop starting and start finishing）
• 解决瓶颈是提高系统吞吐量最行之有效的活动
• 本地优化常常导致整体系统的局部最优化（sub-optimizing）
• 允许个人暂时脱离单一角色的跨职能团队能交付更好的成果

在 2014 年世界杯和 2016 年夏季奥运会之后，每天都会发生很多事情。几年前，在我的家乡里约热内卢商业区的狭窄街道中，一间小汉堡屋开张了。这个点子很好：少量但优质的原料，以及在小巧安逸的地方有一个开放性的厨房。

那时候我们经常在附近上一些培训课。有一天，我的商业伙伴 Rodrigo de Toledo 邀请我去品尝这家店的汉堡。到那之后，我在收银台排队等待。我首先注意到，他们的系统已经经过优化，因此点餐非常高效：选项如此明显，吃客很清楚他要做什么。然后轮到我点餐的时候，我不得不做出选择：汉堡还是芝士汉堡？要不要加培根？西红柿、莴苣、洋葱、泡菜、番茄酱、芥末还是酱油？要不要加苏打和炸薯条？我做出选择后付了钱，走到一边，然后……整个事情就搞砸了。

一群人正在等待区乱糟糟地站着，希望能拿到他们的汉堡。而柜台后面的人忙于制作汉堡，并将它们送到饥肠辘辘的吃客面前。等了那么长时间拿到的居然不是自己点的汉堡，或者里面加了不是自己想要的配料。

过了几个礼拜，Rodrigo 再次来到这个地方吃汉堡，发现两个收银台中，有一台关闭了。估计那天早晨有个收银员请了病假。你能猜到发生什么事儿了吗？你说会不会发生混乱呢？一点也没有。

下面是他的体验：他进到店里，站到唯一可用的收银台边，当然等待时间要比平常久一些。然后，他不得不从可用的几个选项中进行选择。厨房里有几个人正在紧张制作汉堡、炸薯条。他付款后走到一边等待。出乎意料的是，有几个吃客正在整齐地排队等汉堡。在厨房的另一边，他看到人们正在制作汉堡，并以同步的节奏将汉堡放到一起，在不到一分钟的时间里，他就拿到了汉堡并放到托盘里，找了地方坐下来开始享受起来。酷吗，嗯？

是的，没错！体验有所改善！这样更好了，人们在店里逗留的时间也更短了。这怎么可能呢？请让我来解释一下这个“魔法”吧。

在平常，备餐台是个瓶颈：一些厨师制作汉堡并把它们放在一起。两位收银员以及经过优化的点餐系统所产生的订单超过了备餐台的支持能力，导致库存量不断增长，即订单的交付。这对备餐台上工作的员工施加了压力：“天呐，我们还有很多订单要准备！”

而站在那里的吃客则在等待汉堡，这加速了瓶颈的出现。厨师们想要跟上节奏，就不得不加快速度以至于超出了他们的能力，这就使服务质量下降了。较差的服务质量意味着给吃客送错了汉堡，并搭配了不正确的配料。吃客就会退回汉堡，这样一来，就降低了吞吐量。因此，他们销售的汉堡比较少。

而那天收银员没有来上班会发生什么事儿呢？订单减少了，从而缓解了瓶颈。幸运的是，订单减少并稳定在足够的数量时，制作汉堡的员工可以及时完成工作。他们开始能够持续地、有效地做好准备并且无误地把汉堡交给正确的吃客。因此，站在那里等待汉堡的吃客比较少。没错，收银员等待的时间更长了。但是，从整体来说，消费体验更好了，我可以确信当天系统的吞吐量（也就是出售汉堡的数量）更高了，尽管实际上并没有人去测算过。

但你知道这是为什么吗？这种因果关系看上去如此的违反直觉，厨房老板转天招了第二个收银员，问题重现了。

就在几个月前，我像往常一样，正在巴西南部的阿雷格里港机场。如果你喜欢美妙的肉食，那这座城市就是你应该要去的地方。但这次，我只是在美食广场观察一家国际快餐连锁店的运作，并不涉及真正的肉食。

他们有五个收银台，还有其他几个工作台，如炸汉堡、组装汉堡、炸薯条和制作沙拉。收银员自己倒苏打水，并把订单的食物放在一起。

突然，老板在后面呼喝，一名员工随即关上了收银台，然后洗手去帮忙煎炸汉堡。我花了一点时间了解发生了什么事情，才发现了这其中的奥妙之处：汉堡备餐台的两个员工陷入困境，汉堡不能像订单那样很快就出炉，因此，订单就会开始堆积。随着订单的增加，老板了解到他们会越来越深陷其中。显然，在那一刻，那个工作台成为了系统的瓶颈。

也许在收银台的员工是个导购，但那时她在哪里会更有价值呢？给其他站台上送更多的订单？这不仅不会增加出售汉堡的数量，实际上，反而会降低出售汉堡的数量！所以，她可以停下来，情况会更好一些。但是，让她帮助炸汉堡会更有价值，无论如何做，她都可以帮助加快速度。

当然，为了做到这一点，这位员工要比作为收银员的角色掌握更多相关技能，她需要知道如何炸汉堡。而老板不仅需要掌握单一技能的专业人员，也需要能做好其他事情的员工。只要有足够好的员工，至于她是否能得到帮助，又或者她能够做好整件事，都无关紧要。任何一个员工都会为系统带来价值，而那一刻在收银台工作并不会带来更多价值。

另一方面，如果另外一个工作台出现瓶颈，比如制作沙拉？她或者其他人也得知道如何帮助制作沙拉。也许另一个收银员可以帮忙制作沙拉呢？

关键是，鉴于系统中所有的活动都是端对端的（这种情况下是交付订单），团队成员掌握的技能越多，系统的吞吐量就越高。跨职能的人才是关键。

不管你的系统生产什么，无论是汉堡、软件还是其他任何东西，都不难，它的吞吐量总是受到瓶颈的限制，不会比瓶颈允许的速度更快。

但如果您在出现瓶颈之前优化系统的任何阶段，那么库存量将会有所增加，这样会加大瓶颈压力，导致质量下降。如果在出现瓶颈之后优化任何阶段，就会处于空闲状态，请求更多的任务，这样也会增加瓶颈压力。两者都有可能降低吞吐量。换言之，在不考虑整体系统的情况下，优化任何阶段（我们称之为“本地优化”）都有可能会导致系统局部优化（sub-optimization）。

一定要注意，这种情况下，他们习惯老板告诉他们在什么时候以及在这些情况下如何做。但是，如果有了一个自组织的团队，成员自己就会找到方法，知道他们的工作在达到合理的限度然后采取行动。

现在想象一下常见的软件开发团队。DBA 正在忙于创建和更新数据库表，后端开发人员则忙于构建 API 来访问数据库表。业务开发人员忙于创建类，前端开发人员忙于创建动态 HTML ，设计师忙于设计。这个时刻，测试人员等待测试，无所事事。老板很高兴，因为他几乎让每个员工保持“忙碌”，但是，他们在工作中，是以什么样的速度来完成呢？

他们确实做了很多事情，但实际上并没有那么多。如果他们以优先顺序进行工作，从最重要的事情开始呢？如果他们限制可以进行的工作量，那么在完成更重要的事情之前不做其他事情会怎样？如果打破这些孤岛，或者至少模糊这些边界，开始分担责任和互相帮助呢？

听上去不可能是吗？好，看看汉堡屋的第二个故事，他们会完成得更多！一旦测试成为瓶颈，DBA 帮助完成测试任务要比再创建一张数据库表更重要。或者，如果前端成为瓶颈，那么后端就施以援手！这样的好处是，人们会相互学习，成长为一个团队！

在这种更好的吞吐量、质量和动机的情况下，头街并不重要，具备不同的知识和技能才是关键。无论团队成员以往声称自己从事什么工作。现在，他们在团队中都会有不同的工作，第一，在必要的时候无论做什么都要做到最好；第二就是教会别人，这不仅是给他人也是给整个团队的礼物，以后回馈到他们的身上；第三，就是走出舒适区，向团队里的其他人学习，在出现瓶颈时可以做不同的工作来缓解系统压力。

第四，就是和老板合作，这样可以帮他们摆脱困境。这一切很违反直觉，是吧，但今天太多的管理人员根本就没有领悟到。他们让人们限于孤岛，让人们保持忙碌，“忙碌”似乎成了他们的关键性指标。他们让人们着手做很多工作，但却忘了把工作完成才是真正重要的事情。

正如在丰田生产系统和约束理论指导框架中，我们经常听到看板（译注：源自日本，指企业为降低原材料或零部件的仓储成本在需要前夕才进货的制度）从业人员听到的说法，至关重要的是：“停止开始，聚焦完成”（stop starting and start finishing）。

作者简介

Rafael Sabbagh， 拥有二十多年的各种数字产品开发、编程语言、方法和技术的经验。Rafael 是 Knowledge21 联合创始人，Knowledge21 是一家从事国际培训和咨询的公司，也是巴西市场的领导者。他是 Scrum 培训师（CST），在 2015~2017 年时，是 Scrum Alliance 董事会成员。他拥有商业硕士和计算机工程硕士双学位。Rafael 几十年来在二十多个国家开展了培训和咨询的工作。通过旅行与不同社区和文化展开互动，他对全球范围内的软件开发现状有着全球视野、主要挑战的内容以及如何解决这些挑战的想法。除了参与 IT 会议外，Rafael 还参加了不同国家举办的十几个 Scrum 大会（在多场大会担任演讲者）。2013 年，他用葡萄牙语撰写了第一本关于 Scrum 的书，现在是他所在国家的一本著名参考书。

Rodrigo de Toledo、Marcos Garrido 和 Carlos Felippe Cardoso 对本文亦有贡献。

查看英文原文： The Burger House: A Tale of Systems Thinking, Bottlenecks and Cross-Functionality

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。