为你的组织设计自己的障碍消除流程

许多精益主张的支持者是从关注浪费和消除浪费开始入手的。这至少要面临两大挑战 1 。第一，浪费的定义来自于 20 世纪生产行业，在精益软件的著作中一直沿用未做任何修改。第二，浪费的暗喻手法由汽车制造业迁移到当今的知识性工作中也比较牵强，不太舒服。如果在团队和组织工作中执行敏捷 - 精益方法，可以帮助你更好地关注以下的两个基本问题：

1. 你的团队和组织是用怎么样的流程来开展工作的？
2. 什么阻碍了工作的流程？

本文主要关注的是第二个问题，以及如何去处理这些工作流程中的障碍。

在你的团队或组织中有没有以下类似的问题？

• 你们发现自己总是在一遍一遍重复着相同的问题
• 你们发现正在反复地解决相同的问题
• 你们发现思考的问题只不过是一种表面现象
• 你们无法把控团队的速率
• 看上去要很长的时间才能解决这些问题
• 翻来覆去地变
• 尽管很努力，但缺陷率却仍在扶摇直上
• 特性的研发速率随历次的发布逐渐衰减
• 大家普遍对现状不满，却又没人采取行动

以上种种都暗示着你的团队和组织中出现了障碍。

精益产品开发关注的是系统端到端的工作流程。与其关注类似于产能使用率这些传统的度量，关注工作在体系中如何开展会更加有效。时常听人提起消除障碍以完成到敏捷的转变。我发现这其实没有太大的帮助。首先，过渡到最终状态是一种根深蒂固的错误观念；其次，这把焦点集中在了敏捷（或者精益，或者两者都是）上，而不是业务目标上，比如为客户交付满意的产品和服务。我宁愿集中精力去消除流程上有价值的障碍。为了做到这一点，就需要慎重、仔细地设计消除障碍的流程了。

1. 简介

梅里亚姆·韦伯斯特字典里对障碍有如下的定义：使某事难以去做或难以完成的任何事；妨碍活动或流程的某些事。换句话说，障碍是妨碍流程的某些事。

我们先来看看工作在团队和组织体系中是如何运转的。当我首次关注精益并应用精益原则时，就觉得把精益中浪费的概念直接套用到软件开发领域有些不对。这并不意味着消除浪费不重要，问题在于，首先要承认在现代像软件开发之类脑力工作中浪费的界限并不明晰，它不像工业生产线和其他的领域。

我发现为提升效率去关注工作流程是件非常自然的事，而不是总是刻意地去找出浪费和消除浪费。从这个角度来看，有两个主要的问题。第一个问题是“在我们的体系中是工作如何流转的”？对于大家来说，流转图能够看清每个环节，它比那些仅仅存在于名义上的岗位职责会更加地清晰明了。跨组织的管理者和领导者可以共同来创建这张图。第二个问题是“贯穿整个体系的工作流程有什么障碍”？或者，换个问法，“工作流程中还有哪些改进的空间？”

至少从 2010 年开始，我的工作就遍布在世界各地了，主要分布在南美、欧洲、以色列、印度和中国，在这些工作的过程中我深刻理解了工作中的障碍，并找到了解决的办法。我不仅是一个全球性公司的全职员工，而且还取得了一个博士学位，重点研究对流程的理解和团队与组织中的障碍。非常幸运的是，我的研究能够直接应用于我所在的团队和组织中。基于刊物和会议上的资料，我对此有了全新的认识，并将它们写到了我的研究报告中。

2. 障碍的管理

2.1 障碍的认识

敏捷团队对此有着得天独厚的优势，因为在这个方法中涉及频繁的交流仪式和经常性的反思。

每日站立会。每日站立会是提出障碍的绝佳场合。举例来说，类似于日常性的 Scrum“三个问题”可以调整成有关障碍的询问。

Scrum-of-Scrums。当多个团队共同协作来处理一个大型问题时，关注障碍会给予你们非常大的帮助。

回顾会。回顾会是一个不错的讨论场合，但它也容易形成一种定式。团队通常在回顾会中会陷入到同一种形式中。总重复一种模式（比如按常规的节奏重复单调的形式）会阻碍我们检视环境和探测模式的能力：如果我们总是用一种方式去检视体系，那么意识上就容易麻痹，在问题出现之前无法发现那些微弱的信号。大脑喜欢接收新奇和刺激的事物。我们要利用这一点更早地发现障碍。

自我评估。自我评估能够帮助团队识别障碍的来源。通常，障碍不会直接识别出来，而自我评估能够暗示团队应该要引起警觉好好分析一下了。他们可以使用那些实践中的欠缺和记录下来的问题有所关联的信息。

调查。调查是另一个很有用处的工具。我们直接用调查去发现组织中的障碍和导致障碍的原因。

自我评估在本质上更多的是定量分析，专注于特定的敏捷和精益实践和行为。我们习惯按季度来进行。调查让我们可以透过这些定量的信息去更加深入地挖掘洞察力。这对发现障碍来说是非常有帮助的。

观察。一个团队可以通过观察揭露很多的障碍。一位资深的观察者经常可以看到团队已经无视的模式。

2.2 消除障碍的困难

首先是对障碍的认识——克服意识上的匮乏，首先是感觉到哪些事不太对，通过感官可以更敏感地发现障碍。流程和障碍提供了一种语言和语境，让我们去关注是什么降低了我们的工作效率，或者是什么妨碍了我们的流程。我经常首先关注症状，因为它们很容易发现也很容易描述。

理解其影响可能很困难。影响可能会关乎时间、金钱、质量或士气。为了帮助团队和组织清楚地表达障碍的影响，并且去理解要解决这个障碍需要去改变哪些人或者要寻求哪些人的帮助，我绘制了一张障碍影响图。在 2014 年敏捷大会上我介绍了这张图，在 IEEE 数字图书馆中可以找到它，里面详细描述了这一理念的相关细节 2。图 1 展示了障碍影响图的示例。

图 ****1 障碍影响图

当团队已经发现了大量（可能几十，甚至上百）障碍，需要快速搞清楚大量的数据以决策把主力精力放到哪里时，障碍影响图也可以起到特别的作用。

2.3 处理障碍的责任

对于使用 Scrum 的团队来说，Scrum Masters 发挥着至关重要的、显著的作用，由他来推动障碍的解决。他们有很多的责任，团队在他们的指导下去学着理解和解决障碍。在仆人式领导的意识里，他们掌控着团队层的障碍，必要时建议和管理者共同来解决障碍。既需要把控消除障碍的过程，也需要培养一种让团队成员对障碍负责的氛围，要在这两者之间取得巧妙的平衡。他们可以把障碍提给管理委员会，嗯，如果有必要的话甚至可以提给董事会。

管理人员也要发挥作用。其中最重要的一件事就是为团队提供支持，为他们消除障碍或者帮他们消除障碍。

每个团队成员个体也要发挥作用。重点是要在消除团队障碍时找到其中的平衡点，既让他们可以专注于各自的工作，又要帮助大家提升解决问题的能力。

根据障碍的性质，有时可能需要组织外的高级领导或人们的帮助。所以，我喜欢区分开谁负责解决障碍，谁确认障碍有没有解决。Scrum Masters 通常应该掌控这个过程，以确保障碍真的解决了，并使大家负起应有的责任。真正负责解决障碍的人可能会有所变化。

2.4 可视化障碍和处理障碍

让大家都能够看到障碍能帮你们更有效地处理它们。

这要从团队开始入手。在看板或 Scrum 的旁边应该再设立一个障碍板。我们通常都是从一块单独的板开始入手。稍后，也可以把障碍合并到已有的板上。我们要做到的重点是让这些障碍可视化。

管理人员也有障碍板。管理板上的障碍取自于团队的障碍。董事和高管们同样也有障碍板。比如图 2 所示。

Figure 2 团队、管理者和高管的障碍板

我很喜欢 Karl Scotland 的启发法，它将其称之为“可视化的提示”，这个方法能帮助大家形成共识 3。提示可以表示标记、铭文、位置。在障碍的语境下，通常它们有这样的暗指，标记用来表示为障碍，铭文表示障碍的描述，位置表示障碍的状态。

强弱很重要。障碍从团队板到管理板再到高管板逐层升级。组织来决定在团队板、管理板和高管板上移动障碍的策略。这些策略的示例包括：

• 作为流程的掌控者，只有 Scrum Master 可以在不同的板上移动障碍。
• 限制未解决的障碍数量，换句话说，在管理团队板的过程中不要超过 5 个障碍，否则我们就是在制造障碍。
• 限制不同板间移动障碍的时间，也就是说，如果一个障碍在团队板超过既定的时间（可以是一周或者三天都可以）还没解决，那么 Scrum Master 就把它自动移到管理板上。

灵活的约束比死规则要好得多，让团队去实验适合自己的策略。

2.5 障碍板

障碍板在障碍的管理中扮演着核心的角色。从本质上说，它们就是看板，使大家可以清晰地看到针对障碍定义的流程。每个团队都有自己的障碍板。一支管理团队支持多个开发团队时，往往也需要一块障碍板。

Figure 3 一个管理团队支持多个开发团队，每个团队都有自己的一块障碍板

2.6 度量

度量非常地有用。跟踪障碍的处理周期可以为组织提供洞察力。我们如何快速地解决障碍呢？哪些类型的障碍还没有解决？或者解决得不够快速？如何解决问题告诉了我们什么呢？正在如何工作和正在优先做什么教给了我们什么？

2.6.1 针对识别障碍的度量

我们用了一组核心的度量以帮我们更好地理解流程和识别障碍。我在一份敏捷联盟经验报告 4 上描述了很多的细节。图 4 展示了一些生产率分析、积累流图、周期时间和发布燃尽的示例。

图 ****4 为理解流程和识别障碍的度量

图 4（a）中的生产率分析显示生产率上升到了一个稳定的速率，但也显示失败的需求（红色部分）也持续了一段时间了。存在失败的需求要引起你的警惕。图 4（b）中的积累流图（CFD）显示了按周期增长（黄色部分）的半成品（WIP），也显示出已“完成的”工作得到验收会经历明显的延迟（由蓝变绿的过渡）。在图 4（c）中的周期时间报表比较靠后的一部分显示暂时出现了一个比平均周期明显的增长。在图 4（d） 中的发布燃尽图显示了包含在 CFD 中的一部分信息，但清晰地突出了接收率。这些未见得都是问题，但它们暗示出可能存在潜在的障碍。

2.6.2 针对障碍管理的度量

我们也会对障碍的管理予以度量。

队列长度是一个不错的指示器，它向我们显示了当前为给定的开发团队或管理团队打开了多少障碍。跟踪随时间而变化的趋势能为我们提供丰富的信息来源，它显示了我们正在发现和处理多少障碍。我们担心的不是团队出现了很多故障，而是没出现故障。

周期时间为我们显示了解决缺陷的速度。在我们所遇到的障碍中，有一部分仅用几小时或者几天就可以解决掉，而其他的需要几周或者上月的时间。

我们可以利用它对障碍进行分类，这样当发现障碍时，就可以更精确地显示出障碍的类型了。这也能起到一个指示器的作用，告诉我们解决这个障碍需要花多少时间。

我们希望把障碍根据组织链予以过滤和整理，以便对那些系统性的问题保持警惕，知道它们正在影响着跨组织的多个团队。

3 跨组织的障碍处理的扩展流程

在试图扩展流程为跨组织的之前，首先理解流程为何在局部有效，如何在局部有效的。第一步是理解流程的职责。从团队成员到高级管理层都可以清晰地看到，我喜欢画一张简单的图达到这样的效果。它与价值流图最主要的不同点在于，价值流图是为客户找出价值流。而这张图是让我们找到负责帮助团队消除障碍的团队，以使团队和管理团队的流程平稳地运行。这会涉及到各种各样的学习，不仅仅是完成工作，还会涉及如何处理信任、透明度、责任、风险、问题解决这些事，还有很多事我们可能已经习以为常了，或者在此根本就没有提到。

一旦你真的理解它为何有效、如何有效之后，就可以增加更多的团队和更多的管理团队了。

分享障碍的细节，把解决方法贡献给组织知识库。我们可以就此问自己几个问题。我们看到了组织的什么模式？与孤立的事件相比，什么样的事情会成为系统级的问题？有时可以会遇到这样的问题，一个团队不喜欢其他团队去听他们的障碍，但这种情况实际上很少见。当它成为管理问题时，应该有一种将其完全透明的文化。我会在本章之后的可见性和透明度中进行更加深入的讨论。

4 鼓励正确的文化

此类方法要求是让正确的文化可以发扬广大。当然，团队和组织不能简单地创造新文化。我们应该创造有利的条件使有效的文化得以生根发芽蓬勃生长。对于易于处理障碍的文化和支持开发大家解决问题的能力的文化，我们要鼓励和发扬。本章将讨论这个方面的一些方法。

建立信任感。信任对于流程的有效性是必不可少的。最初把所有的障碍公布出来是件很恐怖的事。恐怖心理一直持续，直到我们内心承认这一事实，我们需要去解决它们。如果存在责任的文化，这会变得很困难。出于多种原因，有些人和团队不愿意在障碍上投入精力。这可能是信任的问题，或者其他的文化因素。在一开始，管理者需要鼓励团队去解决障碍。管理者要强调他们的的职责就是支持团队的工作。解决团队层面的障碍就是他们的核心职责之一。教练的一个主要作用帮助大家感受到安全感。

责任。我们需要一种彼此间互相负责的文化。需要明确谁对障碍负责，他们正在做什么，截止日期是什么时候。大家有义务使障碍可见、透明以使它更易于处理，并予以积极的强化。

一致性。在工作流程的管理中坚持始终如一的决心，不断地查找和消除障碍。这一点对于管理团队来说尤其如此。

可见与透明。持续关注可见和透明。保持障碍的可见性。使它们的原因、状态和影响透明化。这些事一开始可能让人有些不太自在，但它们其实是让大家尽早地面对这些不适。如果组织存在基本的信任或能够实现基本的信任，那么对此还是很有裨益的。如果没有，在思考使用障碍消除流程之前，甚至或者在使用敏捷方法之前就需要面临组织级的挑战了。

非中介化。缩短高管和团队间交流和组织的间隔。这不是说要废除管理的角色，只是需要审视在团队和高管之间是否存在过多的中间管理层。一般来说，减少的是项目和程序员的间距，而不会触及到组织结构图。

团队作为一个整体去解决困难的问题。有一定比重的障碍需要一些细致的分析和讨论。我们针对这些障碍使用了 A3 问题解决报表和一些其他的方法。这些方法倾向于把不同组织的人聚到一起共同事解决问题。这也是提供了一个让组织中的高手们去指导和培养其他人的一个绝佳机会。我觉得这个方面存在着巨大的价值，成长中的人们、团队和组织存在着巨大的潜能。管理人员使用 A3 或其他的方法可以指导大家并帮他们开发解决问题的能力。把管理人员和团队成员放在一起还可以加强他们之间的联系，这是这种做法带来的额外好处。这可以让大家增加培养他人的眼光和意识。

培养新习惯。如果总是把障碍换层皮遮掩起来的话，是不利于组织培养新习惯的。通常抛弃旧习惯要比学习新习惯要来得更容易一些，而且收益也会更大。消除障碍就为我们提供了一个培养新习惯的机会。在《习惯的能量：为什么这么做，如何做改变》一书中，Charles Duhigg 探讨了基础习惯的理念。他说“基础习惯以创造文化来改变我们，这种文化让我们在激烈的决策或片刻的迷茫中清楚价值所在，否则我们可能会忘记重点所在。”

文化为先，工具为次。第一步，先简简单单地把看板挂到墙上吧。不管那些电子化工具多么地诱人，在尝试它们之前还是先保证流程能够走通吧。随后，软件工具可以让大家都看得到组织的障碍，从而增加一些价值。这对于地点分散的组织来讲是非常有益的。但是过早地使用工具会抑制和取代人们之间的交流，从而使我们无法取得希望的文化的变迁。我发现很多团队还没有把新文化和新习惯融入到组织之前，就已经掉进了工具的陷阱之中。

5 与方法的关系

无论你所采用了哪种敏捷方法，障碍消除流程都要推崇相同的价值。举个例子，比如说使用看板吧，它推崇和支持的核心价值是透明度、协作、流转、演进式变革，以及协作式改进和实验式演进 6。

• 透明度：我们要使障碍可见，使其影响可见，并展示这些障碍正在如何处理。
• 协作：团队和管理人员共同协作去解决障碍。
• 流转：障碍消除流程最关注的是消除价值流上的障碍。
• 演进式变革：消除障碍会导致不断的变革，并在组织中养成新的习惯。
• 协作式改进、实验式演进：障碍消除流程提供了识别障碍和消除障碍的框架。有些障碍会影响到很多的团队，那就可以做一些小的实验，帮助组织的演进和完善。

障碍消除流程还支持 Scrum 的三大支柱 7：

• 透明性。和看板一样，Scrum 也需要所有工作是可见的、透明的。
• 检查。“_Scrum_ 使用者必须频繁地检查 _Scrum_ 工件和达成迭代目标的进程，以发现不良的差异”。这种不良的差异通常都是由于障碍造成的。仔细地找出和处理这些障碍，支撑起 Scrum 要频繁检查的这根支柱。
• 适应。消除障碍包括进行变革。障碍消除流程应支持进行流程和环境的变革，以帮助团队在正确的航道上前行。

6 总结

总结来说，可以用以下步骤建立消除障碍的流程：

• 先使障碍可见。
• 创建专用的障碍板。它本质上就是用于障碍的看板。然后，团队可以考虑把障碍板合并到主看板上。
• 建立明确的政策，控制如何、何时切换障碍的状态，如何、何时在板上移动它们。
• 采取行动，消除障碍。
• 团队每天检查一下障碍的状态，使它成为每日站会的一部分。
• 和管理团队一起定期回顾组织级的障碍，至少每周一次。采取行动去取消障碍。找出系统性问题并展开讨论。采取对策处理系统性问题。
• 至少每周检查操作程序级的障碍，最好每周两次。如果存在多支 Scrum 跨操作程序间的协作，就要特别关注这一层面的障碍了。

7 参考资料

1. K. Power 和 K. Conboy, 《流程障碍：在现在软件开发中重新思考“浪费”的概念》，在意大利罗马 5 月 26 日 -30 日召开的软件工程和极限编程中的敏捷流程第 15 届国际大会（XP2014）上提出。
2. K. Power, 《障碍影响分析图：理解敏捷团队和组织中的障碍影响》，在美国佛罗里达奥兰多敏捷软件开发大会（敏捷 2014）上提出。
3. K. Scotland，（2013 年），《看板——不仅仅是种常识？》，可参考网址： http://www.infoq.com/articles/kanban-heuristics-common-sense
4. K. Power，《为了解流程进行度量》，在美国佛罗里达奥兰多敏捷软件开发大会（敏捷 2014）上提出。
5. C. Duhigg 的专著《习惯的力量》，William Heinnemann 在 2012 引用。
6. M. Burrows, 《内心深处的看板》。Sequim, WA: Blue Hole Press, 2014.
7. J. Sutherland 和 K. Schwaber, 《Scrum 指南。Scrum 终极指南：游戏的角色》Scrum.orgOctober 2013.

关于作者

Ken Power 是思科系统有限公司的首席工程师、内部教练和顾问。他居住在爱尔兰戈尔韦，和世界各地的团队与组织共同工作。他的职责包括带领思科最大的软件组完成敏捷转型。他还和大学及研究小组共同研究敏捷、精益和软件工程。他现在已经拿到了精益流程的博士学位，对团队和组织中的障碍有相当深入的理解。他经常在各大国际敏捷、精益和软件工程大会上演讲，发表了很多敏捷、精益开发和软件工程管理方面的文章。

查看英文原文： Impediment Busting: Designing an Impediment Removal Process for Your Organization