自组织的铁三角关系

要点

• 了解自组织是什么，为何它很重要
• 在团队中正确实现自组织的三大关键要素
• 如何使用这些要素实现所需的结果
• 如何将其运用在敏捷方法中
• 如何自组织用作一种管理工具

自组织团队这种想法已成为管理复杂工作所用到现代化方法的核心。该方法可用于巩固所有敏捷方法，以及诸如 Holacracy 等企业治理所采用的新方法。

然而自组织这个概念经常被误解为某种“无政府主义”，如果就此听之任之，甚至不需要任何关注或引导，确实会造成这样的结果。实际上如果希望在群体内部实现行之有效的自组织，需要有人为群体成立所抱有的目的提供支持，推动群体变成一个团队，不过这首先要满足一定的条件。

自组织铁三角确立了最重要的三类条件，如果希望成功地将自组织用作一种管理工具，必需妥善处理这些条件。最初我创建这个模型是用作教学工具的，希望能通过形象的方式向学生们强调“铁三角”所包含要素的重要性。然而后来发现如果要与自组织团队合作，还可以将该模型用在实践中，确保可以顺利确定所有要素，进而获得所需结果。

模型

自组织铁三角包含三个重要条件，能对群体的自组织产生极大影响。很多组组织团队主要是通过分别管理铁三角的不同要素间接实现的。

如果缺少任何一个要素，自组织就无法实现（意味着群体不会开始讨论从事工作 / 行为的方法，工作可能完全无法完成，或只能由群体中的个别人完成），或只能以不希望的方式实现（通常位于自组织公司内的员工会抗拒管理层的命令和控制，集体游戏中的奖金计划就是一个典型的例子）。

铁三角的三个要素分别是：目标、规则，以及张力。下文将详细介绍。

图 1：自组织铁三角

首先最重要的是，必须要有一个群体中每个人都了解的明确目标。这个目标决定了群体进行自组织的具体方式：不同目标需要人们应用不同的技能和方法。存在一个共同的目标，这也是群体和团队的主要差异，如果希望让群体变为团队，那么必需通过一个目标将大家紧密联系在一起。

理想情况下，这个目标应该有吸引力，群体中的所有成员需要愿意实现它。目标可以是“含蓄”的，但如果能明确提出，让所有成员知道并用户，往往能获得更好的效果。如果群体位于一个共同的物理空间内，那么更好的做法是将目标公示在某个位置，确保所有人都能看到并了解。

越简明扼要的目标往往能获得越好的效果，这样的目标更好记，更易于理解，因而也就更吸引人。

第二个要素是组员必需遵守的一系列规则。这些规则可以通过对群体进行治理实现所定义的目标，可将其理解为整个群体需要遵守的“必须……”和“严禁……”。具体规则因不同情况而异，并且与目标一样，规则可以是“含蓄”的，但最好能进行公示。大部分情况下，这些规则会来自群体运营过程中所处的组织脉络。例如技术标准或组织所采用的某种方法论中定义的规则施加给群体的结果就是很好的例子。随后群体可以自行添加为了实现目标所需的额外规则。

与目标类似，规则也应尽可能少并且保持简单。太多或太复杂的规则很容易被部分或全部成员忽略。

最后，第三个要素是张力（我有时甚至会将其称之为压力），这是一种短期激励，可以告诉大家群体成员为何应该尽可能实现自组织的团队，进而主动促进目标的实现，而不应被动等待。

通常时间的压力就足以推动群体发展，截止日期可以创造出足够的张力。然而有时张力也可以来自挑战或奖励。

简而言之，为了让群体实现自组织（并在这个过程中变成一个团队），需要满足三个条件：一个清晰的，被所有成员理解并遵守的目标；一系列需要被成员遵守的规则；以及敦促成员积极参与而非被动等待的张力。

最后，我想提醒各位读者，提供了铁三角的三要素后，并不意味着就不再需要后续的过程或内部结构，例如由过程提供的指导，或由 Scrum 大师等教练提供的协助。无论过程或教练，所做的任何决策都应代表整个团队的利益，他们需要协助团队在规则允许的范围内推动工作进展并最终实现目标。

铁三角在实践中的应用

上文曾经提到，最初我所创建的铁三角是用作教学工具的。在意识到我的很多学生认为仅仅从字面意义上理解了“自组织”之后，只要大声地宣布“我们已经敏捷了”，就可以产生非常神奇的效果，很多问题得以顺利解决，但我希望通过一种更简单的方式向大家介绍在我看来，这种方法的真相到底是什么。我最初的想法是通过更直观的方式介绍这些我所了解的，能够帮助群体或团队顺利实现自组织而需要考虑的问题，借此让学生能从不同的视角来看待。然而很快我发现，这个模型在现实工作的实践中也大有用处。

通过组组织的方法指引整个团队，主要是通过刻意应用铁三角的不同要素，缓和地推动群体向着所需目标努力实现的。这一过程通常可由群体本身完成，例如通常可以考虑使用某种敏捷过程，或者由群体之外的管理者进行。

先来详细谈谈第一种情况，再讨论第二种情况吧。第一种情况主要发生在通过自组织团队基本原则所构建的过程开展工作的团队身上，例如最常见的就是 Scrum。

深入研究 Scrum 之后你会发现，铁三角的所有三个要素都已融入到 Scrum 框架中。在冲刺规划（Sprint Planning）阶段中，每个冲刺过程中，团队会定义需要尽力实现的冲刺目标（Sprint Goal）。Scrum 框架本身提供了团队必须遵守的一系列规则，这些规则涵盖了自组织的具体方式（“最多 9 人组成的跨职能专家团队”等）以及工作方法（“完工”的定义，每日 Scrums 等）。该框架会提供需要团队成员遵守的现有规则，例如整个公司都需要遵守的代码编写标准等，并且会在团队发现（也许是在冲刺回顾过程中）有必要时对其进行扩展。所有工作可在短期冲刺过程中完成，转瞬即逝的冲刺和随后对成果的审查（冲刺审阅）会提供必要的张力。换句话说，Scrum 为刻意塑造的自组织方法提供了所有必要的条件，并确保通过不同冲刺所执行的活动对其进行更新和适应。这种方法的反复使用有助于将群体变身为高绩效团队。

对于使用看板方法（Kanban Method）的团队，处理方法就完全不同了。这种方法也有各种规则（实际上该方法要求“所有规则必须清楚明确”），其中最明显的当然就是 WIP 限制。然而这种方法不具备任何可供使用的明确“冲刺目标”（因为根本没有冲刺），或其他类似的目标。对整个群体而言，唯一始终如一的目标是实现和优化流程所暗含的目标：以尽可能快的速度推动工作项实现进展，并始终坚守对质量的要求。通过追踪周期时间和产量等指标，这样的目标通常显得更直观，尤其是在针对某种商定或预期的绩效进行追踪时。然而要注意，这是一种过程目标，而非 Scrum 的“冲刺目标”那样与产品有关的目标。

张力也是间接的，首先来自上文提到的，实现理想“流程”的推动力和相关指标，以及每天进行的“Walk the Board”会议，团队可以在这样的会议中归纳总结因为任何原因卡住的工作项。

如果从这个角度对比 Kanban 和 Scrum，可以很清楚地了解为何更难以使用 Kanban 打造更优秀，更紧密的团队：这个框架对目标和张力的体现并不那么彻底。这样做当然也是可行的，因为无论选择哪种框架，我们都可以提供所需的三要素（举例来说，如果团队要构建一个软件产品，那么随后的发布目标就可以成为群体的激励焦点），但这些要素对 Kanban 方法本身并非必须的。

Holacracy 是自组织一种更为复杂的应用。在 Holacracy 框架中，人们被组织成不同的角色圈（Circles of Roles）（并且身担多个角色的同一人可能属于不同的圈子）。每个圈子必须有一个意图，并将其作为自己自组织的主要目标。短期目标可当作项目。工作成果会至少每周一次在战术会议（Tactical Meeting）上审查，借此提供必要的透明度和压力（Holacracy 对“张力”这个词定义了不同的含义）。每个角色和圈子的行为是由一系列规则决定的，通常每个角色有与众不同的规则，但可由任何人来完成，同时可由圈子所明确设定的策略加以引导。实际上还有一种特殊的角色：Secretary（秘书），这个角色负责追踪所有规则的执行情况。每个规则可在每月进行一次的特别治理会议（Governance Meeting）上进行更改，借此实现更高程度的自组织。圈子不仅负责管理实现目的所需的战术，而且可以根据需要更改自己的结构和规则。

此外铁三角模型也可用于为希望与团队合作并且实现自组织（而非传统的“指出并告知”命令和控制式管理）的管理者提供指导。

这种场景有一个很好的例子：在一个大型的群体中，使用自组织方式组建小型团队。通常来说，这样的大型群体无法定义自己的目标，也无法自行提供必要的规则，必须由外部实体提供这样的东西。

实际上这种情况也是铁三角模型的第一个实践运用。大约 6 年前，我当时在与一家希望转型为敏捷方法的公司合作，他们希望在团队层面的过程中实现 Scrum。开发经历面临的挑战在于：如何将包含 28 名开发者的群体划分为 4 个 Scrum 团队。我们并没有试图通过某种方式分析每个人并将其分配到某个团队中，我建议使用自组织的方法。我们坐在一起通过简短的讨论确定了所有三要素，并写了下来：

• 目标：拆分为 4 个 Scrum 团队，共同参与 X 系统的工作。
• 规则：a) 每个团队成员人数不超过 9 人；b) 团队不应主要侧重于测试或其他技术领域，所有团队都必须能提供 Backlog 中定义的功能；c) “老虎队（Tiger team）”的成员不能拆分到同一个团队中，所组建的每个团队必须至少包含老虎队的一个成员。
• 张力：30 分钟内完成拆分。

就当时情况看，目标已经非常明确了，毕竟所有开发者都已经围绕 X 系统（该组织其他部门使用的一种内部系统）工作了很久。所有人都参加过 Scrum 培训，因此他们都知道（至少在理论上）Scrum 团队到底是什么。培训过后，7 名志愿者组成了一个团队，通过一个附属项目的两次冲刺工作实践了所学到的 Scrum 知识。这个团队开始被人称作“老虎队”，开发经理担心如果这个团队继续保持现状，他们有关 Scrum 的知识将无法传播到其他团队。

我们把所有开发者叫到一间会议室里，向他们介绍我们的目标、规则，以及时间要求，随后问他们是否有什么问题。他们只提出了一个问题：如何解决 / 分配不在办公室里的人（原来那天正好有两人没在办公室）。我们很快改变了自己的问题（问他们“你觉得这个问题该如何解决”），最后他们决定给那俩人打电话，问问他们意见，但如果这个做法未能成功，将由大家代为分配，但那两人回来后可以自行决定是否要换个团队。

随后我们设置了一个 30 分钟的计数器，并与开发经理一起离开了会议室。对他来说，这个等待的过程异常艰难，他很担心这个小实验会失败，到时候他只能继续在人员资料 Excel 表格里尝试解决这个难题。当然，他的担心都没发生，等我们回到会议室后，大家已经商讨出了一个所有人都觉得满意的名单。

这样的体验并非独一无二的，大部分敏捷实践者都会建议通过这种方式建立团队（可参阅有关团队建立的这篇文章）。但对很多管理者来说，这已然是一种全新的体验，借此他们生动地了解到自组织方法的效果，以及铁三角在这一过程中的作用。他们了解到通过选取规则和目标，并应用相应的时间限制，如何能帮助整个群体规避风险（例如所有“猛虎”都在同一个团队里）并获得所需结果。

然而这个铁三角模型也可以用在其他情况中。我本人经常在围绕某个特定主题组建焦点研讨会时使用这个模型。目前我就在针对管理者群体组建这样的研讨会，研讨的主题是为何要在自己的部门实现敏捷方法，如何知道这个做法是否成功，以及如何进行度量。这个活动的预期成果是一系列客观（或至少是主体间的）指标，可以帮助大家了解自己的部门到底是变得更好还是更糟。

• 目标：用于代表部门内部不同领域改进程度的 2-3 个指标。
• 规则：a) 指标必须涵盖能激励团队使用敏捷方法的领域；b) 必须是可度量的客观标准，如果主要是为了收集意见（例如调查等），则必须使用适当的方法论。
• 张力：时间限制为 1 小时 30 分钟，如果群体没能选择出指标，则由管理委员会指定。

不同情境下的铁三角

有一个需要注意的重要事项：自组织通常只能发生在某种组织情境中。自组织方法最基本的铁三角主要关注于短期要素，需要通过这些要素让群体以某种方式实现组织。然而也要注意，铁三角的三大基本要素也需要其他要素的作用或支持（或者也可能不需要）。

群体力图实现的简洁的短期目标应当根植于更长期的愿景，当然，群体成员也必须知道并了解这样的愿景。虽然时间压力可以立即提供必要的张力，但长期范围内的激励同样重要。最后，为群体建立（或由群体建立）的规则应当与组织文化保持同步，并得到组织文化的支持。

愿景、文化，以及整体激励方式是一个长期问题，在视图创建自组织、自管理的团队（以及使用敏捷方法）时，每个组织都必须加以考虑。我们经常会看到一些公司尝试实时敏捷方法，但因为方法与现有文化和愿景不符而最终失败的情况。

最近我回访过的一家公司，他们有一个不怎么有激情的团队，但依然希望通过回顾自己过去（以及第一次）冲刺发现自己所面临的最大挑战，希望借此能自行找出解决问题的方法。当我问他们具体的行动将由谁来落实时，当时的场面一度非常尴尬，他们说当然是由经理来负责了。也许他们的整个职业生涯都处在一种严明的等级划分中，围绕命令和控制的文化使得他们根本没有意识到自己可以主动采取必要措施解决遇到的问题。实际上，一位团队成员开始争论说，作为员工，他们的所有工作应该由管理者来安排，在他看来这是良好管理机制的一种象征。很明显，他们目前的组织文化并不能有效支持敏捷方法，此时要让团队以高效的方式实现自组织，无疑是痴人说梦。

结论

自组织是一种现代化的管理工具，取代了创建团队时所用的命令和控制方法，可以引导团队实现所需结果（例如有价值的产品）。为了善用这种方法，管理者和团队必须了解对这一过程提供指导所需的三大基本要素：目标、规则、张力，并刻意选择能够帮助自己获得预期结果的要素。为确保该方法与现有文化、愿景，以及激励方式相匹配，还需要进行周全的考虑。

关于本文作者

Andy Brandt在 IT 行业有 25 年的工作经验，完成了很多壮举：他是一名程序员，一名 Unix 系统管理员，是培训讲师，是 Linux 布道师，是分析师，是项目经理（兼 PMP），是直线经理（Line manager），同时也是 Scrum 大师以及软件开发初创公司的创始人。他早在 2005 年就开始从事敏捷团队的相关工作，从 2006 年开始实践 Scrum。2010 年，他加入了 Ken Schwaber 的 Scrum.org，是任期最长的 Professional Scrum Trainers（专业 Scrum 讲师）之一。他还出版过有关敏捷的两本书（“Environment for Agile Teams”以及“Agile w Praktyce”），并撰写了很多博客文章。目前Andy 负责管理 Code Sprinters ，这是他在 2007 年创办的软件公司，经过多年发展已成为波兰最大的敏捷培训和顾问服务供应商。

作者： Andy Brandt ，阅读英文原文： The Triangle of Self Organization