作者 | Gergely Orosz
译者 | 核子可乐
策划 | 刘燕
回顾那场对 Uber 工程文化影响深远的变革。
2014 年春天,Uber 公司首席产品官 Jeff Holden 给技术团队发出了一封电子邮件。
这封邮件中讨论的变革将彻底改变 Uber 的工程动作方式并塑造未来几年的新型文化。
但这封“雷霆万钧”的邮件,却有着相当平淡的开头:
“经过对内部大规模的数据收集、思考与讨论之后,我们决定将公司整体划分为项目(Programs)与平台(Platforms)两大版块。请参考邮件附件,了解您自己身处项目团队还是平台团队、特别是在新团队中的职能定位。”
而这时候距离 Uber 招聘第一位全职工程师才刚刚过去三年。这时候 Uber 已经拥有 100 多名工程师、10 位产品经理(PM)和 15 名设计师。几乎所有工程团队都在独立运作,各自拥有不同的发展路线图和项目。
此次调整代表着 Uber 的一次早期演变,也宣告着 Uber 将正式告别以往聚集员工、交付项目、完成拆分再转移到下一个项目这种过于粗放的工程运作模式。
这份邮件解释了现有组织结构将经历怎样的转变:十余个团队将被划分为 16 个项目团队加 11 个平台团队,每位员工都将归属于其中一支平台或项目团队。
但大多数团队人手仍然不足,需要再额外雇用 100 多位面向工程、产品和设计岗位的新增人员。新团队将按重要性排名,例如,负责增加司机供应的团队,在优先级排名方面就远高于扩大乘客需求的团队。
这封邮件宣示的是 Uber 有史以来规模最大的一次工程组织变革: 建立跨职能项目团队,同时引入平台团队的概念。
截至目前,Uber 的运营仍然遵循着这波变革的路线,即一支团队要么属于项目团队、要么属于平台团队。
但到底是怎么划分的,又有什么意义?我们不妨先从这两类团队的定义入手。
项目团队
项目团队(在其他公司里通常被称为产品团队)占全体工程人员的 60% 到 70%,他们围绕一个使命进行组织,负责快速执行并优化产品创新。
项目团队具有如下特征:
当然,此外还有产品经理、数据科学家、设计师以及产品运营人员等成员。在使命调整之前,这支团队曾经扩大到拥有约 12 名工程师。
我们的客户就是使用 Uber 应用的自行车骑手。我们会通过吸引新客户、增加总订单量以及成本节约等指标衡量自身业务的影响。这些指标会随着各个计划周期而变化,旨在适应 Uber 公司的现阶段业务诉求。
平台团队
平台团队为项目团队提供构建块,后者则负责将这些构建块转化为实际业务影响。项目建立在平台之上,平台确保项目能够顺畅运行。各个平台团队均具有以下特征:
对于包括我自己在内的大部分工程领导者来说,建立平台团队往往极具挑战。最重要的当然不是控制员工人数,而是如何提前为团队配备必要的人手;此外,衡量平台团队是否成功的定义往往也比项目团队更模糊、更复杂。
共享项目 / 平台特性
虽然项目和平台团队各自负责解决不同需求,但双方仍具有以下几个共同点:
尽力而为的先遣队
Uber 在推进组织变革方面一直遵循大胆、果断的行事风格。 相较于更稳妥的逐区域渐进式变革,Uber 领导层直接公布部门拆分的明确日期,并将每支团队视为一支独立的先遣队。
这有点像《星际迷航》中各支先遣小队如何从企业号飞船前往行星表面。在各自迁移至项目与平台团队的同时,Uber 公司也将总部搬到旧金山的市场街,标志着与过去的自己彻底道别。
很明显,Uber 希望能在各支先遣队完成人员充实之前抢先重组。这意味着部分团队仍将以骨干成员的身份运作,尽可能早一步为招聘 / 留任工作厘清思路。
项目先遣队。在开展项目与平台团队重组时,相当一部分团队出现了人员配备不足的问题。也有部分员工被标记为“TBH”(待聘用)。
在我看来,Uber 能够成功完成重组要归功于几大原因:
首先,工程技术管理层非常清楚根据之前的招聘预测与投资规模,人员招聘不会出现什么大问题。因此在决定扩张之前,他们肯定已经与招聘人员充分沟通,确保他们理解招聘目标、成本预算等信息。
更重要的是,Uber 的领导层还必须对业务的持续增长、特别是最终超越现有结构抱有坚定的信心。做出如此重大的改变势必在短期之内影响简略,但团队会快速恢复活力并以更高的效率继续大步迈进。
事实证明,Uber 高管对于业务增长的信心是正确的。Uber 公司的拼车业务不仅一路飙升,还在 2014 年夏天启动了 Uber Eats 业务、2017 年上线 Uber Freight,后续几项新业务也纷纷取得成功。
解决旧结构带来的老问题
在变革之前,Uber 采取的是典型的功能性组织结构,包括工程、产品管理、业务运营、设计与数据科学等部门,各个部门都通过自己的团队保持运营。工程师们按团队分组,且各团队均不包含来自其他学科(如产品管理或设计)的人员。
当时的工程团队分为 Rider Operations、Driver Operations、Dispatch 和 Mobile 几大块,但并没有专门的产品经理或其他职能责任。产品经理大多充当项目的拥有者,并且经常与多个团队相互配合。
我个人将这种方式称为“基于项目的方法”,一般更强调稳定的工程团队组成。虽有好处,但这种结构也让项目夺取了工作方式与组织方式的主导权。
这种基于项目的方法当然有很多优点:
业务持续发展,难以确定优先级次序:
初期由于团队规模较小且优先事项不明,所以基于项目的结构没什么问题。但后来 Uber 的业务开始愈发复杂化,Driver 和 Rider 应用的上线以及众多新功能的加入带来了我们之前根本无法想象的复杂应用结构。
让人头痛的不只是应用程序功能;业务运营团队需要在不同城市推广更多一次性计划。而财务、法务等部门也有自己的项目需要完成。对几十个项目进行快速排序变得越来越困难。
很多跨职能项目一亮相就是 MVP,后来却无人问津:
不少项目在刚确定时份量极重,但在启动工作完成后初始团队会立即放手移交;作为接手者的工程团队虽然充当了名义上的拥有者,但移动工程师、产品经理或业务运营人员往往更关注下一个项目。于是很多之前的投入就打了水漂。
可以看到,由于跨职能工作总是“临时”进行,所以难以保证项目的“后续维护”。这一点在涉及移动工程师的业务中体现得尤其明显,毕竟他们自己都不知道接下来会被叫去支援哪些团队。
新项目的启动变得愈发难以协调:
基于项目的方法虽然提出了“配合合适的人员随时启动项目”这种看似美好的理论,但现实远远没那么简单。
每个项目都需要具备特定技能和领域经验的人员,包括移动工程师、设计师或者业务运营人员。但这些人往往归属于其他项目,而这位有空、那位在忙的协调缺少让“随时启动项目”变成了“总也启动不了项目”。另外,同一拨成员身兼多个项目往往让人精神错乱、注意力难以集中。
孤岛项目越来越多,跨职能项目越来越少:
由于跨团队项目的启动步履维艰,公司内部对于跨职能项目的协调能力也就越来越弱。例如,由于所有移动工程师都归属于移动团队,其他部门发现很难“预约”到移动工程师,于是大多数人开始尽可能去除涉及移动元素的功能。
而这时候的 Uber 已经到了发展的紧要关头,必须保证优先启动最匹配业务需求的项目——为此,他们必须解决阻碍前进的潜在问题。
最重要的业务目标一定具有跨职能属性:
Uber 意识到,单纯交付“简单”且孤立的项目并不符合客户和企业自身的利益。
Uber 需要降低跨职能工作的实施门槛。项目团队通过逻辑分组重新在企业内部定义了优先事项,而 Uber 则承诺为这些团队长期提供人员配备。平台团队专为支持项目团队而生,确保他们能够专注于自己的业务使命,并在共享的平台之上各自衍生出不同的发展方向。
由此引发的新问题
但天底下没有免费的午餐,组织结构转型也是如此。每次结构变化在解决部分问题的同时,也会引发新的问题。Uber 的结构变革在刚开始就带来了不少明显的新问题,也有一些问题在随后的运营中陆续涌现。
“双重报告”:
如今,每个团队都有了自己的产品经理、设计师、业务运营及其他职能角色;但原有报告结构并没有变化,于是团队成员只能打两份报告,一份给团队内领导、一份给职能部门领导。
工程技术领域之外出现了严重的“双重报告”问题。每个团队都有了自己的产品经理、设计师、业务运营及其他职能角色;但原有报告结构并没有变化,于是团队成员只能打两份报告,一份给团队内领导、一份给职能部门领导。
可以看到,这样的新制度下每位设计师都对应一名设计经理,而设计师自己又需要与每天合作的跨职能团队成员交代情况。这就引发了“双重报告”结构。看似问题很大,但这已经比过去的结构好得多——以往,设计师需要向对设计一无所知的项目负责人报告,后者很容易提出一些完全外行的“指导意见”。这种状况不仅会给项目带来混乱,同时也使得设计师没法获得专业指导、阻碍其职业发展规划。
于是双重报告结构继续存在,但职能部门的负责人需要密切关注下属们参与的各个项目。这种变化确实让职能经理们的工作更加困难,但同时也维持了团队组成的稳定性,让他们真正理解了自己的专业到底在如何发挥实际作用、铺设出一条更具前瞻性的职业发展轨迹。
应对意外变化时灵活性较差:
在基于项目的时代下,大家可以轻松应对意外变化:马上组建新的项目团队。但在项目团队与平台团队稳定区分的现在,应对意外变得更加复杂。
这种意外响应灵活性的下降其实是权衡后的结果,所以我们才说体量较小的初创企业在适应并改变工作方式方面更具优势。初创公司可以随心所欲地适应,而科技巨头则需要时间推动大规模重组。
应对新事件的常见办法就是建立专门的新团队,或者重组现有团队。建立新团队、选调部分老员工、再招聘几名新员工,这明显是破坏性最小的方法。至于更复杂的状况,企业可能需要进行更全面的重组。而 Uber 显然选择了后一种方法,划分项目与平台团队,以一着险棋在市场竞争中占据了主动。
部分团队产生思维惯性,开始做低优先级工作:
在项目加平台的双轨时代中,每个团队都具有明确的愿景和使命。但如果这些愿景和使命对企业不再重要,又会怎样?从宏观角度来看,公司当然希望能把人员转移到其他更重要的工作当中。
要解决这个问题,领导层会定期审查每支团队是否有必要存在。Uber 的方法就是开展季度性项目与平台团队审查。在审查中,领导们会关注各团队的影响、发展路线图以及如果团队不存在会造成哪些影响。
我发现 Uber 在自我审查方面做得确实很好,特别是擅长考量项目团队的存在意义。当团队的影响力下降时,领导层要么调整团队的资源配置(让部分成员转出去做其他工作)、要么直接解散团队并为成员们指定新的探索领域。
企业适应商业环境变化的方式决定了自身成败,这也是我在 Uber 看到的客观现实。这家以“快速行动”和“领先于竞争对手”为目标的公司确实很善于果断裁撤掉不再重要的团队,同时建立起更具现实意义的新团队。
Uber 目前的竞争对手主要是那些仍以项目为核心的初创公司,后者的运营思路跟过去的 Uber 很像。这些初创企业能够以惊人的速度对新的市场机会、监管变化或竞争关系做出反应。Uber 则需要保持自身灵活性,同时以新结构解决传统基于项目方法中的种种痛点。
谁来决定该建立哪些团队?:
在 Uber 决定启动项目与平台重组时,所有团队都已得到明确定义。季度审查则负责确定各团队是否还有存在的必要。如果没有,则可能缩小团队规模甚至将其解散。
但这些决定由谁来做出?决策流程是怎样的?谁对资金拥有最终决定权?毕竟在 Uber 这样一家快速发展的企业中,总会有游离于常规评判标准的新团队和新思路。
答案是,做出决策的是技术领导团队。他们会收集建议和商业案例,再由 CPO(首席产品官)决定项目团队、CTO 决定平台团队。随着时间推移和 Uber 的发展,这种决策权会被逐步下放到部门负责人手中。
改革成效
如今距 Uber 的项目平台拆分计划已经过去七年多了,这场变革让企业获得了良好的运作态势与竞争活力。
纵观整个 Uber 职业生涯,我发现平台团队确实能够跟上用户增长、项目团队也能随时获得成果交付。
现在的 Uber 仍在遵循平台 - 项目拆分理念,而且在持续发展中逐渐形成了“在大初创公司中建立小初创公司”的良好文化。
对于每项新倡议,公司会先设立一个小型项目团队,成员们尽可能利用现有平台以低成本方式做出试水。如果小团队取得成功,规模就能持续扩大并最终发展成常规的项目团队。在进一步发展后,他们可能拆分成两个项目团队、四个、六个,之后又孕育出一个新的平台团队……周而复始。
将三到四成工程人力资源划拨给平台工程无疑是一项巨大的投资。任何商业人士都很难想象这样的配置思路,毕竟这意味着短期内能够交付的功能将减少三到四成。
然而,Uber 的平台团队又分为三种类型,而且各自服务于不同的客户群体:
在我看来,架构、可扩展性和技术债务会很快给工程团队带来巨大压力,导致他们被迫采取计划外迁移来解决底层系统问题。更重要的是,工程技术人员的流失问题会相当严重,毕竟谁愿意待在一家部门间互不关心、松散无序的企业里?
平台团队的概念当然不是 Uber 的专利,不少快速增长的组织在特定领域都建立有专门的平台团队。我坚定认为平台才是一切技术组织稳定扩展的关键,也是他们不断突破效率极限的必要前提。
平台团队之我见
我跟平台团队合作过多年,也参与过多个平台的创建过程,观察到其中数十个团队的运作状态。下面我想聊聊自己对于平台团队的一点看法。
平台团队的部署不够直观。 从商业角度来看,平台团队似乎缺乏现实意义。
“我们为什么要把两成到四成的工程师投入到客户永远接触不到的工作当中?更离谱的是,我为什么要让最优秀的工程师参与这部分工作?”
这个问题是大部分企业在组建平台团队时做出的普遍反应。确实,平台团队在小型组织内毫无意义,对那些现有结构比较稳定而且业务增长幅度不大的组织同样没什么吸引力。
平台团队能够提高组织效率。 如果标准化确实对组织整体有利,那么平台团队的存在能够减少重复工作、推动方法标准化。例如,后端安全平台团队能够帮助我们对企业内的安全漏洞开展全面检查,同时有助于发现重复消耗资源、或者与既定原则相冲突的安全方法。
在平台团队落实到位后,我们能够更轻松地减少重复工作。平台团队的使命是为使用他们服务的客户获益,包括让产品团队将精力集中在产品身上,同时也让平台自身变得更加灵活、更好地为更多客户服务。
对于快速扩张的业务组织,平台团队必须存在。 如果您的业务已经超越了几十名工程师能够承受的极限,而且业务在客户群体、产品类别及流程复杂性等方面快速升级时,大家就必须建立起自己的平台团队。
平台团队满足的是那些非功能性需求,例如系统可靠性、更高的负载处理能力以及更稳定的产品支持能力等等。
这种非功能性其实非常重要,但却往往被决策者所忽视。具体包括:
产品平台团队在业务扩展方面与基础设施平台团队同等重要。随着产品覆盖区间的拓展、特别是逐步拆分为多支产品团队,企业当然需要将通用功能和服务转移到各个新的产品平台团队。如“事后总结”部分所述,Uber 的通信平台团队也正是由此衍生而来。
平台团队会带来新的痛点。 我当然承认平台团队带来的巨大帮助,但平台团队的出现也给组织带来不少新挑战。受篇幅所限,这里我只简单谈谈几个值得关注的问题:
这还只是产品与平台议题的冰山一角
我特别关注产品和平台的议题,而本文所涉及的也只是 Uber 在项目与平台转型工作中的冰山一角。
这里要感谢各位 Uber 高管和行业资深人士提供的帮助,特别是:
原文链接:
https://newsletter.pragmaticengineer.com/p/program-platform-split-uber