不要仅仅优化团队层面性能

Klaus Leopold 在 GOTO Berlin 2015 会议上发表了演讲。在演讲中他阐述了为什么专注团队层面的性能往往会导致局部次优化、并不能在整个团队层面提高敏捷。InfoQ 对其进行了采访，主要关于为什么安装（install）敏捷框架并不有助于提高敏捷、如何使用 Kanban 加强协作、和团队能够从 Kanban 中获得的优势。

InfoQ：我听说越来越多的团队正在使用 Kanban**** 从而以一种敏捷的方式工作。你能举例说明你共事过的团队是如何使用 Kanban**** 的吗？

Leopold：我在许多不同的领域使用过 Kanban。从经典的硬件开发到市场营销、管理、人力资源部门和机构，几乎没有哪个领域是我没有接触过的。我知道有的企业使用 Kanban 管理招聘流程，或者在汽车行业，有的企业用 Kanban 管理开发流程，或者甚至是有多个工厂参与的回收再利用流程。当然，软件开发也是其中之一，但是，它仅仅占我目前工作的 30%。在每个环境中，你都需要更好地了解自己的工作环境，在此认识基础上实现改进，从而提高客户满意度。

InfoQ：团队可以从 Kanban**** 中获得什么优势？

Leopold：一开始，许多团队会寻求可见性（seeking visibility）。当谈到使用 Kanban 时，我听的最多的目的可能是“能够看到发生了什么”。然而，我认为可见性不是目的。当涉及理解你的工作系统时，可见性是达到目的的手段或者方法。并且我认为这是人们能够通过使用 Kanban 获得的最大优势。从根源上来讲，Kanban 仅仅意味着了解发生的事情，并基于这种了解实施正确的改进。这听起来好像非常容易，但是相信我，完全不是这么回事，因为知识工作并不是直观的。比如：当我们不是无时无刻加班加点工作时，工作往往能够更加快速地完成。当我们立即开始客户工作时，往往不能很好地服务客户。更快地工作与更快地完成工作没有直接关系。更早地开始工作往往会更晚地完成工作，等等。这非常的不直观，但是，当涉及到改进时，理解工作系统的这些方面是必不可少的。关键在于你需要弄清楚为了分别优化你的业务或者客户你需要采取的手段。旨在按时交货的系统与优化产品上市时间所采取的行动和设计的系统是不一样的。

InfoQ：如果我们是有多个团队，或者有数百名员工的较大组织？敏捷框架能否帮组我们组织工作，我们还需要其它一些什么吗？

Leopold：我并不是十分热衷于“安装”框架，无论是敏捷、精益或者其它目前流行的框架。有一点是明确的，如果你想在当今的商业现实中生存，敏捷非常重要。另外一点也同样非常清楚：安装一种方法或者框架不会给你带来想要的敏捷。我来告诉你为什么。

敏捷意味着什么？对我而言，敏捷意味着企业适应不断变化的世界或者甚至是为了成为行业领导者和创新所需要的领先。为此最重要的前提是企业不断地变化和改进。如果你安装框架，中心思想是复制随机实践。但是持续改变和敏捷不能通过复制实践获得。情况恰恰相反；在许多情况下，框架阻碍了持续改进，因为它们的安装被看成是达到一种目标状态：正如框架所规定的，企业需要重组，员工需要为新的工作方式重新培训，然后执行新的流程和实践。搞定！不，这是完全错误的！如果真实目的分别是持续变化或者敏捷，那么你就从来没有搞定。

InfoQ：您能否详细说明如何使用 Kanban**** 了解较大组织内的团队协作的情况，如何使用 Kanban**** 为提升协作寻求新的方式？

Leopold：我认为最重要的一点是 Kanban 不注重组织结构，比如团队、部门等等。Kanban 使公司服务和价值生成成为关注焦点，并希望改进它们。因此，第一个问题是：“如何才能为客户创造价值？”一旦你有了答案，你就可以专注第二个问题了：“为了实现客户价值需要什么？”因此方法不是在企业 100 个团队中实施 Kanban 然后询问：“如何让团队一起工作？”而是分别从寻求服务和创造价值开始。如果你需要多个团队，从而确保服务的价值生成，然后答案才是不要在单个团队层面实施 Kanban，而应该跨多个团队。并且我认为这是 Kanban 的伟大之处：绝对没有东西可以限制规模化 Kanban。这意味着 3 个人的团队可以使用 Kanban 进行改进，拥有数百人的组织也可以。你唯一需要做的是实施真正意义上的 Kanban。

InfoQ：在 InfoQ**** 文章 Kanban****能否规模化一文中，你给出了如何使用 Kanban**** 在完整的交付周期管理在制品数量的案例。您能解释一下 Kanban**** 是如何有助于优化整件事，并阻止局部优化的？

Leopold：对我而言局部优化意味着一个系统只有一部分被优化，并没有考虑整个系统。如果我们讨论的不是只有 10 名员工的公司，那么为了开发产品或者履行服务几乎可以肯定需要数个团队。比如，在软件开发中，开发一个产品可能需要多个团队。如果在这种体系结构中，只是服务中的个别团队被“优化”或者敏捷而不是整个服务，那么如果整体性能寸步难行时你就不应该感到惊讶——尽管已经敏捷并花费不菲。我给你举个例子：我曾经在一个公司与他们的软件开发团队共事过，他们引入了 Scrum。他们确实获得了成功——他们成功提高了生产量降低了产品特性的交货时间。团队完成开发后，将产品移交给员工培训团队，员工培训团队的任务是给那些在商店使用应用的员工进行培训。随着开发团队提高了性能，员工培训团队跟不上步伐，导致培训质量下降。商店员工在购买流程中使用软件咨询终端客户。但是，因为商店员工没有获得正确的有关最新产品和促销活动的培训，他们不能很好地服务客户，导致客户投诉的增加，最终导致成本增加。开发团队的工作完成的很出色，但是这种“敏捷”是一个大的局部优化，因为最终没有使终端客户满意。然后我们引入了 Kanban 的飞行阶段 3（Flight Level 3），在飞行阶段 3 中我们优化整个价值链，在软件开发中从产品负责人直到商店员工。其结果是一段使各方共同改进的旅程，从而让终端客户满意。关键是不要敏捷或者改进组织结构，比如团队——提高价值创造！

如果 Kanban 被正确理解和执行，这些影响就不会发生，因为正如前面问题描述的，公司服务和价值生成成为焦点，而不是整个系统单一、分离的部分。

在这点上有必要说一件事：局部实施 Kanban 当然是可以的。如果系统被正确建模，那么局部优化就能很快被发现，未开发的潜力就能经济地量化。这通常是初步讨论的起始点，讨论的结果往往是规模化——因为经济论证相当有说服力。

查看英文原文： Don’t Optimize Team-level Performance