下面咱们继续聊亚马逊独特的工作方法。这次为大家介绍在科技企业中已经颇负盛名但玩法依然有几分神秘，很多企业有点玩不转的“2 Pizza Team”。
2 Pizza Team来源于贝佐斯在2004年左右提出的一个想法：“We try to create teams that are no larger than can be fed by two pizzas,” said Bezos. “We call that the two-pizza team rule. The smaller team the better collaboration."
也就是说，贝佐斯认为团队颗粒度越小，协作就越好。亚马逊针对这个理念如何实施，在技术、产品、运营等大量领域进行了十多年的探索，在创新和效率提升上取得了显著效果。下面咱们来深度聊聊这个机制怎么玩。
1
什么是2 Pizza Team
让我们先让ChatGPT对2 Pizza Team做一个简单概括。
正如ChatGPT所说，2 Pizza Team机制是通过小团队的组建，最大化创新和协作。但在实际实施时，会存在很多困难，需要对团队如何组建、如何运行、如何设计目标、如何与其它团队和资源解耦进行精心设计。稍有差错，小团队就会有其形而无其神，处处受到制约，无法渐入佳境。
本文针对这个机制如何设计和运行，基于笔者在亚马逊领导产品、运营等团队的具体实践进行分享。
2
组织架构
要理解2 Pizza Team的组织架构方式，先要理解两类常见组织架构形态。
1） 职能型组织
职能型组织
职能型组织的特征是，把具备某个领域的专业能力并且负责某个具体职能的人员集中起来形成各个部门，然后在各项工作中通过各部门协作共同推进。
这个架构的优点很明显，职责明确、专业能力集中、分工细致、资源共享，并且能从全局对优先级进行规划，确保关键项目的资源支持。当然，它的缺点也同样突出，主要是决策需要各部门层层审批、跨部门协调复杂、资源全局共享导致项目缺乏保障、部门间工作优先级差异、以及多部门分工或责任不明。
2）项目型组织
项目型组织
项目型组织的特点是，把所有资源以项目为单位进行闭环组合，在每个项目组中包含项目需要的绝大部分重要资源，类似上图。
这种组织类型的优缺点刚好和职能型组织相反。优点是项目资源独占，内部决策效率高，协调快速，责任归属明确，优先级统一。但缺点是项目专业能力可能存在不足、资源缺乏弹性且使用效率低、项目间存在重复劳动。
3）矩阵形态的2 Pizza Team
职能型组织相对最不适合创新，因为资源全局共享，需要抢，所以“重要不紧急”的创新，在抢资源时常常输给业务需求。但项目型组织又缺乏专业能力，以及对公用模块的把控能力，因此也不具备最佳的创新能力和决策效率。
为了解决上述问题，2 Pizza Team往往采用第三种形态：矩阵型组织。它的特征是，纵向以职能型组织为基础组建部门，横向以项目资源需求为依据组合资源，形成纵横结合的“矩阵”。这个组织类型，一定程度上集中了职能型组织和项目型组织的优点，规避了两者的缺点。
矩阵型 2 Pizza Team
以上图为例，比如针对亚马逊的重要导购栏目“全球优选”，可以组建相应的2 Pizza Team。这个team同时包含产品、运营、UED、研发、测试、数据分析人员，需要跨部门组建。但因为资源需求规模会持续变化，比如前期偏重产品和UED，中后期偏重运营和数据分析，所以人员规模保持弹性，部分人员与其它项目共享（但要规定好比例，比如某个阶段某个岗位人员投入30%的时间）。
矩阵型组织的问题是双头汇报，管理复杂，依然存在一定程度的资源竞争也不完全具备资源弹性。能流畅运作的前提是，多部门的上层可以有更深度的介入和快速协同能力。
4）垂直单元型2 Pizza Team
垂直单元型2 Pizza Team
这个形态比较简单，在亚马逊内部多见于技术团队，也是数量最多的一种。它针对某一独立的小模块，组建相应的2 Pizza Team，闭环相关人员。比如个性化推荐算法2 Pizza Team，负责一个算法黑盒子，暴露接口供外部业务方（如首页个性化瀑布流）调用，通过入参控制类型和场景，并返回结果集。
3
组建原则
1）团队规模
2 Pizza Team通常建议不超过10人（不要纠结饭量
），最小的由1人组成也可以。可以有一定弹性，不是说15人就一定不行，但越大，内部协调复杂度就越高，效率就越低。如果针对大模块组建团队，需要人数很多，建议进一步拆分成裂变。
2）成员构成
2 Pizza Team的成员建议全部由领域专家、业务专家和技术专家构成。一般项目团队可以有一个金字塔结构，可以通过老带新培养新人，但2 Pizza Team需要成员精干、富有经验、具备独立决策能力和权力。这个团队通常完全把控所负责模块，全权决策，以充分提升决策和执行效率。
3）适合领域
并非所有领域都适合设置2 Pizza Team。它最适合的领域是，可以独立运作、由量化目标驱动（以快速评估效果）的单元，比如独立技术模块（比如个性化推荐算法）、独立产品模块（比如秒杀频道）、专项运营（比如付费会员运营）、工具研发（比如CMS系统开发）等模块。
它更适合有创新空间，可以快速验证的工作，比如新技术领域试水、创新想法验证、新技术应用验证，等等。日常按程序规章进行事务性工作的部门，比如客服、人事、法务等部门，可能不适合。
4）存在期限
2 Pizza Team建议长期存在，负责某个领域的持续提升和创新变革。比如，个性化推荐算法，如果针对它组建团队，就应该是个长期团队，负责持续迭代。也可以针对特定目标组建，完成后解散，但这不是对2 Pizza Team机制的最佳使用。虽然这样可以保障执行，但团队可能不具备良好的创新意愿和能力。
4
运作机制
2 Pizza Team的运作需要奉行独立自主、面向长期价值两大核心原则。
1）独立自主
这是最重要的一点。2 Pizza Team的关键目的是充分提升协作效率和创新能力，这极其需要团队运作独立性的保障，以最大限度从资源依赖、跨部门协调、层层审批的环境下解放出来。独立运作能力可以通过下述操作来提升：
持续解耦。如果存在外部的高频硬依赖，如技术、流程、资源方面的依赖，建议尽可能把相应人员也纳入2 Pizza team。比如，负责全球优选的2 Pizza Team需要频繁请某个品牌运营人员提供支持，最好的方法是把这位运营人员也闭环进这个team（可以part time）。
消除资源/代码共享。如果某个2 Pizza Team和其它团队共享某个资源，在使用、修改时需要和其它团队协商，这就极其影响效率。建议进行资源分配的调整，消除共享。比如负责A算法的2 Pizza Team需要频繁修改其它团队负责的B接口的内部代码，那么最好把B接口整个划入A算法模块，或者进行代码重构，把A需要修改的代码部分从B调整到A的模块里。
最小化跨团队协作。当需要跨团队协作时，2 Pizza Team的进展就会受到牵制。虽然这无法完全避免，但要尽力做到最小化。对其它团队的依赖，可以是软性的支持（比如提供建议），而非刚性的配合（比如完成某个任务）。如果协作刚性且频繁，建议对人员、资源、责任范围等进行调整。
持续组织架构优化。从上面的要求我们已经看到，2 Pizza Team并不意味着划一个团队出来自己就能跑。它的组建以及走向最佳形态，需要上级部门的全力支持，通过组织架构的持续调整，拆出一个个具备独立运作条件的2 Pizza Team，并且通过资源配置和职能调整最大限度地保障2 Pizza team的独立运作能力。一个大部门通常也不可能全都分割成2 Pizza Team。如果从中能孵化出几个2 Pizza Team，负责相对独立、关键并且需要创新的部分，就很理想了。
2）面向长期价值
前面已经提到2 Pizza Team最好长期存在，以更好地完成团队内部磨合，达到最佳效率，并且提升归属感和主人翁意识，产出更高价值。
创新的价值体现往往也需要时间。一般来说技术成熟度曲线如下图：
技术成熟度曲线
一个创新想法被提出后，大家满怀期待，投入资源猛干。但创新也存在很多假设，刚推出时有可能暂时达不到预期，并非所有美好愿望都立刻能转化为数据。同时创新也需要整个体系的保障，是一个体系逐渐适配创新的过程，有一个渐入佳境的过程。因此，前期的成绩往往是有限的，问题也会很多，此时创新常常会面对风险，被质疑。但如果可以长期坚持，度过难关，真正有价值的创新就可以再次攀升，进入稳定和越来越高的持续性价值输出。2 Pizza Team的核心价值正是释放创新的潜能，必须面向长期价值才能有所收获。
3）进展可量化衡量
价值不能是主观的，2 Pizza Team必须要有清晰的远期方向和近期可量化目标，这就要求有一个明确的指标体系来衡量进展和成果，并且对资源投入的ROI进行计算。所以亚马逊非常重视次年规划，在关键项目上进行明确的量化效果预估，并提出准确的资源需求。这个规则也完全适用于2 Pizza Team。
5
组建方式
2 Pizza Team的组建一般有三种方式。
1）Top-Down
这个方式较常见。2 Pizza Team的组织往往从领导层发起，分析部门内职能状况和飞轮形态（参见《战略思维：飞轮效应》），找到独立的价值引擎，针对其组建2 Pizza Team，并协调资源、划分职能，完成解耦，提供效率上的保障。
2）Bottom-Up
也有2 Pizza team来自于某个员工的创新想法，通过跟领导层的价值论证，得到支持后申请资源组建。或者某个员工负责一个较小的模块，因为找到了比较好的创新机会，慢慢长成了一个2 Pizza Team。这种稍微少一些，但条件具备时也会应运而生。
3）裂变
有很多优秀产品或者业务初期规模较小，适合2 Pizza Team运作，后期会渐渐长大，此时可以进一步裂变（有兴趣可以看看分形创新理论），裂变出“子”2 Pizza team，因为母团队自身具备天然的2 Pizza Team土壤和环境，比如与外界解耦，规模也不大，调整难度一般会大大低于在大部门里进行“解耦封装”，是一种极佳的2 Pizza team组织方式。
这里总结一下2 Pizza team的组建过程，下面是我总结的核心流程环节和要点。限于公众号文章的篇幅所限，不对每个细节进行展开，大家应该比较容易理解。
2 Pizza team的组建流程
6
核心价值
根据我的实际经验，2 Pizza Team有下面这些明显的核心价值：
1）创新利器
创新常常受到企业习惯的产品形态、工作方式和既有技术/业务体系的束缚，因此，创新的理想环境格外需要独立运作和自主决策。2 Pizza Team机制最核心的设计目标正是最大化这方面，因而往往能获得较为理想的空间进行创新，是企业的创新利器。
2）提升效率
在大企业，运作效率很大程度受制于层层汇报审批和跨团队协作的优先级差别。2 Pizza Team闭环人员、资源和决策权在团队内部，保障快速决策并最大限度减少跨团队协作，效率可以达到甚至超越创业公司水平。
3）增强责任感
在大企业，员工负责的工作往往变化频繁、成绩难以量化衡量、成绩或者问题归因困难，导致了很多员工只是以打工人心态工作。2 Pizza Team长期负责独立模块、人员稳定，以指标体系量化工作目标、衡量进展，这就决定了团队成员对所负责的模块会有强大的责任感和归属感。
4）提升质量与产量
跨部门协作时，人员能力、分工和责任感的不确定性会导致进度、配合、标准、态度上的妥协，这些问题最终往往转变为工作产出的问题。2 Pizza Team的小团队独立运作可以最大限度规避上述问题，极其有利于质量的提升。而2 Pizza Team的高效率特征也明显有利于产量提升。
5）鼓励创业者精神
很多大企业提倡的“创业者精神”说起来容易做起来很难，是因为大企业往往有稳定的业务基础和营收，员工工资未必真的受到实际业绩的影响，即使做出成绩也很难归功到个人。2 Pizza Team机制带来的强大归属感、指标展现的明确结果、独立运作带来的清晰ROI，都会进一步引出团队更强的创业者精神。
刚刚这些优点，在2 Pizza Team运作的过程中我是有清晰的体感的。虽然也受到特定2 Pizza Team的实际环境、奖惩机制和团队亚文化的影响，但上述几点的促进作用均十分明显。
7
问题与挑战
前面说了那么多优点和价值，但2 Pizza Team在实际运作中也存在很多问题和局限性，并不能完全进入理想状态。下面说说实操中的困境。
1）人员抽调阻力
2 Pizza Team最理想的情况是把业务、产品、技术专家闭环在团队里，专注特定目标，为梦想而狂奔。但现实是，能者多劳，骨干力量往往需要支持各种工作，很难被批准专职在2 Pizza Team中工作，所以抽调人员的阻力，可能会导致关键人员无法进入，进而形成对外部人员的依赖。
2）无法完全解耦
2 Pizza Team运行的一个重要前提是尽可能与外界解耦以保持独立性。比如负责一个算法的2 Pizza Team，理想情况下仅仅通过接口与外部交互，对外则是一个黑盒子，这样才能有最大的独立性。但实际上，很多事情解耦难度很高，对外提需求就会受到跨团队协作的牵制。在无法绝对避免的情况下，持续通过调整将高频硬约束最小化，会有助于提升2 Pizza Team的效率。
3）和公司、部门优先级产生冲突
大部门在某个阶段常常要攻坚，比如618大促来了，就要求调动所有资源支持好这类S级工作，这时2 Pizza Team也往往被要求提供对618的支持。那么S级要支持，A级呢？这类工作此起彼伏，2 Pizza Team到底要暂停自身工作来支持哪些项目最终只是个程度和领导的决心问题，就像战略预备队的使用。这类打扰是无法避免的，严重时2 Pizza Team根本无法专注自身目标。
4）量化目标制定困难
在这个大数据时代，通过数据驱动业务发展成为共识。但如何用好数据，是个巨大课题，企业能力也参差不齐。亚马逊是个有深度数据文化和极强数据应用能力的公司。即便如此，要定义一个客观合理的量化目标，并对工作产出和价值进行全面衡量，依然颇有难度。比如如何预测未来的提升、如何完全屏蔽其它影响因素来评估一件事的价值、如何找到一个改变带来的副作用，都是很大的难题。
定目标是2 Pizza Team成功的基础要素之一，但这个主题涉及到数据指标体系建设和精准分析方法，是一个至少几十万字的主题，本文暂且略过。
这些是我实操中的实际困难挑战。当然这挡不住2 Pizza Team可以提供的巨大价值，它依然是一个极其值得尝试的方法。
8
机制对比：敏捷、阿米巴
本文的最后，再来聊聊它和两个相似的模型，敏捷模型和阿米巴模型的对比。
1）2 Pizza Team vs. 敏捷
我本来不觉得2 Pizza Team和敏捷有什么关系，但多次被朋友问到，所以讲一讲它们的主要区别：
2 Pizza Team vs. 敏捷
简单说，敏捷是为了更有效率地搞定项目和客户，2 Pizza Team则是通过创新能力和效率的保证，持续提升某个工作单元。
2）2 Pizza Team vs. 阿米巴
阿米巴和2 Pizza Team有更多的相似性，但本质上还是两种东西。
2 Pizza Team vs. 阿米巴
概括来说，阿米巴是提升经营效率的，而2 Pizza Team是提升创新和执行效率的。对于敏捷和阿米巴有兴趣的同学可以进一步做拓展阅读，以理解其本质。
好，亚马逊听起来简单做起来复杂的2 Pizza Team机制的深度解析先讲到这里，希望能成为有创新和效率方面痛点的企业有益参考。
作者：徐霄鹏
来源：产品遇上运营