人们一般都认为：如果团队中每个人都能发挥最大能力，那么这个团队一定是最有产出的团队。与之相反，Steve Bockman 认为这个假定不一定永远成立。在有些情况下，可能有必要 放慢团队速度，少干点儿活，而不是全速前进，最终目的是为了迅速提高产出和利润。
Steve 提到他在两个团队中做过的练习，步骤如下：
- 操作一：从库房里取出一些原材料（一叠纸）。
- 操作二：把纸向内折叠，然后再展开。
- 操作三：把纸张的上面两个角向内折叠。
- 操作四：把纸张两边向内折叠，只折一半，折成类似于翅膀的形状，再放下来。
一个团队用尽全力工作，而另一个团队被要求放慢速度，以配合最慢的操作。
两个团队都在 5 分钟内产生出同样数量的纸飞机，然而查看由于在制品库存造成的损失，全力工作的团队的损失要远高于配合最慢操作的团队造成的损失。第二个团队没有产生堆积如山的在制品，因此减少了消 耗的物料和劳力。
Steve 进一步引用了商业小说《目标》， 其中指出可采取下列步骤改进产出：
- 步骤 1：识别系统的瓶颈。
- 步骤 2：想办法如何让瓶颈发挥最大潜力（比如：不让瓶颈处于空置状态）.
- 步骤 3：协调系统其他部分，以配合步骤 2 中的决策（比如减缓瓶颈上游步骤的操作速度）。
- 步骤 4：提升系统的瓶颈（比如让缓慢的操作提速）。
- 步骤 5：如果在之前的步骤中，一个瓶颈被打破（比如某个瓶颈不再是瓶颈），那就回到步骤 1。
因此，推荐做法是：在试图提升瓶颈速度之前，先放慢所有非瓶颈操作的速度。
将上面的推荐做法与自己在试验中得到的体会梳理过一遍之后，Steve 将软件开发过程做了一个类比，这个类比可以总结为知识的创建与分享。他建议采用下列咒语来提升利润：
- 知识是软件开发的库存。
- 人们会以自己的速率来消耗知识。
- 如果知识的创建速度快于消耗速度，那就会产生过量库存。
- 过量库存会降低利润。
根据上面的讨论，我们可以得出结论：如果系统中存在瓶颈，而且以相对较低的速度水平运作，要是此时仍拼尽全力，反而对系统产出利润不利。关键在于保持与瓶颈相同的处理能力，并先让瓶颈提速，让整个 系统向最高处理能力接近。这样就可以降低在制品数量，从而保证系统的健康，还能产出利润。
查看英文原文： Slow Down to Speed Up Profits
暂无签名
最新发布
你的 Scrum 检查列表
2011 年 4 月 20 日
Apache 基金会主席 Doug Cutting 谈 Hadoop 和开源
2012 年 1 月 17 日
InfoQ 专访 eBay 系统架构总监 Tony Ng：聊聊电商网站的架构与安全
2011 年 12 月 6 日
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
FreeWheel 技术专家为你解读微服务架构趋势
中小前端团队 Team Leader 的管理之路
余额宝背后的服务治理架构（下）
评论