揭秘Uber史上最大規模工程組織變革

作者 | 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%，他們圍繞一個使命進行組織，負責快速執行并優化産品創新。

項目團隊具有如下特征：

長期存在：并非針對短期項目所組建，而是圍繞着司機體驗、市場效率或者亞太地區業務增長等目标而建立。各個團隊擁有明确定義的發展使命。

跨職能特性：每個團隊都擁有必要的人員配備，是以各團隊内既有工程師、也有非技術人員。團隊中通常有一名産品經理、一名資料科學家甚至是一名業務營運人員。就連工程工作本身也具有跨職能屬性，大多數團隊都設有後端和本地移動工程師，部分團隊甚至擁有網絡工程師。各團隊分别負責Rider、Driver 或者 Eats 等具體應用功能。要建構和運作功能，當然需要建構并維護相應的後端系統和用戶端代碼。

外部客戶：項目團隊會直接與外部客戶合作，傳遞供他們使用的功能。客戶涵蓋的不隻是 Riders、Drivers、Eaters 或者 Couriers（騎手、司機、食客、配送員），同時也包括公司内部的營運、客戶支援或會計人員，外加貨運客戶、Jumper 自行車騎手等其他小體量領域的客戶。

關注商業使命：各個項目團隊都專注于推動業務發展。例如，如果業務發生巨大變化、特别是不再需要關注增長，那麼相應團隊也将解散轉移。随着時間推移，項目團隊也一直在變化、一直在成長。當然，也有部分團隊因為沒能達到預期的快速增長目标而提前解散。Uber Rush 就是典型案例，由于一直無法達成預期增速，團隊隻能宣布撤銷。在加入 Uber 時，我曾在一個項目團隊工作過很長時間，當時主要負責乘客付款功能。我們的使命就是為所有自行車騎手提供順暢的支付體驗。在剛剛接手時，團隊是一個由 8 名原生移動與後端工程師組成的跨職能部門。

當然，此外還有産品經理、資料科學家、設計師以及産品營運人員等成員。在使命調整之前，這支團隊曾經擴大到擁有約 12 名工程師。

我們的客戶就是使用 Uber 應用的自行車騎手。我們會通過吸引新客戶、增加總訂單量以及成本節約等名額衡量自身業務的影響。這些名額會随着各個計劃周期而變化，旨在适應 Uber 公司的現階段業務訴求。

平台團隊

平台團隊為項目團隊提供建構塊，後者則負責将這些建構塊轉化為實際業務影響。項目建立在平台之上，平台確定項目能夠順暢運作。各個平台團隊均具有以下特征：

專注于技術任務：平台專注于各類技術目标，例如擴充關鍵區域、實作性能或可用性目标，或者建立起易于擴充和維護的架構，并為多個團隊和區域提供服務等。

專業且較少跨職能：由于平台團隊專注于解決技術問題，是以幾乎沒必要引入跨職能結構。平台團隊通常隻面向一個領域或者堆棧，大多數團隊也隻有面向特定堆棧的工程師。後期，部分平台團隊也開始與技術産品經理（TPM）或者産品經理合作，但這種情況在早期非常少見。

客戶主要是内部工程團隊：平台團隊的大多數客戶是其他項目團隊的工程師，極少數情況下也可能是使用該平台的業務人員。正因為如此，大多數平台團隊才隻吸納工程師成員。當然，也有少數平台團隊會直接為外部工程客戶提供服務，例如傳遞開發 SDK 的團隊。

供多個“垂直”領域（項目或平台）使用：每個平台都面向多個客戶，平台團隊在建立任何功能時都必須考慮到這個硬性前提。如果某項服務或功能隻供單一項目使用，那麼其就該歸為項目團隊所有、而非平台團隊。随着我所在的團隊在Uber 内部不斷發展壯大，我最終拆分了這個平台團隊，建立起支付 Web 平台與支付移動平台兩個新團隊。這些團隊掌握着支付建構塊，供 Uber的其他團隊利用這些建構塊快速釋出 Web 或移動支付功能。

對于包括我自己在内的大部分工程上司者來說，建立平台團隊往往極具挑戰。最重要的當然不是控制員勞工數，而是如何提前為團隊配備必要的人手；此外，衡量平台團隊是否成功的定義往往也比項目團隊更模糊、更複雜。

共享項目 / 平台特性

雖然項目和平台團隊各自負責解決不同需求，但雙方仍具有以下幾個共同點：

單一經理面向所有工程師：團隊中的每位工程師，無論他們熟悉哪種堆棧或專業方向如何，都向同一位團隊工程經理彙報。工程團隊是一個緊密耦合的單元。

誰建構、誰擁有：無論團隊建構出怎樣的成果，他們都需要保證成果品質、随叫随到并有責任維持一切正常運作。于是，平台團隊和項目團隊都需要随叫随到、準備解決成果中出現的問題。

品質标準保持統一：無論身在哪個團隊，我們都需要遵循相同的品質标準。代碼必須經過測試并接受功能監控。很多人都驚訝地發現，Uber 的平台團隊會在幾乎一切方案中添加遙測機制，而且往往能比客戶更早知道自己的系統何時出現問題。例如，開發者體驗團隊會收到持續內建（CI）服務發回的問題警報，并在工程師實際上報問題前就開展深入調查。

無需許可即可建構：即使不是平台團隊的成員，大家也可以随意建立新的服務、子產品或者可重用元件。很多平台其實就是項目團隊開發成果的延伸。這類建立平台要麼發展成新的獨立平台團隊，要麼就是被移交給負責該領域的平台團隊。

項目團隊地随着成長而發展成更多項目與平台團隊。作為項目與平台方法的自然結果，項目團隊會不斷成長并分化出更多項目或平台團隊。平台團隊往往掌握着跨項目的共享功能與責任，而這種“分化”也成為 Uber 組織大多數部門的自然過程。所有這些特性都與團隊自治有關。團隊自治與工程自治正是矽谷企業探索出的核心要訣，同時也是傳統企業難以了解和實作的精要所在。

盡力而為的先遣隊

Uber 在推進組織變革方面一直遵循大膽、果斷的行事風格。相較于更穩妥的逐區域漸進式變革，Uber 上司層直接公布部門拆分的明确日期，并将每支團隊視為一支獨立的先遣隊。

這有點像《星際迷航》中各支先遣小隊如何從企業号飛船前往行星表面。在各自遷移至項目與平台團隊的同時，Uber 公司也将總部搬到舊金山的市場街，标志着與過去的自己徹底道别。

很明顯，Uber 希望能在各支先遣隊完成人員充實之前搶先重組。這意味着部分團隊仍将以骨幹成員的身份運作，盡可能早一步為招聘 / 留任工作厘清思路。

項目先遣隊。在開展項目與平台團隊重組時，相當一部分團隊出現了人員配備不足的問題。也有部分員工被标記為“TBH”（待聘用）。

在我看來，Uber 能夠成功完成重組要歸功于幾大原因：

首先，工程技術管理層非常清楚根據之前的招聘預測與投資規模，人員招聘不會出現什麼大問題。是以在決定擴張之前，他們肯定已經與招聘人員充分溝通，確定他們了解招聘目标、成本預算等資訊。

更重要的是，Uber 的上司層還必須對業務的持續增長、特别是最終超越現有結構抱有堅定的信心。做出如此重大的改變勢必在短期之内影響簡略，但團隊會快速恢複活力并以更高的效率繼續大步邁進。

事實證明，Uber 高管對于業務增長的信心是正确的。Uber 公司的拼車業務不僅一路飙升，還在 2014 年夏天啟動了 Uber Eats 業務、2017 年上線 Uber Freight，後續幾項新業務也紛紛取得成功。

解決舊結構帶來的老問題

在變革之前，Uber 采取的是典型的功能性組織結構，包括工程、産品管理、業務營運、設計與資料科學等部門，各個部門都通過自己的團隊保持營運。工程師們按團隊分組，且各團隊均不包含來自其他學科（如産品管理或設計）的人員。

當時的工程團隊分為 Rider Operations、Driver Operations、Dispatch 和 Mobile 幾大塊，但并沒有專門的産品經理或其他職能責任。産品經理大多充當項目的擁有者，并且經常與多個團隊互相配合。

我個人将這種方式稱為“基于項目的方法”，一般更強調穩定的工程團隊組成。雖有好處，但這種結構也讓項目奪取了工作方式與組織方式的主導權。

這種基于項目的方法當然有很多優點：

響應時間。每當有新機會或出現新威脅時，我們都可以組建起新項目加以解決，不需要太多協調努力。

靈活性。就算管理者不知道接下來會出現哪種類型的工作内容，基于項目的結構在短期内也足以應付下來。Uber 早期的發展經曆已經證明了這種靈活性優勢。當時我們并不清楚接下來的重點是應對外部事件、把握新機會還是執行現有計劃，那保持固有結構肯定是最安全的辦法。

規劃和結構性成本較低。各團隊實際上是通過項目進行自我組織，共同應對企業面臨的最大挑戰。隻要整個體系運作良好，似乎就沒必要給規劃群組織團隊額外增加工作負擔。但随着業務發展，基于項目的方法也開始暴露出衆多缺點。對當時的 Uber 來說，問題主要有以下幾個方面：

業務持續發展，難以确定優先級次序：

初期由于團隊規模較小且優先事項不明，是以基于項目的結構沒什麼問題。但後來 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 的第一批平台團隊，他們為大部分工程技術團隊提供基礎服務，具體涵蓋存儲、計算、移動等平台。

開發者平台：這是一種值得關注的特殊基礎設施平台，相關團隊的使命在于提高整個公司的工程師與工程團隊效率。他們掌握着 CI/CD 系統、控制不同平台上的開發者體驗，并不斷研究創新方法以幫助工程師們更高效地傳遞成果、擷取回報并縮短功能疊代周期。

面向客戶型平台：這是一種不太常見的特殊平台案例，相關團隊負責為内部、非技術客戶以及包括工程師在内的外部客戶提供服務。相關示例包括通信平台，會以“低代碼”方式向客戶和業務使用者提供消息傳遞功能。另外，負責開發Uber Developer SDK 的團隊也屬于這一類，負責向外部開發者提供服務。

産品平台：從多個項目團隊的實際需求演變而來。例如，小費和評分平台團隊就源自衆多項目團隊對這類功能的共通需求。他們開發出的産品能夠供 Driver、Eats 乃至 Freight 等團隊共同使用，隻是不同團隊的實際用例略有差別。如果我們把大多數工程師都投入産品領域，而不像 Uber 這樣高度重視基礎設計，結果又會如何？

在我看來，架構、可擴充性和技術債務會很快給工程團隊帶來巨大壓力，導緻他們被迫采取計劃外遷移來解決底層系統問題。更重要的是，工程技術人員的流失問題會相當嚴重，畢竟誰願意待在一家部門間互不關心、松散無序的企業裡？

平台團隊的概念當然不是 Uber 的專利，不少快速增長的組織在特定領域都建立有專門的平台團隊。我堅定認為平台才是一切技術組織穩定擴充的關鍵，也是他們不斷突破效率極限的必要前提。

平台團隊之我見

我跟平台團隊合作過多年，也參與過多個平台的建立過程，觀察到其中數十個團隊的運作狀态。下面我想聊聊自己對于平台團隊的一點看法。

平台團隊的部署不夠直覺。從商業角度來看，平台團隊似乎缺乏現實意義。

“我們為什麼要把兩成到四成的工程師投入到客戶永遠接觸不到的工作當中？更離譜的是，我為什麼要讓最優秀的工程師參與這部分工作？”

這個問題是大部分企業在組建平台團隊時做出的普遍反應。确實，平台團隊在小型組織内毫無意義，對那些現有結構比較穩定而且業務增長幅度不大的組織同樣沒什麼吸引力。

平台團隊能夠提高組織效率。如果标準化确實對組織整體有利，那麼平台團隊的存在能夠減少重複工作、推動方法标準化。例如，後端安全平台團隊能夠幫助我們對企業内的安全漏洞開展全面檢查，同時有助于發現重複消耗資源、或者與既定原則相沖突的安全方法。

在平台團隊落實到位後，我們能夠更輕松地減少重複工作。平台團隊的使命是為使用他們服務的客戶獲益，包括讓産品團隊将精力集中在産品身上，同時也讓平台自身變得更加靈活、更好地為更多客戶服務。

對于快速擴張的業務組織，平台團隊必須存在。如果您的業務已經超越了幾十名工程師能夠承受的極限，而且業務在客戶群體、産品類别及流程複雜性等方面快速更新時，大家就必須建立起自己的平台團隊。

平台團隊滿足的是那些非功能性需求，例如系統可靠性、更高的負載處理能力以及更穩定的産品支援能力等等。

這種非功能性其實非常重要，但卻往往被決策者所忽視。具體包括：

可靠性（正常運作時間、存儲可靠性、資料持久性等）

延遲（系統響應時間、UI 延遲等）

性能（系統、UI 等）

用戶端非功能性限制（記憶體使用、應用程式占用空間等）

合規性

安全性

開發者體驗（編譯 / 測試 / 部署時長、CI 周圍時間、開發者工具使用體驗）組織結構越複雜，就越是需要由專門的非功能性團隊幫助其他團隊獲得這種共通的日常運作基礎。

産品平台團隊在業務擴充方面與基礎設施平台團隊同等重要。随着産品覆寫區間的拓展、特别是逐漸拆分為多支産品團隊，企業當然需要将通用功能和服務轉移到各個新的産品平台團隊。如“事後總結”部分所述，Uber 的通信平台團隊也正是由此衍生而來。

平台團隊會帶來新的痛點。我當然承認平台團隊帶來的巨大幫助，但平台團隊的出現也給組織帶來不少新挑戰。受篇幅所限，這裡我隻簡單談談幾個值得關注的問題：

難以定義并衡量團隊目标與關鍵結果。對平台團隊産出的準确衡量要遠比衡量正常項目團隊更難。項目團隊基本都有自己的一套相關業務名額，但平台團隊就沒那麼單純。另外，平台團隊的發展周期也大多更高，是以在目标回報上也比項目團隊更慢。

容易出現倚老賣老、思維固化的情況。平台團隊往往需要同時面對多個工程團隊，而且會在整個公司内部産生影響。在這樣的團隊中工作，工程師們若不 需要跟實際業務相關者打交道，畢竟他們的“客戶”主要是其他工程師。這聽起來很好，但卻容易讓成員們驕傲自滿、目空一切，反而有礙于大多數團隊成員的職業發展。

平台團隊容易“替客戶做決定”。平台團隊必須權衡自身決定與客戶決定之間的關系。例如，平台團隊既需要穩定投資并控制技術債務，同時也要及時拿出有利于客戶團隊的新功能。但也有部分平台團隊堅持優先處理自己認為重要的工作、甚至可能破壞客戶團隊利益，這種傾向非常危險。

保持與客戶的順暢溝通。我發現不少平台團隊開發的确實是客戶想要的功能，但在實際釋出後結果卻令人失望——客戶這時候才意識到自己并不想要這個功能，也不想承擔後續維護成本。于是，如何與客戶保持開放暢通的回報循環就成為建立平台團隊面臨的一大挑戰。

這還隻是産品與平台議題的冰山一角

我特别關注産品和平台的議題，而本文所涉及的也隻是 Uber 在項目與平台轉型工作中的冰山一角。

這裡要感謝各位 Uber 高管和行業資深人士提供的幫助，特别是：

Ganesh Srinivasan——Uber 公司前工程技術副總裁，在公司隻有 5 位移動工程師時創立了 Uber 移動平台團隊。我們探讨了快速行動為何如此重要，以及他對其他一些平台方案的看法。

Adam Rogal——Uber 公司前任移動平台團隊負責人。他目前擔任 Doordash 公司開發者平台總監。我們讨論了平台、開發者生産力以及二者之間的聯系。

其他關于平台工程的主題。感謝各位朋友的耐心閱讀，也期待您能分享自己的觀點與意見。

https://newsletter.pragmaticengineer.com/p/program-platform-split-uber