业务敏捷的组织设计模型

前面介绍的各种创新型组织模型都有其独特性。阿米巴从企业经营的角 度来设计，每个阿米巴是一个独立的经营实体，不同阿采巴之间做财务结算，旨在实现整个企业的营收最大化和成本最小化。合弄制是对未来组织的 一种大胆、前卫的设计，将企业的金字塔结构彻底、完全地颠覆，连 CEO 对企业也没有控制权，这样理想的“乌托邦”理论在绝大多数的企业里难以 落地，目前只在小范围有零星、成功的案例，有其上下文特有的成功条件。 青色组织是一种未来组织的发展理念，没有成形的组织模式设计。部落制是 Spotify 的外部敏捷顾问对 Spotify 工作模式的总结，可以说是 Spotify 自有的 设计，其成功建立在 Spotify 公司自身的文化基础之上。虽然很多公司也宣称 在使用部落制，但是更多的是取了 Spotify 的“部落”和“小队”的名字和组 成形式，与 Spotify 本身原有的部落制已经没有多少吻合。

这几种创新型组织模型也有共通性。例如，个人的价值得到绽放是青色组织和阿米巴的核心特征；小团队是阿米巴和部落制的核心特征；自组织是这些组织模型的共同特征。业务敏捷的目的是让整个组织能够快速捕捉市场机会，对外界的变化迅速做出响应。从我们辅导众多企业敏捷转型的经验来看，没有两家公司在转型过程中采用了完全一样的组织结构，每个企业都基于其战略和自身的现实进行了特有的设计。但是，万变不离其宗，我们经过对众多企业敏捷转型的经验进行总结，同时梳理并整合前述创新型组织模式后，将这些视角抽象提炼成一个完整的框架，构成了业务敏捷组织模型，如图 1所示。

业务敏捷的组织模型包括 4 个部分：

• 客户和用户；
• 敏捷团队；
• 赋能平台；
• 领导者；
• 生态合作伙伴圈。

图1-业务敏捷组织模型

1 .客户和用户

对于任何一个组织而言，其客户和用户是它们得以存在的根本意义。客 户是购买产品的人，用户是使用产品的人。客户和用户可能是同一批人，也 可能不是。例如儿童教育产品，客户是家长，用户是孩子；对于 To B 的产 品，客户是企业，用户是采购产品的企业的内部员工。对于客户和用户不等 同的产品或服务来说，组织在创设产品或服务时，既需要满足客户的要求， 也需要满足用户的要求。组织在交付产品或服务后，既需要经营客户，也需 要运营用户。客户和用户是组织的生命之源。

在传统的职能型组织结构中，往往只有与客户或用户直接打交道的业务 部门与客户或用户深度沟通，造成需求传递链条变长，传递过程中需求产生 失真；在产品发布后，客户对产品的反馈声音传递到公司内部各个环节链条变长，传递过程中又产生新的失真。因此团队对客户的需求及产品反馈的理解往往与客户的真实需求有偏差，团队针对有偏差的需求进行产品设计和实现会产生极大的浪费。因此必须由敏捷团队直接与客户或用户沟通，理解客户的场景和需求。

此外，在当今时代，同质化产品竞争激烈，跨界商业模式层出不穷，业务环境动荡，敏捷团队除了直接对接客户获取客户的一手需求，还必须让客户和用户参与到产品设计的过程中来，并在产品创设及运营过程中保持与客户和用户的深度互动。只有这样，组织才能够快速地洞察客户和用户的最新需求，并且高效地交付给客户和用户，从而能够长期保持产品或服务与客户和用户的黏度。

在用户参与产品设计和运营过程这方面，小米做得很好。小米最先开始做 MIUI 时团队只有 20 多人。但是小米联合创始人黎万强却有一个疯狂的想法：建立一个 10 万人的互联网开发团队。这听上去简直离谱，就算是世界上员工数最多的公司，开发人员也不太可能达到 10 万人。为此，小米设计了“橙色星期五”的互联网开发模式，要求 MIUI 团队每天抽空在论坛上与用户互动，收集用户对系统和功能的建议、吐槽，然后在每周五下午，进行新一版的 MIUI 系统更新。用户在整个系统迭代的过程中，除了工程代码的编写，其他的(如产品需求设计、发布、测试等)都是深度参与的。在这种群策群力的氛围下，小米把这些消费者成功转化成了生产者，MIUI 真的以论坛为根据地建立了 10 万人的开发团队模型，其核心是官方的 100 多个研发工程师，核心的边缘是 MIUI 论坛的 1000 个荣誉内测组成员，而外围则是 10 万个 MIUI 论坛的活跃用户。

2.敏捷团队

敏捷团队是敏捷型组织里最基本的构成单元，就像器官是人的基本构成单元一样。每一个器官都有其独立存在的意义，但是所有器官都是一个人的组成部分，缺一不可。对于一个组织而言，每一个敏捷团队都有其各自的作 用，同时所有的敏捷团队共同肩负着组织的使命。

为了让整个敏捷团队释放出最大的潜能，敏捷团队的结构需要遵循以下 3 个原则。

原则 1：团队小而且相对独立。

团队小，指的是每个团队的规模遵循“两个披萨”的原则。“两个披萨” 的原则最早是由亚马逊 CEO 贝索斯(Bezos) 提出的，他认为如果两个披萨 不足以喂饱一个项目团队，那么这个团队可能就显得太大。“两个披萨”的 原则落实到具体人数上，是 6 ~ 10 人的规模。“两个披萨”的原则与敏捷方法之一—Scrum 框架所要求的团队规模在 5 ~ 9 人的意义相同。

这个原则背后的道理是，人数过多将不利于决策高效达成，而小团队容 易产生共识，并能够有效地促进组织内部的创新。此外，如果人数过多，沟 通和管理的成本迅速提高，会导致团队内部的信息不对称。

团队要相对独立，指的是各个团队的设计要尽量减少彼此之间的耦合 度。比如，对于一个 IT 团队来说，每次上线一个版本需要两个团队的代码互 相集成，或者 A 团队依赖 B 团队提供的组件，而 B 团队又依赖 C 团队提供 的组件，这样会极大地削弱交付效率。但是团队之间的独立不是绝对的，因 为对于复杂的业务、大型的产品或解决方案，组织往往需要多个团队互相合 作，比如，跨团队共同交付一个解决方案，或者共同合作一系列营销活动。 因此，各个敏捷团队保持相对独立，但不是单打独斗，而是在需要时相互配 合，协同作战。

原则 2：围绕业务组建敏捷团队，在绝大多数情况下，敏捷团队要覆盖产品价值链各个环节的职能。

这个原则在前面的章节反复提到过。只有将价值链的全部职能纳入团队 中，才能够以最高的效率响应市场和用户的需求。将全部职能纳入团队后， 鼓励团队的每个人参与彼此的工作，让不同的角色对彼此更加具有同理心。 比如，让处于价值链下游环节的开发人员、测试人员也参与用户调研，这样 他们能够更加理解业务需求，听到客户对产品不满意的声音，理解客户的场 景，从而使设计的解决方案更加贴近客户的实际场景，业务人员的压力也可 得到有效的分担；处于价值链上游的业务人员和产品经理，在产品开发的过 程中，跟设计师、开发团队一起探讨设计方案，而不是提了需求后就直接扔 给设计师和工程师交付；在产品交付前，业务人员对产品进行验收和体验， 避免产品在发布到用户手中后发生与用户需求不符合的现象。

如果某个产品、解决方案或服务的规模比较大，很可能会出现敏捷团队的人数多于 10 人的情况，此时组织需要考虑对业务做进一步拆分，比如，将一个业务拆分为多个子业务、一个产品拆分为多个子产品、一个服务拆分为多个子服务，否则会由于团队人数多而导致协作效率低下。

原则 3：团队具备自主决定权，并独立承担责任。

在传统的职能型组织中，内部信息流转节点多，信息经过多个部门的处理后才传递到决策层。信息的处理、论证及决策链条过程很长，导致整体决策效率低下。此外，由于价值链跨越了多个部门，因此经常需要集中到业务的最高领导才能做出决策。当敏捷团队覆盖了价值链的全部职能后，企业需要对敏捷团队下放权利，让团队能够独立行使从客户洞察、产品或服务设计、产品或服务交付、价值验证直至客户运营的整个过程的自主权。

很多企业在组织重组建立敏捷团队后，管理层仍旧不习惯将权力下放给团队，团队对创新方向的探索和设计的产品方案仍旧需要经过管理层的层层 审批，导致很多创新方向刚刚萌芽，还没来得深入用户验证，就被管理层扼 杀在摇篮里。久而久之，团队开展用户调研和创新探索的热情大受打击，因 为团队的感受是一切照旧。在很多人的理解中，亚马逊的“两个披萨”团队 讲的只是规模小，其实除了规模小，更重要的是团队的高度自治，这种高度 自治的团队模式让亚马逊在保持高速增长的同时保持了组织的敏捷性和持续 创新。当然，所谓权力下放不是下放所有的权利，对于业务的战略发展、业 务愿景、重大技术路线等宏观长远的方向性话题，还是需要集中式决策，因 为业务的战略不能脱离组织的整体战略和愿景。

需要注意的是，权利与责任是并重的。敏捷团队被下放了多少权利，就 承担多大责任。管理层与团队需要共同设定业绩目标，团队有权利设计达成目标的路线图，团队的所有成员对业绩目标共同承担责任。责任和权利并重 的团队就像一个小型创业公司，每个人都感觉到自己对业务的成功起着重要 的作用，对工作的热情更高，责任心更重。敏捷团队的负责人相当于创业团 队的 CEO ，把团队交付的产品或服务当作自己的创业项目认真对待。因此， 在这样的团队里，员工对企业的敬业度和忠诚度更高。

3. 赋能平台

尽管敏捷团队覆盖了产品价值链的各个环节，但并不意味着敏捷团队开 展工作完全靠自己。在整个组织范围内需要建设公共的平台，为各个敏捷 团队所需的共同资源赋能。赋能的范围包括但不限于公共的组件、服务、数 据、工具、信息、能力等，从而各个敏捷团队不需要耗费资源重复建设和维 护。映射到真实的组织里，赋能平台可能会包括以下类型。

• 每个企业都存在为所有业务单元提供公共服务的职能部门，如 HR、 财务、法务、行政、采购、合规部门等。这些部门为整个企业服务， 因此不需要也不应该划分到各个敏捷团队中。
• 为一个业务单元提供业务支撑的服务部门，如售后技术支持、物流、 安全审核等。这些部门服务的范围是整个业务单元，不需要划分到 各个敏捷团队中。每个敏捷团队都可以利用这些业务服务部门提供 的服务，不需要自己招聘客服人员、建设物流体系等。这些业务服 务部门为敏捷团队所召唤，提供敏捷团队所要求的客户服务。
• 为各个敏捷团队提供公共工具、设备、数据、信息的部门，如研发 工具平台、测试设备、大数据平台、实践经验库、市场分析研究、 云存储设施、To B 业务的客户管理系统等。公共内容是各个敏捷团 队开展工作必不可少的部分，如果没有公共部门提供这些公共内容， 那么它们将分散在组织的各个角落里，造成无数个“信息孤岛”。每 个敏捷团队就会像井底之蛙，只看到一小片天空，看不到天空的全貌，导致开展工作都需要重复造轮子，不仅对整个组织来说浪费巨大，各个敏捷团队也无法将有限的资源和精力聚焦在日常业务上。

采用敏捷团队 + 赋能平台这样的组织设计模型，能够将职能型组织重构为小的、独立的、对产品价值链端到端负责的敏捷团队，敏捷团队直接面向客户，可满足组织快速响应业务变化、灵活创新、快速交付的要求。同时，赋能平台为敏捷团队长期服务，既满足了组织复用公共资源，又避免了各自为政、重复建设而产生的效率低下和浪费，从而提升了整个组织的运营效率。因此，业务敏捷组织模型既满足组织对外界的适应性要求，也满足组织追求效率的要求。

4 领导者

• 领导者需要对敏捷团队高度授权，支撑敏捷团队充分释放潜能，实现组织的共同目标。为了实现这一目的，只做到授权还远远不够，领导者需要在以下角色方面投入大量的时间和精力。
• 愿景架构师。领导者能够预测和设想未来，凭借对市场趋势的深刻理解，特别是在技术和客户未被解决的痛点方面，创造全新的市场 机遇、产品或服务，并能够展望业务的发展愿景。
• 组织结构的设计师。领导者能够设计以客户为中心的敏捷型组织， 构建高度自治的敏捷团队，建设公共赋能平台，让各个团队借助公 共赋能平台的资源互通互联。领导者需要领导各个敏捷团队在保持 高度自治的同时，共识共同的使命、愿景和价值观，并凝聚各个敏 捷团队，为了共同的目标而努力。
• 组织文化的塑造者。领导者需要在整个组织中创造鼓励发现、实验 和学习的心态和文化，并在日常行为中亲力亲为地参与组织文化的 塑造，而不是将文化塑造的责任简单地分配给人力资源部门。另外， 领导者需要通过设计一系列措施将组织文化落地执行，而不只是将文化停留于贴在墙上的口号。
• 组织改善的催化者。领导者帮助人们将他们正在做的工作任务与组织 的愿景和目标联系起来，帮助敏捷团队消除妨碍实现目标的障碍，并 鼓励创造一个包容和开明的环境，让人们能够将真实的自我带到工作 中，以充满活力和可持续的节奏工作，实现个人和职业发展的抱负。
• 教练型领导者。领导者需要理解授权是有限度的，授权意味着团队 突破能力圈，从前只需要高级别领导者或特定职能角色人员具备的 技能，比如强大的商业敏锐度、战略思维、市场洞察能力等，现在 团队也需要具备。若团队在不具备相应技能的情况下被授权，会给 整个组织带来重大风险。因此，领导者需要权衡敏捷团队当下的能 力来判断授权的范围。另外，领导者需要致力于个人和团队的技能 发展，并为团队树立榜样，鼓励各种正式和非正式的能力建设计划 和举措。在领导风格上，领导者需要通过询问和倾听，采用一定的 教练式领导风格，而不是以纯粹的命令和控制方式来领导团队。

5 生态合作伙伴圈

生态合作伙伴圈是一个自然演进的过程。企业在初创期， 由于还未形成规模，且急需利润的增长，将不自觉地陷入竞争，而且这种竞争的意识形态会持续很长时间。随着快速发展和规模日益扩大，企业逐渐意识到，要想获得更大的发展需要共赢，自然开始发展盟友和合作者。随着数字化和人工智能技术的蓬勃发展，企业之间、企业与用户之间的连接需求比以往任何时代都更加强劲，各个行业的特征和边界也变得越来越模糊。

华为有句口号：“不在非战略机会点上消耗战略性资源。”企业不能也不应该什么都去投入、什么都形成核心竞争力。生态合作伙伴圈一般由企业内专有部门来经营，为各敏捷团队补充与价值链相关环节的能力，从而使各个敏捷团队可以聚焦其自身战略和长项，而敏捷团队的短板和不足，则可以借助生态合作伙伴圈为客户提供的产品、服务或解决方案来弥补，敏捷团队自身也作为生态合作伙伴圈的一部分促进整个生态的共荣。

6.   保持组织的敏捷雏形

组织结构的设计一定要服务于公司的战略。当战略发生变化时，企业自然需要相应的组织结构来支撑战略的实施；此外，即使在战略不变的情况下，组织结构也不是一成不变的，而是需要根据业务的发展动态调整。大多数企业在创业初期，都具备高适应力的敏捷型组织，但是随着业务的发展，员工的人数越来越多，专业化分工也越来越细致，新增的职能部门、职能组织越来越多，组织结构越来越臃肿，如果不小心地保持组织结构的敏捷雏形，往往会演进成纯粹的职能型组织。

组织因此在发展的过程中，需要根据业务的发展，小心地呵护业务敏捷的组织雏形，避免进入纯职能型组织结构：一方面，每个新增的敏捷团队都 应坚持敏捷转型结构的 3 个原则；另一方面，持续增强建设公共赋能平台，才 能在业务迅速发展和组织规模迅速扩张的情况下，使组织始终保持对外界的 高响应力。

基于业务敏捷的组织模型，各个企业可以根据自己的环境和需求，设计 适合自己的组织结构，只要遵循了这个模型，组成的新部门叫“部落”也好， 叫其他名字也罢，并不是核心问题。