自组织的基础-白红宇

自组织的基础

阅读量：5825 次

发布时间：2019-06-18

本文共 10307 字，大约阅读时间需要 34 分钟。

自组织团队理念被称为敏捷开发的秘密武器。本文试图系统化如何思考以及如何发展健康的自组织。

引言

我第一次开始思考软件开发团队中的自组织是在2011年。当时，除了如果你渴望敏捷，你应该拥抱它之外，真的没有多少相关文献。在如何（作为经理/教练/领袖）促进和培养自组织方面几乎没有什么建议，而且大部分建议是这几个方面：

不要指派角色\

不要指派领袖\

不要指派任务\

不要规定方式方法\

有很多不要，当然意识到问题的反模式肯定是有用的，但是很大程度上却没有回答出你究竟怎么做来支持自组织

如今，你可以更容易地在互联网上搜索到敏捷团队的自组织建议，例如和，但是在我看来这个问题还是未被描述清楚且有待完善。我在这片文章中描述的模型并非完全独特的，但是我认为与其它描述相比，它更加的清晰，专注。我希望这片文章可以作为灵感，也许可以作为讨论如何在组织内最佳利用自组织的起点。

什么和为什么

与定义一群人截然不同，人们对团队的定义各不相同。简洁但有用的定义是：

团队是一群才能和技能互补，并有着共同目标的群体。\

这是一个通用的定义，并且没有特指敏捷或者软件开发团队。

有时自组织、自主、自管理团队之间是有区别的。更复杂的是不同的人对这些术语的定义不同。本文的重点不是区分它们之间的不同。但是我写这篇文章的时候也做了一些假设：本文讨论的环境是有数个团队有着共同的或者至少相关的目的，在这个环境中存在自组织团队，以及存在围绕团队的管理架构。即团队不是自发聚集的，他们有一定程度的相关依赖性。

那么，从业务和管理的角度来看，为什么拥有自组织团队是一个好主意？虽然被认为有着完善的价值和被授权的员工这种现代化组织的确很好，但是真实原因却更加的实际；自组织是一种强大的管理策略，将会带来更好的结果，因为：

为了向商业交付重要价值，将端到端的所有权指派给团队将激发人们更加优秀，最终将带来更高质量的可交付成果。\

局部决策意味着更快同样更好的决策，最终将带来更快的交付，这种方式更适合目的。\

与始终在不同任务之间切换截然不同，由于没有（或者至少很少）的交接工作，当团队对端到端负责时，你会完成的更多且更快，因为你只需要关注一件事。\

除了纯粹的商务术语中的改进成果之外，运作良好、自组织的敏捷团队还应该展示一些特性或者价值，例如：

承诺（Commitment）\

勇气（Courage）\

问责制（Accountability）\

诚实（Honesty）\

透明（Transparency）\

信任（Trust）\

公开（Openness）\

真实（Authenticity）\

尊重（Respect）\

沟通（Communication）\

反馈（Feedback）\

简洁（Simplicity）\

有些文章暗示培养自组织的方法就是确保这些特性存在团队之中。但是，我想争辩的是这些特性更多的是运行良好、自组织的证明而不是培养自组织的良方。相反我想说必须有一套组织的先决条件，才有可能实现自组织。然后，考虑到这些先决条件，我们还需要铭记健康的组织在很大程度上依赖团队成员。下图试图说明这一点，即首先你需要有合适的组织资产基线，我称之为基础。在这之上你需要确保拥有健康的团队和面面俱到的个人。只有这样我们才能实现健康的自组织，拥有真正的团队价值观和行为，就像上面列出的一样。

让我们更详细地看看模型的不同层，首先从基础层开始。

基础

在基础层，我们发现如下组织基础架构:

目标与效用\

知识与学习\

沟通与反馈\

工作方式与决策制定\

高标准与期望\

我们简要地谈一下每一点。

目标与效用

为了得到健康的自组织，你必须有一个为之奋斗的伟大目标，并知道如何以正在进行的方式度量团队产量和服务的效用。

在经济学中，最简单定义效用的方式是货币的数量，人们愿意支付商品或者服务的货币数量。过去几年，在敏捷中非常流行使用延误成本作为价值的度量指标，可能也是效用的最佳代理了。换句话说，团队必须有一种严格的经济术语可以用来确定其有效程度。度量价值/效用并非没有挑战：

很难从个人用户故事层面推断延误/价值成本。通常你至少需要上升一个层面。\

甚至即使你上升一步，可靠地估算延误/价值成本也不是那么容易。\

而计算组件团队和基础设施团队的延误/价值成本计算就更加不容易。\

在网站上有一些指示有助于你思考价值和计算延误成本的紧迫性，但是为了关联你们具体的商业环境，你还需要进行大量的关联工作。

除了理解效用，团队拥有一个为之奋斗的伟大的高层次的目标同样非常重要。优秀的高层次的目标应该包括：

意图和最终状态——专注于团队工作的“为什么”和需要完成的变化。在软件开发中，通常按照客户和业务的机会实现表述。\

主要努力——必须有发布一个完整产品或者进行显著变化的详细细节。定义一个努力的主要努力内容，通常以关键特性列表的方式提问，这些关键特性旨在解决手头问题。\

这类似于美国海军陆战队和其他军事机构的任务指令结构形式。

许多组织在经济成果之上定义目标：收益、收益率等等。然而，作为促进自组织的手段，这种目标完全不起作用。作为能够起到有效指导的目标，你需要觉得你（作为一个团队或个人）对能否完成目标有着巨大的影响。这与你依据顶级 KPI定义目标不同。目标应该是一些你关心的，觉得兴奋和有挑战的事情。

在目标有所成就方面，我见过的一个最佳的例子大约是在20年前；那时软件还是以纸盒的方式发布。那时我还在 Rational Software工作，从事软件开发工具，Rational其中一个产品 UML建模工具 Rational Rose非常的出名。那时，微软是当时公认的首屈一指的高科技超级独角兽。总之，Rational跟微软做了笔交易，开发 Rational Rose的变体——Microsoft Visual Modeler，作为 Visual Basic 5.0 / Visual Studio 97的一部分发布。留给我们完成产品的时间表非常具有攻击性，从事这项工作的团队是最近才组建的，成员分布在美国和瑞典。完成这项工作不是一件容易的事情。让团队走到一起并作为一个整体的高层次目标可以简单表示为：

\

与 Visual Studio 97一起发布
\

这是一个伟大的目标，因为它即让人兴奋和渴望，同时对开发团队而言也具有挑战性。并且也与 Rational的商业目标有关联，能够最大化暴露给使用 Visual Basic的企业开发人员，能够实现引人注目的提升销售。最后事实证明尽管与 Microsoft CD作为一体发布不是一个正确的决定，不如将 Visual Modeler作为软件下载发布好。然而在完成产品方面，这是一个伟大的目标。

还有更多有关如何使用目标和度量（效用）的内容，但是我想在以后的博客中详细探讨。

知识与学习

有时人们认为为了能够自组织，从一开始团队就应该具备所有必须的知识。在现实中我们完全具备大部分必须的知识。剩下的可以在过程中学习。因此，每个团队必须理解：

A．我们知道的事情。\

B．我们意识到目前我们不知道，但是为了成功我们必须知道的事情。\

除此之外，还有一些让人讨厌的知识范畴，可以归类为：

C．我们没有意识到我们不知道，但是为了成功又必须知道的事情。\

因此，要取得成功我们需要 B和C范畴的学习方法，同时我们还需要一种方法能够意识到 C范畴。为了实现这一目标，团队需要帮助、时间，或许资金。从本质上来讲如果不考虑太多的细节，提供适当支持的责任应该由围绕团队的组织制度负责。比如：

干系人/商业人士的参与可以根据需要在业务领域培训团队，为此他们正在创建解决方案。\

技术监督从而确保团队知道标准、设计模式以及团队将接触的任何现有解决方案的设计意图。这种监督不给人命令式的印象或者这将会拖延团队工作的方式完成非常重要。与建立正式批准相比，负责监督的人应该实践自己去看，比如出席 Sprint评审、旁听设计研讨会等等。这样你可以联系上下文培训团队，久而久之它会变得越来越自给自足。\

时间、资金和各级管理层的道义支持从而确保团队有时间学习必须的知识。包括整个组织专用的学习日和用于培训的个人预算。\

有学习自然有反馈，接下来我们讨论反馈。

沟通与反馈

自组织团队将不断适应他们所构建的和打算构建的，以及如何去实现。为了做到这一点，团队必须得到工作的反馈。其反馈应该是：

我们是否构建了正确的事情，即我们解决的问题是否是真的需要解决的问题，或者我们是否误解了真实需求？我们可以把这看成是从我们所构建系统的干系人/用户那得到的反馈。\

我们是否采用了最佳的工作方式，即是否有能够变得更好的改变？我们可以把这看成是流程反馈。\

我们是否正确地构建事情，即我们构建的解决方案是否有正确的质量属性，故障等级是否是可容忍的？我们可以把这看成是技术反馈。\

反馈是敏捷方法的心脏，这并非是巧合。敏捷团队通常定期向干系人/商业人士验证/评审，从而获得所构建解决方案的反馈；他们举行回顾会议以评估工作方式，使用技术实践比如自动化测试和持续集成来获得持续的技术反馈提要。

单个团队内的沟通本身就是一个挑战，但是在这个模型中我们将在随后的人们层讨论这一问题。然而，在多团队情境中，你可以充分持续观察团队之间的沟通。有意义的沟通的发生通常需要具备沟通机制和共享的本体。如果你有多个协作团队并且拥有共同的历史，那么很大程度上沟通将自然而然的发生。另外一方面如果你有许多团队但没有共同的历史，团队可能需要支持，以建立沟通机制和共享的本体。如果你的团队分布在和/或属于不同的组织，这会进一步放大这个问题，比如你与外包合作伙伴合作。

实际上，这意味着你需要建立会议时间表，并需要确保有足够的空间和技术运行会议，比如分布式会议。同时你还需要建立一种文化，使人们不会犹豫寻找其他团队的帮助或者为共同利益进行讨论。为了做到这一点，必须建立存在哪些团队，他们从事什么，和如何联系他们的目录。

如果您的组织正从传统的层级组织转变，那么它将要求人们学习新的行为。当你拥有自组织团队时，协调和请求将在点到点之间处理，而不是贯穿项目上下或者各级管理层。根据我的经验，你需要明确告诉团队成员帮助他人是他们的职责。在一个大型组织内，这意味着有时你会求助一些你不认识的人，并与其沟通。对于团队的某些成员而言，这会让他们一开始感觉不舒服，但是根据我的经验，一旦你打破密封层，人们都会领会直接沟通的优势。你有时看到的反模式是 Scrum master/敏捷教练代表团队处理了所有的外部沟通。在我看来，这是向传统项目管理角色后退的不幸的一步。

共享本体应该以某种方式记录在案。例如，一种可能性是在领域模型中捕捉商业领域中最重要的概念。但是这很容易造成过犹不及，因为如果某个模型太大或者太详细，很快其就会变成废词和/或者难以理解，因此请保持精益。高等级的架构描述和指导原则可以在技术领域起到类似的作用。这些描述的目的是提高对所谈论的有趣事情的关注，而不是详细地指定事情。

工作方式与决策制定

任何智力活动都需要做决策，比如软件开发。有时做决策很简单，有时却很复杂。有时决策会影响局部性质，有时却会影响全局性质。在职责分工明确的层级模型中（至少在理论上）很容易理解谁做哪种类型的决策和在哪做决策。但是当涉及自组织团队时，谁做决策就不是那么明显了。

此外，作为团队有效地工作你需要对工作完成度有一定的共识，即工作方式。自组织团队对定义这种工作方式有一定程度的自由，但是在较大型组织中，还需要跨多个团队达成一致的共识，或者甚至是跨整个组织作为一个整体。本质上来讲，达成共识的工作方式应该有助于个人和团队之间的协作，并能够确保组织内在正确层面做出高品质和及时的决策。

即便如此，仍然需要制定不同类型的决策。关注软件开发的决策主要分布在三个不同的领域：

业务领域\

技术领域\

工作方式领域\

对于每个领域，提出不同类型的决策在哪个层面制定的分类非常有用。目标应该分为在局部做小经济和小型组织影响的决策，和以协调一致的方式做大型组织影响或者较大经济后果的决定，同时还应该避免很长的交付周期和决策僵局。

在敏捷组织内多个团队之间不同层面做决策的例子可能是：

个人\

团队\

项目（多个团队致力于同一解决方案）\

组织\

考虑这两个维度，我们可以排列一个矩阵，帮助理解应该在哪里做决策，如下：

	业务	技术	工作方式
个人
团队
项目
组织

不同的组织矩阵内容是不一样的，但是它应该能够回答如下问题：

谁决定可接受的工作时间和在家工作的政策是什么？\

谁决定某种技术用不用？\

每个层面可以独立决定的预算？\

哪些设备可以提供给团队和个人？\

哪些工具可用？\

完成的定义是什么？\

解决方案能够解决的范围和不能解决的范围？\

发布计划是什么？\

我们如何测试？\

我们怎么做代码/设计评审？\

一旦对某一类决策的制定层面达成共识，无论决策来自哪一层面，确保你在制定决策时是敏捷的特别重要，否则它会令事情变慢，阻碍进度。这在个人和团队层面则不是太大的问题，因为决策可以按需制定。但在项目和组织层面，通常需要正式的决策讨论会，且是计划性的会议。在项目层面，这种讨论会将有团队和项目管理代表出席。在组织层面，将由各级管理部门制定决策，但是应该视情况咨询项目和团队的意见。最后是紧凑但频繁的会议，而不是冗长、低频率会议，从而确保事情顺畅发展。项目层面的决策主体更应该每日召开会议，而组织层面的决策主体的频率可以稍微低点。

决策的制定是一门非常值得单独讨论的主题。在偏离本文主题太远之前我希望能够及早收回话题。

高标准与期望

自组织并不意味着没有效能需求。类似清晰且具有挑战的目标，建立卓越的文化，或者追求卓越的文化同样非常重要。那么你如何在团队内实现呢？几年前我参加了一个讲座，是由瑞典的一个主导足球俱乐部教练举办的（他们刚刚赢得那年联赛冠军）。讲座谈到了如何在一个相当多样化的群体里创建追求卓越的共享的渴望。其中一些引用让我久久不能释怀：

“做简单的事情，并每天做”，即以高品质\

“好的总是充满乐趣，但充满乐趣的不一定是好的”\

就我的理解而言，这些是团队内的座右铭，为了实现：

建立纪律和关注细节\

建立不懈地专注每件事的品质和成果\

我认为这种心态的影响完全可以应用到软件开发团队中，因为他们同样面向细节和品质，比如在如下方面：

代码品质\

适当的自动化，比如测试和构建\

为自己设立具有挑战性但可实现的目标\

交付承诺\

他们是如何不断努力变得更好\

在这方面我同样认为足球团队的教练可以在软件开发团队中扮演类似的角色。即激励并挑战团队追求卓越，或者为团队建立合适的座右铭。

现在我们更详细地看看本模型中自组织的人们层。

人

尽管我们有技术，尽管有不同的技术可以用于获取需求、估算、或者管理团队工作等等，但是在团队内仍然需要人的协作使事情发生。当如此考虑时，把团队看成一个整体，把所有团队成员从团队分离看成个体非常重要。为了从团队中得到优秀结果，你必须确保同时拥有积极的个体和伟大的团队动力。

积极的个体

我心酸地体会到至少在相当大的程度上，积极性是个人责任。几年前我因为严格的经济原因而不是对角色成功的渴望，很长时间紧紧抓着一个职位。长话短说，你个人认为的缺乏动力在别人看来就是糟糕的心态。这绝不会让别人觉得你是价值贡献者或者适合为未来投资的对象。对此我的意见是你不能指望你的老板或者职场的其他人激励你。毕竟，你才需要对自己的未来负责。再明显不过了，是吧。组织能做的是创建一个个体能够自我激励的环境。

下图显示了内在动力的三个必要成分。

这一激励模型来自 Dan Pink的心理研究正文，基于他的畅销书 Drive和 TED演讲，它们都是同一题材。上图中的自主（Autonomy）、能力（Competence）、和关联（Relatedness）就是 Dan Pink所谓的自主、精通（Mastery）和目的（Purpose）。

你绝对不该做的就是创建愚蠢的繁文缛节流程，这会打击个体的积极性。组织应该意识到使人丧失积极性远比让人获得积极性更加容易的重要性。那么，你能做些什么从而助力积极性？正如本节开头所述，我信奉的是内在动机基本上是个人责任。即个人必须将自己置于能够自我激励的位置。组织需要做的是了解并支持这一机制，并创建一种能够助力内在动机的文化。我们将在下一章节详细探讨这一问题。

团体发展

在团体发展和团队动力方面有很多书籍和研究。有些文章比其它文章在心理研究方面更加有理有据。Susan Wheelan提出了一个有理有据且新颖的模型，如下图所示。

当你将上文描述的内在动力模型覆盖在这个模型上时，你可以发现一个重点，团队发展的早期阶段就是找出共同基础和工作协议，从而让所有成员有可能通过以下方式实现内在激励：

自主——意味着有足够的水平能够影响你的工作方式和工作内容。Dan Pink将自主看成是选择团队、任务、时间和技术的自由，即与谁合作、干什么、何时做和如何做。敏捷充分内置了这一属性，在敏捷中团队被允许自行决策这些事情，只要他们的决策不会消极影响他人。然而，自主并不意味着完全独立或者你可以不考虑其他人的需求任意妄为。敏捷与传统实践相比能够提高自主的案例包括：团队成员自愿参加任务而不是被分配，团队成员可以跟喜欢的其它团队的成员配对，与干系人的直接沟通，团队决定自己开发实践，等等。\

能力/精通——这意味着你感觉能够胜任，并且做的很好。这需要对你的工作有一个合适的挑战度，需要考虑你的个人知识和学习的意愿。但是这是不够的，因为最重要的因素觉得能够胜任是积极的反馈，即积极的反馈加速激励而消极的反馈会减速激励。因此确保你建立的机制能够给团队或者个人更多显著的积极而非消极的反馈。除了常规管理和干系人反馈外，研究如何刺激同伴为荣誉反馈或者类似的机制。\

关联/目的——正如在基础之下讨论的这意味着对组织/团队目标的强烈支持（buy-in），尤其是涉及到为什么和期望的最终状态时。同时这也意味着你觉得与合作的同事相关联，你们有着共同需要达成目标的愿望。如果为什么和最终状态是明确的，而良好的沟通和有能力的人还是不能获得支持，那么他们可能是在错误的地方。\

虽然敏捷教练可以促进，并对其中一些事情能够产生影响，但是最终对组织功能中的团队和个人运行良好负责的还是组织的各级管理部门。我的建议是简单地跟团队谈这些事情，或许可以作为回顾扩展的一部分。不需要那么复杂，但是通过展示给他们和小组讨论在团队内提高对这些机制的认识，在我看来有助于事情的发展。我不会直接跟新成立的团队谈这些，因为如果他们有至少一个月的合作经验，你将能够从讨论中获得更多有价值的内容。这里描述的简单的团队发展和个人激励模型可以用于指导。

成果

模型的最后一层是你在有足够合适的前两层的基础上希望得到的成果。我认为成功的自组织有三个主要成果

价值（value）\

平衡（balance）\

结果（results）\

价值

这里所描述的模型并不意味着任何理想的敏捷价值可以在不考虑它们的情况下自动出现。相反它表明如果在模型中你没有合适的基础层和人们层，你就不要指望它们的出现。

敏捷价值通常包括上文列出的，即：

承诺\

勇气\

问责制\

诚实\

透明\

信任\

公开\

真实\

尊重\

沟通\

反馈\

简洁\

让团队意识到这些价值和为什么重要是敏捷教练的职责。除非你非常确信你在做什么，否则我会非常小心地参与旨在促进信任、诚实、真实性等发展的明确干预或者小组练习。格外小心的理由是你这么做时总是会有风险对个人造成不可逆转的伤害。我认为这个精力更应该用在确保模型中下面两层在合适的位置，从而确保团队可以成功交付高品质的价值。没有什么能够比胜利更能建立团队精神。

当然，各级管理部门在文化的发展和组织内的价值观中同样发挥着重要的作用。如果行政决策者被视为不诚实那么可能一切都是虚假的，即为了促进价值的成长，你需要高层领导以身作则。

平衡

平衡是指自组织真正的含义：团队有权且有能力不断做出权衡。软件开发团队中包含的权衡如下图所示：

你也许会冒出团队为了展示自我需要的更多的权衡。这也是我从 Rashina Hoda的博士论文中学到的。

结果

归根结底都是有关达成目标与最大化效用的结果。正如本文一开始建议的，自组织是一个强大的管理策略，一个健康的自组织仅仅比严格的指导团队拥有更好的交付成果的机会。

复杂适应系统注记

有人建议你可以认为自组织团队是复杂理论中的复杂适应系统。我必须承认起初我对此也很好奇。但是一段时间后我发现这是个死胡同，并不能帮助你理解团队工作方式。敏捷团队其交互和自适应都是复杂的这是个事实。但是，如果我们研究一下复杂适应系统的定义，它应该有下述属性：

交互和关系的复杂、动态网络\

自适应的行为变化是经验的结果\

主要原则是：\

自组织\

涌现（emergence）\

如果我们仅仅看这些词语并把它们映射到敏捷团队中，你脑中很容易出现这样的想法：

i. 我们想要自组织团队

ii. 一群人放任不管，展示应急行为

iii. 因此我们可以认为自组织团队就是复杂适应系统

在我看来，这非常具有误导性，因为复杂理论中的复杂适应系统同样意味着：

复杂适应系统中的个体 agent遵循一组简单的规则，系统作为一个整体是复杂的，而不是个体 agent。\

复杂适应系统中有大量的个体 agent，系统中agent的简单交互可以自组织，并以复杂（不容易预测）的方式展示应急行为。\

这与敏捷团队完全不同，在敏捷团队中我们只有相当少的 agent（人），而每个个体 agent之间的交互和行为非常复杂，记住我们面对的是人，而不是蜜蜂。

总之，复杂适应系统不能作为自组织敏捷团队的有效模型，即使可以它也不能帮助我们理解如何在职场支持和培养自组织。

结论

有经验的敏捷领袖和教练应该熟悉本文中讨论的大多数内容。此外，本文并没有包含太多可以直接用于促进自组织的具体促进技术和练习。我希望你能够将此模型作为一个工具，研究自己的组织，看看在合适的位置是否存在必须的部分，从而实现健康的自组织。当然这只是一个理论，但是我希望你会发现这是一个好的，至少是有用的理论。

这里有张图，是我有关自组织的大统一理论：

尽管该模型表明在关注更高层的项目之前你应该关注底部项目，但是那里没有严格的顺序。在实际应用中，你会发现你需要并行和迭代关注这些项目。这就是为什么箭头是双向的。

关于作者

Svante Lidman在创业公司和大型国际企业比如微软、爱立信和 Rational Software拥有超过25年的软件开发和软件开发团队的管理/指导经验。2008年以来，Svante一直从事顾问工作，主要帮助软件开发组织转向精益/敏捷。2010-2012年间，他曾在 Scandinavia参与其中一个最大的精益/敏捷转型的启动和推进工作。