unFIX – 破幻求实的敏捷组织结构变革模型 – 敏捷开发咨询顾问,Scrum认证,敏捷项目管理培训,敏捷教练

Scrum Master 中文CSM认证课程-2023年6月-线上-敏捷项目管理培训

2022年2月6日

Certified Scrum Product Owner 中文敏捷产品管理CSPO认证课程 -2023年6月-上海-敏捷产品负责人

2022年2月8日

unFIX模型

是时候取代掉SAFe、LeSS、合弄制、管理3.0、Spotify模型和矩阵组织了。我们需要将灵活性提升至全新高度，并接受跨地域联合办公成为新常态。以下是我的建议。我称它为unFIX。

我花费了十二年的时间才完成它。

可笑的是，在这里展示的这个解决方案（上图）显得这么明确，然而我却花了这么长时间完成它。事实上，它已经存在很多年了，我知道它在许多公司里都在成功地应用着。但在此之前似乎从来没人尝试记录、可视化地呈现，或者命名它。据我所知，本文描述的组织结构模型是最具普适落地性的。这个组织结构形式并不是全新的，但肯定没人描述出来过。

请允许我在文章开头提前澄清：这文章中列出的想法，几乎没有一个是我原创的。我能做的只是从许多来源中吸取灵感，在我脑海中经过多年的酝酿与混合后，绘制出这个模型。

以下，让我们开始回顾其中的一些灵感来源的建议吧。

动态重新组队（Dynamic Reteaming）

如果你问我什么是”最后一块拼图”，那么我的答案就是Heidi Helfand在同名书籍中所描述的《Dynamic Reteaming》这个概念。 Heidi的书帮助我意识到，静态的团队是不敏捷的。为什么管理者必须帮助员工容易地将自己重组成不同的团队呢？以下有至少四个理由可以进行解释：

随着外部环境变化加剧，以及层出不穷的挑战，我们需要迅速塑造新团队的能力。当你的企业遭受如数据泄漏、勒索软件攻击、新冠病毒疫情使团队工作瘫痪，或竞争对手的战略改变时，你完全没有时间让你的团队再去经历为期六周的forming、storming、norming和performing过程（Tuckman团队发展理论）。
没有办法绕过康威定律。企业会使用符合组织结构的方式来构建产品。如果你希望通过提供动态的产品与服务，来保持业务的灵活性，那么你就需要多才多艺的万能团队结构，并且尽可能地防止出现筒仓与僵化。只有灵活的团队结构才能产生灵活的产品架构。
正如”the Great Resignation“文章所示的那样，你除了需要提供出色的客户体验（CX）外，还需要负责改善员工体验（EX）。员工们当然会希望有归属感、友谊和忠诚感，但他们同时也受到好奇心、创造力和胜任力的驱使。出色的员工体验应该包括个人发展和职业发展，而不仅仅是单纯组成团队而已。
排在最后（但同样重要的一点）的是，建议去衡量团队的表现而不是个人绩效，以及奖励团队而不是个人，否则容易导致团队层面间的局部优化。你最终可能会陷入团队之间的竞争！如果你希望团队更多地关心整个客户体验，而不是他们的个人表现，则必须在跨团队协作上投入一些精力。

但不要误会我的意思。我并不是建议你每个月都将团队进行洗牌。稳定的团队确实拥有些基本的好处。但稳定并不代表一成不变！开始、停止和改变，这些对团队来说都是机会，而不是风险。这就是为什么我把Dynamic Reteaming作为本文的模型描述当中的最基本原则。

团队拓扑（Team Topologies）

第二个值得一提的灵感来源是Matthew Skelton和Manuel Pais的《Team Topologies》这本书（译者注：该书中文版名为《高效能团队模式》）。在他们工作当中，他们强调团队的责任永远不应该超过团队成员们的认知负载。团队应该总是清楚他们拥有的每部分工作，否则不断的重新学习会极大地减慢他们的速度。（正如因为我糟糕的记忆力和面对超大的投资组合，我个人每天都在承受着痛苦！）

本书还描述了四种基本的团队类型：

价值流对齐的团队，对完整价值流端到端负责（我称之为Value Stream Crew);
临时性地帮助其他团队加速的赋能型团队
（我称之为Facilitation Crew);
拥有稀有和独特技能的复杂子系统团队（我称之为Capability Crew);
提供基础设施或架构的平台团队，如同内部供应商一般（我称之为Platform Crew）。

这四种类型分类虽然简单但十分有效。在我过往的工作当中，我从来没有明确建议说，每个团队都必须是独立为他们的客户提供确定价值的单元，因此非常感激团队拓扑对我的启发，使得我更加明确自己过往的模糊想法。

我将团队拓扑列为第二个指导原则，因为”所有团队都应该拥有价值流”这种标准建议的想法，过于抽象，简单，并且对大多数企业来说是不具有可操作性的。（除此之外，我还增加了另外三种额外的团队类型，是对现有类型进行的扩充，他们分别是：Governance Crew、Experience Crew和Acquisition Crew）。

虚拟和混合（Virtual and Hybrid）

奇怪的是，我的第三个灵感来源是计算机概念。虚拟化是指创建某样东西的一个虚拟版本，包括硬件、软件和接口。例如虚拟机就是模仿物理机器的软件。而虚拟团队是指，一群人好似物理坐在一起那样行动。

如果你希望有一个能够应对21世纪挑战的组织结构，那么你需要确保物理团队和虚拟团队之间几乎没有区别。你必须能够最快速度地创建虚拟团队，成员可以在任何地方专注工作，而在更大的团队维度上，他们也清楚如何在团队内部相互配合。

如今，随着更多跨地域混合工作方式的涌现，这一点变得更加重要。部分团队成员在办公室，而部分则在家或其他地方工作。团队内的成员总是在进进出出，办公室工作的日子将永不复回到原来的样子。若有人建议你说“团队必须坐在一起”，那他仍然停留在新冠病毒疫情前的时代！

在我的unFIX模型应用描述当中，虚拟化就是第三个原则。你的组织结构需要以物理和虚拟方式并存，允许人们以跨地域混合工作方式工作。你的每个虚拟团队都是由一个更大的团队创建的实例，他们可在全球范围内工作。

那么接下来，让我们正式开始讨论这个模型吧。

The Crew (机组/战斗班/豆荚/细胞)

在unFIX模型中，Crew是一个通常由三到七个人组成的团队。也有可能会有更多的人，这需要根据上下文，但在大多数情况下，我不推荐这样。正如我在第一本书中所解释的那样，最佳团队成员规模是五个。其他框架建议是七个，但我相信跨地域混合工作方式需要一个稍小一些的平均团队规模。团队成员大多专注在他们的Crew，但若他们每周保留一小部分时间在Forum上工作（见下文），那也没关系。

以下列出七种类型的Crew：

Value Stream Crew（价值流机组）
Facilitation Crew（赋能促进机组）
Capability Crew（稀缺能力机组）
Governance Crew（治理机组）
Platform Crew（平台机组）
Experience Crew（体验机组）
Acquisition Crew（供应商管理机组）

Crew可以是七种标准类型中的任何一种。然而，在常规业务中，大多数Crew尽可能应该是Value Stream Crew。这些自组织的跨职能团队（在LeSS框架中称为特性团队-feature teams）管理着自己的会议（计划会议、每日站会、评审会议和回顾会议）。他们管理着自己的文档和发布，同时他们会通过共创团队协议从而决定角色分工、统一规则等的团队操作。与LeSS不同的是，此模型允许Crew为非价值流团队，这使得选择其他类型的Crew有了充分的理由。

作为自治的团队，这些Crew对他们的角色、使用的方法、围绕的目标、生产节奏或工作流程，以及对其他Crew依赖，肩负全部的责任。既然Crew对自己提供的价值承担全部责任，那么他们就对如何完成工作拥有最终决定权。他们是企业当中最接近客户体验的团队。

有些人称这些Crew为Squad（战斗班）、Pod（豆荚）或Cell（细胞），这都是完全没问题的。我喜欢Crew这个词，因为这个词暗示它的所有成员需要一起管理整个旅程。就像一艘船的船员一起照顾船以及乘客。航空公司的机组人员一起负责飞机以及航行。而软件公司中的Crew则需要对代码库和发布负责。遵循动态重组的原则，我们希望这些Crew是稳定但非静态的。当人们有需要切换Crew时不应该是困难的。

The Captain（机长/船长/领导者）

若进一步把船舶与飞机的形式类比，我认为是需要唯一的一名Crew成员担任Captain。而不是两名或者三名。这个人是与外界之间的主要联系人，对于这趟旅途中发生的任何事情，他都负有最终责任。但这并不意味着Captain应该给每个人下达命令。David Marquet在他著作的《Turn the Ship Around》书中解释道：一名好的船长事实上很少做出决定，而表现出色的船员知道如何自组织，船员们清楚他们自己的责任！

Crew中还可以有一些额外的角色，例如产品主管、技术主管等，根据上下文的产品及其外部依赖而定。不同Crew的成员可以管理不同的沟通渠道。事实上，每个Crew成员都可能是某领域的”领导者”！这没什么不对。但注意，共同责任不等于没有责任。在Base中（见下文）需要坚持，只有一个人对整个Crew在旅途中的运作负责。那个人就是Captain。

在Base中可能有些规则和限制，约束着哪些人可以成为Crew的Captain，因为需要考虑到技能水平，资历，任期等，Captain可以是被任命，也可以是当选的。然而，Captain从来都不是Crew成员的直线上司。 Captain不会与成员讨论职业发展、薪酬或晋升。根据上下文，此人的官方职业名称可以是产品经理、项目经理或平台经理。但无论采用哪种方式，他都是旅程的管理者，而不是Crew成员！

我们不希望在Crew中进行直线管理，因为这会使Crew的灵活性极大降低。一旦直线经理拥有某个领域，他就会保护领域，并抵制任何的改变。还有最重要的是，大多数团队成员不喜欢更换经理，因为这会导致重新建立相互信任和尊重的关系。如果你的Crew中有直线经理，你只能忽略动态重新组队这个原则了！

注意：这样做会更容易导致Captain去跟成员谈论工资和晋升机会（特别是管理经验尚浅的Captain）。我曾经犯过一个错误而深感愧疚，那就是将软件开发人员晋升为团队的Captain，而该名Captain一直致力与团队进行绩效评估。这可能是我一个不太聪明的决定。

The Base（基地/部落/事业部）

所有的Crew都是在一个10至150人的Base中运作。Base中包括了七种标准类型的Crew，他们围绕着多个价值流进行组织的。Base就像一个完全成长的独立企业。它包括产品所需的设计、开发和交付等的必要技能，更包括设计思维、DevOps、精益创业、精益制造这些思想。（由于可以从世界各地招募成员，这应该不会太难）

每个人都只属于一个Base。就像是他们的家一般。Base需要使得大家有目标感、归属感和认可感。它为所有成员提供舒适，个人安全，联系网，共享的文化，共享的工具集，以及职业机会。

理想情况下，Base覆盖某个客户的领域，而不是技术的领域。它类似于Spotify模型中的Tribe，或SAFe中的敏捷发布列车ART。然而，Base中的工作节奏和同步机制是可选的。Spotify模型中没有规定它，unFIX模型中当然也没有。所有你完全有充分理由让所有Crews异步地进行工作。（这对于松散对齐型的Base和完全隔离型的Base尤其如此）。你的Base你来决定。

Base其中一项关键性工作，就是基于客户体验去持续不断地重组自身。我们当然知道组织结构直接与产品架构挂钩。当产品架构需要改变时，组织结构也需要同样改变。因此Base需要尽其所能去支持所有的Crew保持灵活性。这就要求包括能照顾到所有Crew的最低标准和规则，使得重组尽可能变得容易。

The Chiefs (指挥官/管理团队)

当我在写新书《Startup Scaleup Screwup》时，我与欧洲各地的许多初创公司和大规模公司（不管成功还是失败）进行过交流，他们包括Spotify、Flixbus、Wise、Typeform、Zalando、Booking、Intercom和Futurice。这让我认识到在这些年轻且成功的企业中，有一种模式没有进入我这本书中。就是有着一个Chiefs团队领导业务的简单模式。

典型的领导力团队通常由首席产品人员、首席技术人员和首席营销人员组成。但有时，角色的划分会有些不同，他们是一个四到五人的团队，而不是三人，职位和人数都会有所不同。在大多数情况下，Chiefs对其Base中的每个人都负有直线管理的责任。从这个方面看，他们是管理者团队。根据Chiefs如何划分角色，他们当中的每个管理者都会有三到二十个直接下属。通常，所有后端开发人员都会向首席技术人员汇报，而所有UX人员可能都向首席产品人员汇报，依此类推。但其上下文背景可能有所不同。

这种方式的主要好处（很久之前我就各种大规模案例中发现）是，无论Crew发生任何情况，Base都是一个稳定管理的汇报结构。成员们也许每年在Crew之间调组五次（如有客户或员工需要的话），但没有人会改变他们的直线经理，也不会有任何管理领域需要被保护！只有Chiefs负责招聘、薪酬、晋升等。而在同时，他们可以把价值流委托给Captain或者Crew，而把职能发展委托给Chairs或者Forums（见下文）。

注意：在unFIX 模型中所说的直线经理与SAFe中所说的”Manager-less”是完全不同的概念。SAFe中故意不明确直线管理概念，以便它可更容易地兜售给现存的官僚层级。但由此产生的过于复杂矩阵管理可能会是一场噩梦！

作为一个领导力团队，Chiefs负责整个Base的产品、营销和技术。他们设定过程中的愿景、目标、流程、认可、奖励。（不过在实践中，他们会因为非常忙，以致他们很乐意将其中很大部分委托给Crew和Forum）。然而，就像CEO担任最高级的经营者一样，Chiefs中应该有一名成员领导着Base的整个管理团队。而Base以外的更大组织也希望有一个人可以代表整个单位。

The Forum（论坛/分会/社区）

一个由两到三个Chiefs成员组成的小团队，可以轻松管理一个十几个人的Base。但若在发展到超过50人或更多的时候，管理就会变得更加成问题。领导力团队将会委派出大部分责任。正如我之前所指出的，所有的价值流工作都回在Crew中发生，但Base内的某些事情需要沿着职能线进行协调。

Forum是一个由两个到四十个人组成的可选结构。Forum的命名类似于Spotify模型中的Chapter，但我更喜欢Forum这个名字，因为它代表着它的主要目的是让志同道合的成员聚在一起、交谈和做出决策。所以可能会有DevOps论坛、UX论坛、增长黑客论坛等。在传统组织中，项目管理办公室（PMO）可以转化成一个Forum，而在更敏捷的企业中，产品经理们也可以拥有自己的Forum。Chiefs决定着Base中需要哪些Forum，因为Forum在组织结构中发挥着正式作用。

Chiefs可以将工作委托给Forum，例如标准化、模板、工具集、基础架构、个人发展、跨团队协调等。他们可期望Base中的每位成员成为一个或多个Forum的成员，并参与到其职能领域中至关重要的对话和决策。Forum的作用是成为Crew之间的连接组织。

现在，若你认为这与Spotify模型中的Chapter相同的话，让我澄清他们间一个关键的区别：Forum中没有直线管理！招聘、薪酬、职业发展和绩效考核都不是Forum的任务。Forum的目的是让Base中类似角色的人聚在一起，商定以自组织的方式完成工作，以便进行动态重组的时候可以更容易。

例如，当两名Crew成员想要换地方工作而导致那两个Crew绩效受损的时候，他们的Forum应该指出其根本原因以及对此可以做些什么。是否他们的入职效率不够？抑或两名成员之间的工作方式差别太大？抑或他们的Crew文化优先于Base的文化？Forum的目标是优化Base，高于优化单个Crew。

The Chair（首席/主席）

Chair是Forum的管理者，而不是成员们的管理者。为了确保充分理解，请允许我再强调一遍。 Chair 是负责主持Forum运作的人员，他并不是正在参与到Forum当中的成员们的管理者。Chair这个角色是一份兼职的工作，通常由在Base中有一定资历的人担任。他负责管理讨论和决策的运作，但他对薪酬或晋升没有任何权力。你可以说Chair是“首席（first among equals）”。

为什么在Forum中没有直线管理呢？主要原因依然是为了保持业务灵活性。我们最不想看到的就是重新引入职能部门！当Forum的领导者对成员们承担管理责任时，成员们就成为他们领土的一部分了。这会使得Forum的缩小、拆分、合并变得困难得多。此外，你最终得到的会是一个矩阵组织，而这绝对是我们不想要的结果。

我曾经在矩阵组织下的团队中工作过。我的项目经理来自组织的某个部门，而我的职能经理则在企业的另一部分工作。在矩阵中，这两个人通常甚至都不认识对方，他们朝着完全不同的方向努力。在我的角度而言，他们的管理在以水平相反的方向消失。幸运的是，我没有一直忍受它，但我知道许多其他人在遭受着痛苦。因此我有充分的理由相信矩阵组织的名声并不太好。

unFIX 模型不是矩阵组织。当然，不同的Crew参与到不同的Forum，而他们可能有着不同的Chief作为他们的上级管理者。但是，不管你看向哪个Crew，Chief们总是在同一个Governance Crew中工作的。管理者们有着相同的目标。当Crew之间发生冲突时，它可以升级到的只有同一个管理团队！好了，矩阵再见。

The Super-Base（超级基地/支舰队）

在许多组织当中都超过150人。在这样的环境中，大家不得不与与同事们之间协作，这超过了一个Base的边界上限。

这样的处理方法就是将多个Base组合成一个Super-Base或叫2级Base。 Super-Base拥有它自己的管理团队，并且它的组织形式是围绕着相互依赖的价值流或相关的客户体验开展。例如，具有B2C属性的多个Base可以包含在一个Super-Base中，而具有B2B属性的多个Base可以包含在另一个Super-Base中。

该结构类似于SAFe中的解决方案层级，包含着多个ART敏捷发布列车，他们为为相同或类似的客户交付价值。（而Spotify模型中没有类似的结构描述）

The Super-Forum（超级协会/超级社区）

最后，若需要跨Base协作，有一种非正式对标准解决方案，他们通常被称为实践社区（CoP）或兴趣社区（CoI）或卓越中心（CoE）。这些非正式的2级Forum是采用志愿者的组织结构，使成员能够跨越单个Base的边界（甚至可能是多个Super-Bases）的方式进行协调和工作。

Super-Forums通常自下而上地涌现的，它们通常服务于职能、技术、地域、市场等的领域类似的多个Forum。

Super-Forums是否有可能跨多个Base呢？答案是肯定的。但这需要这个Super-Forums能够得到参与其中的所有Base的Chiefs的正式认可。而这些不同Base当中的Forum将不得不将他们自己的某些权力转让给这个Super-Forums，让他们都将成为其的一部分。

总结回顾

团队拓扑向我们提供了一个可以讨论不同团队类型的机会（四种基本类型，详情见上文团队拓扑章节）。由你自行决定该采用怎样的组合方式去绘制你的组织结构。对于 unFIX 模型而言，也是这样的。而我认为有必要再添加三种额外的概念，因此我提供了Crew，Forum和Base的概念。那么现在该是时候，拿出你拼乐高的能力，动手开始构建属于你的结构了。它们可以由Forum、Base等组成。

那么，如果unFIX与其他敏捷方案相比的话是如何呢？

当谈到Spotify模式时，我表示怀疑，每个实施它的企业都会遇到矩阵问题：Squad成员向不同的领导者进行汇报，而这些领导者却在不同团队中工作，他们可能会朝着不同的目标而努力。此外，Spotify模型并没有为Tribe以上的层级提供任何建议。在前文中，我指出了该模型的这两个问题。

而SAFe框架的范围比unFIX模型大得多。它的目标受众是大型传统公司。对于年轻和较小的公司而言，SAFe显得过于庞大和官僚。除此之外，SAFe故意对直线管理避而不谈。这意味着对于现有管理架构顶层的SAFe实施，都会在矩阵组织中引发大量未知的问题。（扩展阅读：Let’s Unfix the Scaled Agile Framework)

LeSS（Large Scale Scrum）网站建议团队应该”永远在一起”地进行配合，没有预留任何的空间给到授权团队、平台团队或复杂的子系统团队。跨地域混合工作、团队拓扑、动态重组在LeSS框架中不会受到重视。在我看来，这个框架并没有很好地为应对未来作准备。

合弄制（Holacracy）在八年前就被提出宣传，但现在很少有人继续在讨论它。它提供了一些创新的想法，但合弄制却因为过于古怪、抽象、技术导向而失败了。unFIX模型会更加接近目前的现实状况，并且在世界各地的组织当中被使用。因此，它更容易评估组织的变化，这将有利于实现企业的愿景。

最后，管理3.0又如何呢？然而，在我过往的工作中，我从来不敢提出任何具体的组织模型，仅仅是建议团队都应该作为价值提供单元。管理3.0一直都是一种管理理念与价值实践的工具箱，而不是作为一个框架。但是这篇文章的描述，unFIX模型终于弥补了管理3.0一直缺乏的结构描述，并且作为整个工具箱的纽带。

结语

如我前文所说，这个全貌图是新的，但想法本身不新。我也明白许多高速增长的初创企业或大规模企业都已经在实施本文中大部分的描述内容。他们也许会称为部落而非Base，称为团队而非Crew，或职能单元而非Forum。采用什么术语都没关系。我提出不同的专用名词，是因为这样可以帮助大家去区分新与旧的不同。归根结底，组织结构本质上与命名无关，而是关于意图、责任和决策。

我相信这里描述的unFIX模型通过动态重组、团队拓扑、跨地域混合工作，已经在为未来做好了准备。它使企业真正成为灵活响应变化的组织。也许你已经在别的地方看过类似的建议而知道大部分内容。这很棒，但我肯定，我绘制的这个全貌图是你前所未见的。

unFIX – 破幻求实的敏捷组织结构变革模型