写在开头：原文为Jurgen在2022年1月2日发布的关于unFIX模型介绍的第二版文章，后经本人翻译并同时发布到了UPerform优普丰数字化敏捷咨询的公众号上 - Vaycent孙维
unFIX模型它不是什么
我们如何才能改变一个组织，使得在其环境当中能够具备适应性呢？我们如何才能使得企业做好准备，在21世纪中生存和发展呢？许多模型和框架向你提出了静态的、打包好的解决方案。现在该是时候放下SAFe、LeSS、合弄制、Spotify模型和传统矩阵结构了。我们需要能将组织的灵活性提升到一个更高的新水平。因此以下即个人建议。我称它为unFIX。
该文章是于2022年5月12日更新的。第一个原始版本在这里here。
首先让我来解释，到底unFIX模型不是什么：
unFIX模型不是一个框架。“框架”要必须定义出一个支持组织的结构。但unFIX中没有必须的东西。一切都是可选的。使用“模式库”这个词反而是更准确的描述。
unFIX模式不提供任何流程。unFIX的目的是覆盖到组织设计和组织结构。你能轻易从许多别的渠道找到流程相关的建议。
unFIX模型不只适用于IT部门。unFIX中的所有模式内容可应用于团队、部门和企业。它并没有指明只适用于软件开发领域。
unFIX模型不是自顶向下的。与某些其他模型和框架不同，unFIX模型中的模式是建议采用自下而上地应用。你不能直接建造大的东西。必须从小做起。
unFIX模型不是个替代品。在其他模型和框架中也有着许多好东西，我们不应该完全丢弃它们。而是希望通过unFIX，取消原来当中的不好部分，保留所有的好特性。
以上即“到底unFIX模型不是什么”。
那么，我们现在可以开始讨论unFIX模型到底是怎样的了，开始吧。
The Crew 机组 (Team, Squad)
在unFIX模型中，Crew机组是一个通常由三到七个人组成的团队。也有可能会有更多的人，这需要根据上下文，但在大多数情况下，我不推荐这样。正如我在Management3.0该书中所解释的那样，最佳团队成员规模是五个。某些框架中建议的是七个，但我相信跨地域混合工作方式需要一个稍小一些的平均团队规模。团队成员大多专注在他们的Crew中，但若他们每周保留一小部分时间在Forum上工作（见下文），那也没关系。
以下列出七种类型的Crew：
- Value Stream Crew价值流机组
- Facilitation Crew赋能促进机组
- Capability Crew稀缺能力机组
- Governance Crew治理机组
- Platform Crew平台机组
- Experience Crew体验机组
- Partnership Crew合作伙伴机组
Crew可以是七种标准类型中的任何一种。然而，在常规业务中，大多数Crew尽可能应该是Value Stream Crew价值流机组。这些自组织的跨职能团队管理着自己的会议（计划会议、每日站会、评审会议和回顾会议）。他们管理着自己的文档和发布，同时他们会通过共创团队协议从而决定角色分工、统一规则等的团队操作。而unFIX模型允许Crew作为非价值流团队，这使得选择其他类型的Crew有了充分的理由。
作为自主的团队，这些机组Crew对其内部的角色、方法、目标、产品交付节奏、持续工作流程以及对外部依赖管理负有全责。只要Crew机组对他们提供的价值负全部责任，他们就拥有定义如何完成工作的最终决定权。没有其他人能像他们这样靠近客户体验。
有些人把这些Crew机组称为Squad、Pod、Cell等等，这都是可以的。而我更乐意使用“机组”这个词，因为该词意味着它的成员们需要共同管理这段旅程。作为船上的机组需要负责照顾船只及其乘客。作为航空的机组需要负责管理飞机及其航班。作为软件企业的机组需要负责其代码库以及发布。根据动态重新组队的原则（见下文），我们希望这些机组保持稳定，但非静态。我们不该妨碍大家不时地更换机组Crew。
The Captain 机长(Team Lead)
若进一步把船舶与飞机的形式类比，我认为是需要唯一的一名Crew成员担任Captain机长。而不是两名或者三名。这个人是与外界之间的主要联系人，对于这趟旅途中发生的任何事情，他都负有最终责任。但这并不意味着Captain应该给每个人下达命令。David Marquet在他著作的《Turn the Ship Around》书中解释道：一名好的机长事实上很少做出决定，而表现出色的机组人员知道如何自组织，机组人员们清楚他们自己的责任！
Crew中还可以有一些额外的角色，例如产品主管、技术主管等，根据上下文的产品及其外部依赖而定。不同Crew的成员可以管理不同的沟通渠道。事实上，每个Crew成员都可能是某领域的”领导者”！这没什么不对。但注意，共同责任不等于没有责任。在Base中（见下文）需要坚持，只有一个人对整个Crew在旅途中的运作负责。那个人就是Captain机长。
在Base中可能有些规则和限制，约束着哪些人可以成为Crew的Captain，因为需要考虑到技能水平，资历，任期等，Captain可以是被任命，也可以是当选的。然而，Captain从来都不是Crew成员的直线上司。 Captain不会与成员讨论职业发展、薪酬或晋升。根据上下文，此人的官方职业名称可以是产品经理、项目经理或平台经理。但无论采用哪种方式，他都是旅程的管理者，而不是Crew成员！
The Base 基地 (Tribe, Business Unit)
所有的Crew都是在一个数人至数百人的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 首席 (Management Team)
当我在写新书《Startup Scaleup Screwup》时，我与欧洲各地的许多初创公司和大规模公司（不管成功还是失败）进行过交流，他们包括Spotify、Flixbus、Wise、Typeform、Zalando、Booking、Intercom和Futurice。这让我认识到在这些年轻且成功的企业中，有一种模式没有进入我这本书中。就是有着一个Chiefs团队领导业务的简单模式。
典型的领导力团队通常由首席产品人员、首席技术人员和首席营销人员组成。但有时，角色的划分会有些不同，他们是一个四到五人的团队，而不是三人，职位和人数都会有所不同。在大多数情况下，Chiefs对其Base中的每个人都负有直线管理的责任。从这个方面看，他们是管理者团队。根据Chiefs如何划分角色，他们当中的每个管理者都会有三到二十个直接下属。通常，所有后端开发人员都会向首席技术人员汇报，而所有UX人员可能都向首席产品人员汇报，依此类推。但其上下文背景可能有所不同。
这种方式的主要好处（很久之前我就各种大规模案例中发现）是，无论Crew发生任何情况，Base都是一个稳定管理的汇报结构。 成员们也许每年在Crew之间调组五次（如有客户或员工需要的话），但没有人会改变他们的直线经理，也不会有任何管理领域需要被保护！只有Chiefs负责招聘、薪酬、晋升等。而在同时，他们可以把价值流委托给Captain或者Crew，而把职能发展委托给Chairs或者Forums（见下文）。
The Forum 论坛(Chapter, Guild)
一个由两到三个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中类似角色的人聚在一起，商定以自组织的方式完成工作，以便进行动态重组的时候可以更容易。
The Chair 主席(Moderator)
Chair是Forum的管理者，而不是成员们的管理者。为了确保充分理解，请允许我再强调一遍。 Chair 是负责主持Forum运作的人员，他并不是正在参与到Forum当中的成员们的管理者。Chair这个角色是一份兼职的工作，通常由在Base中有一定资历的人担任。他负责管理讨论和决策的运作，但他对薪酬或晋升没有任何权力。你可以说Chair是”首席（first among equals）”。
为什么在Forum中没有直线管理呢？主要原因依然是为了保持业务灵活性。我们最不想看到的就是重新引入职能部门！当Forum的领导者对成员们承担管理责任时，成员们就成为他们领土的一部分了。这会使得Forum的缩小、拆分、合并变得困难得多。此外，你最终得到的会是一个矩阵组织，而这绝对是我们不想要的结果。
unFIX 模型不是矩阵组织。当然，不同的Crew参与到不同的Forum，而他们可能有着不同的Chief作为他们的上级管理者。但是，不管你看向哪个Crew，Chief们总是在同一个Governance Crew中工作的。管理者们有着相同的目标。当Crew之间发生冲突时，它可以升级到的只有同一个管理团队！好了，矩阵再见。
规模化扩展Scaling Up
许多组织的规模都超过了数百人。在这样的环境中，员工必须越过Base基地的边界，与外部其他同事进行协同工作。因此unFIX模型提供了规模化扩展的建议，可把前文所描述的内容也以规模化的方式，扩展应用至更高层级的组织当中。
多个基地Base可在一个联盟League中协作。在个联盟League中，他们可能会形成集群Clusters（类似于Crewd机组的组成）。某些基地Base可自组织为价值流集群Value Stream Cluster，某些基地Base可作为赋能促进集群Facilitation Cluster、平台集群Platform Cluster、稀缺能力集群Capability Cluster等。联盟League有其自己的管理团队（治理集群****Governance Cluster），并围绕相互依赖的价值流或相关客户体验进行组织。
同样地，跨基地的协作可在集会 Assemblies 中进行工作（类似于在论坛Forum中的协同）。这些集会 Assemblies是以自愿为原则组织的结构，使其能够作为代表，去协调跨越单基地Base边界的工作。
我们甚至可以更进一步地说，多个联盟League可能会形成人群 Crowd。联盟League可在联合体Coalitions 中自组织地进行协作，并在大会Congresses中协调其工作。同样地，所有前文的模式在组织的更高层级上进行重复，使得unFIX模型在所有规模层级上的划分是相似的。这是一个规模化扩展方式。
但老实地说，大部分使用unFIX模型向上扩展的情况仍然是存在假设的。我们知道这些模式在小范围内起作用；因此相信他们能以同样的方式应用到大规模当中。但正如我开头所说的。最好从小处做起，从基地Base做起。
动态重新组队Dynamic Reteaming
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和Partnership Crew）。
虚拟与混合Virtual and Hybrid
奇怪的是，我的第三个灵感来源是计算机概念。虚拟化是指创建某样东西的一个虚拟版本，包括硬件、软件和接口。例如虚拟机就是模仿物理机器的软件。而虚拟团队是指，一群人好似物理坐在一起那样行动。
如果你希望有一个能够应对21世纪挑战的组织结构，那么你需要确保物理团队和虚拟团队之间几乎没有区别。你必须能够最快速度地创建虚拟团队，成员可以在任何地方专注工作，而在更大的团队维度上，他们也清楚如何在团队内部相互配合。
如今，随着更多跨地域混合工作方式的涌现，这一点变得更加重要。部分团队成员在办公室，而部分则在家或其他地方工作。团队内的成员总是在进进出出，办公室工作的日子将永不复回到原来的样子。若有人建议你说“团队必须坐在一起”，那他仍然停留在新冠病毒疫情前的时代！
在我的unFIX模型应用描述当中，虚拟化就是第三个原则。你的组织结构需要以物理和虚拟方式并存，允许人们以跨地域混合工作方式工作。你的每个虚拟团队都是由一个更大的团队创建的实例，他们可在全球范围内工作。
总结回顾Let’s Wrap It All Up
团队拓扑向我们提供了一个可以讨论不同团队类型的机会（四种基本类型，详情见上文团队拓扑章节）。由你自行决定该采用怎样的组合方式去绘制你的组织结构。对于 unFIX 模型而言，也是这样的。而我认为有必要再添加三种额外的概念，因此我提供了Crew，Forum和Base的概念。那么现在该是时候，拿出你拼乐高的能力，动手开始构建属于你的结构了。它们可以由Forum、Base等组成。
那么，如果unFIX与其他敏捷方案相比的话是如何呢？
当谈到Spotify模式时，我表示怀疑，每个实施它的企业都会遇到矩阵问题：Squad成员向不同的领导者进行汇报，而这些领导者却在不同团队中工作，他们可能会朝着不同的目标而努力。此外，Spotify模型并没有为Tribe以上的层级提供任何建议。在另一篇文章中，我指出了该模型的这两个问题 (扩展阅读: Let’s Unfix the Spotify Model)。
而SAFe框架的范围比unFIX模型大得多。它的目标受众是大型传统公司。对于年轻和较小的公司而言，SAFe显得过于庞大和官僚。除此之外，SAFe故意对直线管理避而不谈。这意味着对于现有管理架构顶层的SAFe实施，都会在矩阵组织中引发大量未知的问题。（扩展阅读：Let’s Unfix the Scaled Agile Framework)
LeSS（Large Scale Scrum）网站建议团队应该”永远在一起”地进行配合，没有预留任何的空间给到授权团队、平台团队或复杂的子系统团队。跨地域混合工作、团队拓扑、动态重组在LeSS框架中不会受到重视。在我看来，这个框架并没有很好地为应对未来作准备（扩展阅读: Let’s Unfix Large-Scale Scrum）。
合弄制（Holacracy）在八年前就被提出宣传，但现在很少有人继续在讨论它。它提供了一些创新的想法，但合弄制却因为过于古怪、抽象、技术导向而失败了。unFIX模型会更加接近目前的现实状况，并且在世界各地的组织当中被使用。因此，它更容易评估组织的变化，这将有利于实现企业的愿景（扩展阅读: Let’s Unfix Holacracy）。
最后，管理3.0又如何呢？然而，在我过往的工作中，我从来不敢提出任何具体的组织模型，仅仅是建议团队都应该作为价值提供单元。管理3.0一直都是一种管理理念与价值实践的工具箱，而不是作为一个框架。但是这篇文章的描述，unFIX模型终于弥补了管理3.0一直缺乏的结构描述，并且作为整个工具箱的纽带。
结语
我花费了十二年的时间才完成该unFIX模型。
可笑的是，在这里展示的这个解决方案（上图）显得这么明确，然而我却花了这么长时间完成它。事实上，它已经存在很多年了，我知道它在许多公司里都在成功地应用着。但在此之前似乎从来没人尝试记录、可视化地呈现，或者命名它。据我所知，本文描述的组织结构模型是最具普适落地性的。这个组织结构形式并不是全新的，但肯定没人描述出来过。
请允许我澄清一点：这文章中列出的想法，几乎没有一个是我原创的。我之所以能够绘制和描述这个模型，是因为我借鉴了许多来源的建议，这些建议在我的脑海中酝酿了多年。这幅绘画是新的；但这些想法并非如此。我也明白许多高速增长的初创企业或大规模企业都已经在实施本文中大部分的描述内容。他们也许会称为部落而非Base，称为团队而非Crew，或职能单元而非Forum。采用什么术语都没关系。我提出不同的专用名词，是因为这样可以帮助大家去区分新与旧的不同。归根结底，组织结构本质上与命名无关，而是关于意图、责任和决策。
我相信这里描述的unFIX模型通过动态重组、团队拓扑、跨地域混合工作，已经在为未来做好了准备。它使企业真正成为灵活响应变化的组织。也许你已经在别的地方看过类似的建议而知道大部分内容。这很棒，但我肯定，我绘制的这个全貌图是你前所未见的。
