在拓展組織、指導平台團隊發展的過程中，我們吸取了一些寶貴的經驗教訓。 這些教訓往往源於過去的錯誤。
翻譯自 Tame the Tiger： A Lighthearted Guide to Platform Teams，作者：Ashwin Ragh** 領導 Google IDX 專案的工程。 那些討厭的 firebase API 也是他的傑作。 他在 Google、Twitter、Zynga、Thoughtworks 和 Intel 擁有 20 年的軟體和軟體團隊建設經驗。 他自稱是開發人員工具方面的專家，經常面臨世界各地不滿意的開發人員的憤怒。 他與妻子和兩個孩子住在一起。 在成功的產品和快速擴張的團隊背後的巨集偉藍圖背後，有乙個鮮為人知但至關重要的實體——難以捉摸的平台團隊。
在我的職業生涯中，我領導過兩個平台組織，我們的社群對協調平台團隊的藝術很少關注，這讓我有點惱火。 由於他們與生俱來的性質，這些團隊往往是產品和他們所服務的其他團隊的弱點。 你能誠實地說，你沒有遇到過乙個內部平台團隊興高采烈地要求你等到下乙個財政年度來解決你勤奮提交的錯誤報告嗎？
在這篇文章中，我將分享我在 Google、Firebase 和 Zynga 工作時建立平台團隊的經驗和想法。 我將重點介紹從所犯錯誤中吸取的經驗教訓，這些經驗教訓教會了你如何擴充套件你的組織，以及如何應對平台團隊開發的複雜性。 隨著組織的發展，領導者正在尋求效率改進，以跟上不斷增長的員工隊伍。 通過致力於一系列效率改進，平台團隊變得越來越重要：減少產品團隊之間的重複工作（考慮核心服務，如可觀測性、資料庫和儲存、DevOps 和工程生產力工具）。
促進招聘各種“繁瑣技能”（運營、移動開發、前端、資料科學、指標等）的專家;
戰略性地標準化您的服務，這樣您就不必擔心這些雜務，因此您可以更好地處理組織擴張和團隊重組。
事實上，平台團隊的概念已經建立，標準的組織結構已經建立，我們已經成為習。
然而，我們所珍視的效率改進往往也是效率低下的罪魁禍首。 我們已經學會了容忍它們，因為總的來說，平台團隊的好處仍然大於壞處。
但事實證明，我們可以做得更好。
如果本文只有乙個關鍵點要說明，那就是最小化外部成本是平台組織設計的關鍵。 這些外部成本是多少？
想象一下，發布工程 （releng） 團隊負責指導和執行整個組織的主要產品發布。 問題在於，這個過程不可避免地涉及大量的手動流程和法律風險。 實現完全自助式的發布流程就像解開了乙個戈爾登結。
因此，Releng 團隊選擇了一條更簡單的路徑——發布列車。 產品團隊依次“乘坐”發射列車，等待他們的車票被“打出”。
因此，產品團隊必須依賴發布過程的可靠性，並仔細規劃其產品發布日期和隨之而來的營銷活動。
但最關鍵的問題是，自定義熱補丁和緊急發布就像曲線球一樣，經常讓產品團隊措手不及。 高歌猛進的發布團隊不得不思考，“什麼樣的情況值得我們在周五的加班之夜進行熱補丁發布？”
既然發布成本是產品團隊的外部成本，那麼在這個過程中誰扮演反派的角色呢？沒錯，就是發布團隊減慢了發布過程，並為熱補丁設定了無法達到的閾值。
相反，如果在下乙個計畫的發布中忽略了生產環境中的錯誤，則所有相關的外部成本都將放在發布團隊身上，這對他們極為不利。
解決方案是什麼？保持發布過程存在，但開發乙個自助服務、有據可查的修補程式過程。 讓每個產品團隊自己決定哪些錯誤值得在週末進行修補，突然之間，發布的成本就像隱藏在辦公室裡的零食櫃一樣成為內部事務。
隨著組織的發展，團隊會按照自己的節奏前進。 儘管這感覺像是一場集體鄉村舞會，但讓球隊保持同步很重要。 當像真人騷的淘汰過程一樣在競爭團隊的優先事項中進行選擇時，您就知道是時候提高您的決策能力了。
在組建平台團隊時，您應該致力於提供持續的支援。 領導們在就職典禮之後，必須繼續支援平台團隊的各種需求，不能片面地拋棄它們！
那麼，做出明確決定的秘訣是什麼？退款！對於那些頑固地存在於產品團隊職責範圍之外的成本，退款是您的門票。 我們談論的不僅僅是通常意義上的可疑成本——計算、儲存和指標團隊提供的各種借據。
我們需要跳出框框思考
還記得之前瑞冷團隊的例子嗎？用軟體工程師的小時數來衡量在每個發布過程中花費的時間（一種特殊但有效的衡量標準）。 產品團隊會追求成本效益，發布團隊的目標是盡可能降低每個產品團隊在“發布列車”上的“票價”。
有沒有人提議棄用功能？計畫告別傳統支援的團隊可以收取對過時平台的持續支援費用。 突然之間，這是一場競標戰！如前所述，建立平台團隊的主要原因之一是成為某些利基市場專業知識的“磁鐵”。 （運營、移動開發、前端、資料科學、指標 - 應有盡有。 )
但請謹慎行事，因為您即將步入效能校準的殿堂。
是時候調整你的績效評估標準了。 過去，對在關鍵領域展示專業知識的自動獎勵不再有效。 即使您是“安全專家”，此標題也不會自動提高您的效能評級。 請記住，每秒查詢數等影響指標與產品團隊的記分卡無關。 如果你想集中某些專業人士，你必須全力以赴。 例如，不要將移動開發人員分散到不同的產品團隊，同時保持乙個核心移動團隊。 你最終會得到乙個椅子遊戲，你必須為不同團隊的每個人公平地規劃發展機會，並評估不同角色、工作無關的人的影響。
集中化不是一勞永逸的解決方案。 根據產品的實際需求明智地選擇要集中的功能。 例如，將UI設計師集中起來似乎是乙個合理的舉動，但如果你的產品嚴重依賴品牌標識，那麼將設計師作為共享資源可能會引發設計理念的衝突。
老生常談的爭論是：平台團隊是否應該引入產品經理？我堅定地支援將您的產品視為美味佳餚，將消費者視為挑剔的食客——這需要產品管理。
平台產品經理的角色可能與常規不同，但團隊化學反應和明確的期望是必不可少的。 在這裡做產品經理，不是為了實現巨集偉的創造，而是為了組織管理、系統的溝通和運營細節的協調。 並非每個產品經理都能勝任這項任務。
儘管TPM（Total Product Maintenance）對產品經理的替代仍然存在，但像珍貴的蘭花一樣培育您的平台服務將為所有人帶來更好的果實。
還記得我們討論過的組織管理嗎？如果產品團隊中的產品經理正在處理關鍵業務和財務指標，那麼在優先順序會議上擁有一位使用相同語言的平台產品經理將改變遊戲規則。
親愛的讀者們，我們來到了大結局！我們衷心祝願您的平台團隊一切順利——願您的收費公平，發布像黃油一樣順利！