作者 | 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