2014 年春天，Uber 公司首席产品官 Jeff Holden 给技术团队发出了一封电子邮件。这份邮件解释了现有组织结构将经历怎样的转变：十余个团队将被划分为 16 个项目团队加 11 个平台团队，每位员工都将归属于其中一支平台或项目团队。

 

 

 

项目团队

项目团队（在其他公司里通常被称为产品团队）占全体工程人员的 60% 到 70%，他们围绕一个使命进行组织，负责快速执行并优化产品创新。

项目团队具有如下特征：

●长期存在： 并非针对短期项目所组建，而是围绕着司机体验、市场效率或者亚太地区业务增长等目标而建立。各个团队拥有明确定义的发展使命。

 

●跨职能特性： 每个团队都拥有必要的人员配备，所以各团队内既有工程师、也有非技术人员。团队中通常有一名产品经理、一名数据科学家甚至是一名业务运营人员。

 

●外部客户： 项目团队会直接与外部客户合作，交付供他们使用的功能。客户涵盖的不只是 Riders、Drivers、Eaters 或者 Couriers（骑手、司机、食客、配送员），同时也包括公司内部的运营、客户支持或会计人员，外加货运客户、Jumper 自行车骑手等其他小体量领域的客户。

 

●关注商业使命： 各个项目团队都专注于推动业务发展。例如，如果业务发生巨大变化、特别是不再需要关注增长，那么相应团队也将解散转移。

 

平台团队

平台团队为项目团队提供构建块，后者则负责将这些构建块转化为实际业务影响。项目建立在平台之上，平台确保项目能够顺畅运行。各个平台团队均具有以下特征：

 

●专注于技术任务： 平台专注于各类技术目标，例如扩展关键区域、实现性能或可用性目标，或者建立起易于扩展和维护的架构，并为多个团队和区域提供服务等。

 

●专业且较少跨职能： 由于平台团队专注于解决技术问题，所以几乎没必要引入跨职能结构。平台团队通常只面向一个领域或者堆栈，大多数团队也只有面向特定堆栈的工程师。后期，部分平台团队也开始与技术产品经理（TPM）或者产品经理合作，但这种情况在早期非常少见。

 

●客户主要是内部工程团队： 平台团队的大多数客户是其他项目团队的工程师，极少数情况下也可能是使用该平台的业务人员。正因为如此，大多数平台团队才只吸纳工程师成员。当然，也有少数平台团队会直接为外部工程客户提供服务，例如交付开发 SDK 的团队。

 

●供多个“垂直”领域（项目或平台）使用： 每个平台都面向多个客户，平台团队在建立任何功能时都必须考虑到这个硬性前提。如果某项服务或功能只供单一项目使用，那么其就该归为项目团队所有、而非平台团队。随着我所在的团队在 Uber 内部不断发展壮大，我最终拆分了这个平台团队，建立起支付 Web 平台与支付移动平台两个新团队。这些团队掌握着支付构建块，供 Uber 的其他团队利用这些构建块快速发布 Web 或移动支付功能。

 

对于包括我自己在内的大部分工程领导者来说，建立平台团队往往极具挑战。最重要的当然不是控制员工人数，而是如何提前为团队配备必要的人手；此外，衡量平台团队是否成功的定义往往也比项目团队更模糊、更复杂。

 

共享项目 / 平台特性

虽然项目和平台团队各自负责解决不同需求，但双方仍具有以下几个共同点：

●单一经理面向所有工程师： 团队中的每位工程师，无论他们熟悉哪种堆栈或专业方向如何，都向同一位团队工程经理汇报。工程团队是一个紧密耦合的单元。

 

●谁构建、谁拥有： 无论团队构建出怎样的成果，他们都需要保证成果质量、随叫随到并有责任维持一切正常运作。于是，平台团队和项目团队都需要随叫随到、准备解决成果中出现的问题。

 

●质量标准保持统一：无论身在哪个团队，我们都需要遵循相同的质量标准。代码必须经过测试并接受功能监控。很多人都惊讶地发现，Uber 的平台团队会在几乎一切方案中添加遥测机制，而且往往能比客户更早知道自己的系统何时出现问题。例如，开发者体验团队会收到持续集成（CI）服务发回的问题警报，并在工程师实际上报问题前就开展深入调查。

 

●无需许可即可构建：即使不是平台团队的成员，大家也可以随意创建新的服务、模块或者可重用组件。很多平台其实就是项目团队开发成果的延伸。这类新建平台要么发展成新的独立平台团队，要么就是被移交给负责该领域的平台团队。

 

●项目团队地随着成长而发展成更多项目与平台团队。 作为项目与平台方法的自然结果，项目团队会不断成长并分化出更多项目或平台团队。平台团队往往掌握着跨项目的共享功能与责任，而这种“分化”也成为 Uber 组织大多数部门的自然过程。所有这些特性都与团队自治有关。团队自治与工程自治正是硅谷企业探索出的核心要诀，同时也是传统企业难以理解和实现的精要所在。

 

解决旧结构带来的老问题

基于项目的方法当然有很多优点：

1.响应时间。 每当有新机会或出现新威胁时，我们都可以组建起新项目加以解决，不需要太多协调努力。

2.灵活性。 就算管理者不知道接下来会出现哪种类型的工作内容，基于项目的结构在短期内也足以应付下来。Uber 早期的发展经历已经证实了这种灵活性优势。当时我们并不清楚接下来的重点是应对外部事件、把握新机会还是执行现有计划，那保持固有结构肯定是最安全的办法。

3.规划和结构性成本较低。 各团队实际上是通过项目进行自我组织，共同应对企业面临的最大挑战。只要整个体系运作良好，似乎就没必要给规划和组织团队额外增加工作负担。

 

但随着业务发展，基于项目的方法也开始暴露出众多缺点。对当时的 Uber 来说，问题主要有以下几个方面：

 

业务持续发展，难以确定优先级次序：

初期由于团队规模较小且优先事项不明，所以基于项目的结构没什么问题。但后来 Uber 的业务开始愈发复杂化，Driver 和 Rider 应用的上线以及众多新功能的加入带来了我们之前根本无法想象的复杂应用结构。

让人头痛的不只是应用程序功能；业务运营团队需要在不同城市推广更多一次性计划。而财务、法务等部门也有自己的项目需要完成。对几十个项目进行快速排序变得越来越困难。

 

很多跨职能项目一亮相就是 MVP，后来却无人问津：

不少项目在刚确定时份量极重，但在启动工作完成后初始团队会立即放手移交；作为接手者的工程团队虽然充当了名义上的拥有者，但移动工程师、产品经理或业务运营人员往往更关注下一个项目。

于是很多之前的投入就打了水漂。可以看到，由于跨职能工作总是“临时”进行，所以难以保证项目的“后续维护”。这一点在涉及移动工程师的业务中体现得尤其明显，毕竟他们自己都不知道接下来会被叫去支援哪些团队。

 

新项目的启动变得愈发难以协调：

基于项目的方法虽然提出了“配合合适的人员随时启动项目”这种看似美好的理论，但现实远远没那么简单。

每个项目都需要具备特定技能和领域经验的人员，包括移动工程师、设计师或者业务运营人员。但这些人往往归属于其他项目，而这位有空、那位在忙的协调缺少让“随时启动项目”变成了“总也启动不了项目”。另外，同一拨成员身兼多个项目往往让人精神错乱、注意力难以集中。

 

孤岛项目越来越多，跨职能项目越来越少：

由于跨团队项目的启动步履维艰，公司内部对于跨职能项目的协调能力也就越来越弱。例如，由于所有移动工程师都归属于移动团队，其他部门发现很难“预约”到移动工程师，于是大多数人开始尽可能去除涉及移动元素的功能。

而这时候的 Uber 已经到了发展的紧要关头，必须保证优先启动最匹配业务需求的项目——为此，他们必须解决阻碍前进的潜在问题。

最重要的业务目标一定具有跨职能属性：

Uber 意识到，单纯交付“简单”且孤立的项目并不符合客户和企业自身的利益。

Uber 需要降低跨职能工作的实施门槛。项目团队通过逻辑分组重新在企业内部定义了优先事项，而 Uber 则承诺为这些团队长期提供人员配备。平台团队专为支持项目团队而生，确保他们能够专注于自己的业务使命，并在共享的平台之上各自衍生出不同的发展方向。

 

改革成效

如今距 Uber 的项目平台拆分计划已经过去七年多了，这场变革让企业获得了良好的运作态势与竞争活力。

现在的 Uber 仍在遵循平台 - 项目拆分理念，而且在持续发展中逐渐形成了“在大初创公司中建立小初创公司”的良好文化。

Uber 的平台团队又分为三种类型，而且各自服务于不同的客户群体：

 

●基础设施类平台：Uber 的第一批平台团队，他们为大部分工程技术团队提供基础服务，具体涵盖存储、计算、移动等平台。

 

●开发者平台： 这是一种值得关注的特殊基础设施平台，相关团队的使命在于提高整个公司的工程师与工程团队效率。他们掌握着 CI/CD 系统、控制不同平台上的开发者体验，并不断研究创新方法以帮助工程师们更高效地交付成果、获取反馈并缩短功能迭代周期。

 

●面向客户型平台： 这是一种不太常见的特殊平台案例，相关团队负责为内部、非技术客户以及包括工程师在内的外部客户提供服务。相关示例包括通信平台，会以“低代码”方式向客户和业务用户提供消息传递功能。另外，负责开发 Uber Developer SDK 的团队也属于这一类，负责向外部开发者提供服务。

 

●产品平台： 从多个项目团队的实际需求演变而来。例如，小费和评分平台团队就源自众多项目团队对这类功能的共通需求。他们开发出的产品能够供 Driver、Eats 乃至 Freight 等团队共同使用，只是不同团队的实际用例略有区别。如果我们把大多数工程师都投入产品领域，而不像 Uber 这样高度重视基础设计，结果又会如何？

在我看来，架构、可扩展性和技术债务会很快给工程团队带来巨大压力，导致他们被迫采取计划外迁移来解决底层系统问题。更重要的是，工程技术人员的流失问题会相当严重，毕竟谁愿意待在一家部门间互不关心、松散无序的企业里？

平台团队的概念当然不是 Uber 的专利，不少快速增长的组织在特定领域都建立有专门的平台团队。我坚定认为平台才是一切技术组织稳定扩展的关键，也是他们不断突破效率极限的必要前提。

 

文章来源：AI前线