平台團隊如何完成任務

「平台」> 內部開發人員平台

目前關於平台工程有很多熱門話題，主要集中在內部開發者平台 (IDP)。我要澄清的是，這裡對「平台」的討論範圍要廣泛得多，它涵蓋了其他內部產品，例如資料平台、前端設計系統或實驗平台。

事實上，雖然我們主要關注技術平台，但這裡提出的許多想法也適用於提供共用業務功能的內部產品，例如金融科技公司的資金流動服務或電子商務公司的產品目錄服務。統一的特徵是平台是組織內其他團隊使用的內部產品。因此，平台團隊正在建構產品，其客戶是公司內的其他團隊。

移轉作業範例

我們在談論哪些類型的變更？一個相對簡單的遷移將是版本升級 - 升級共享元件庫，或升級服務的基礎語言執行環境。

常見的較大規模遷移將是使用內部包裝取代第三方系統的直接整合 - 例如，將記錄、分析或可觀察性工具轉移到使用由平台團隊維護的共享內部庫，或使用某種內部閘道服務取代與支付處理器的直接整合。

另一種遷移類型可能是將現有整合替換為已棄用的內部服務，並整合到其替換服務中 - 可能從舊的使用者服務轉移到新的帳戶設定檔服務，或將信用拉取和信用報告服務的使用遷移到新的整合信用機構閘道服務。

最後一個範例將是基礎架構層面的重新平台化 - 將產品團隊擁有的服務 Docker 化，引入服務網格，將服務的資料庫從 MySQL 切換到 Postgres，諸如此類。

請注意，對於平台遷移，產品團隊通常沒有特別的動機進行這些變更。有時會有，如果新平台將提供一些特別令人興奮的新功能，但通常會要求他們作為更廣泛的架構計畫的一部分進行此轉移，而實際上並沒有獲得大量的價值。

合作模式

讓我們看看哪些跨團隊協作模式適用於平台遷移工作。

外包工作

平台團隊可以在產品團隊的待辦事項中提交問題單，要求他們自行進行必要的變更。

這種方法有一些優點。它是可擴充的 - 實作工作可以外包給所有需要處理程式碼庫的產品團隊。它也是可追蹤且易於管理的 - 通常可以由程式經理或其他專案管理類型的人員提交問題單。

然而，也有一些缺點。它真的很慢 - 在某些產品團隊開始執行工作之前，將會有很長的交貨時間。此外，它需要優先順序的角力 - 經常被要求執行此工作的團隊通常不會獲得有形的利益，因此他們自然會將此工作降級，優先處理其他更緊急或更有影響力的任務。

平台團隊執行工作

平台團隊可能會選擇使用三種相似但不同的模式來對產品團隊的程式碼庫進行變更 - 輪值、可信賴的外部人員，或 內部開放原始碼。

使用 輪值，來自平台團隊的工程師會「嵌入」產品團隊並從那裡執行工作。

使用 可信賴的外部人員 和 內部開放原始碼，產品團隊會接受來自平台團隊工程師的程式碼庫拉取請求。

就像採用檔案票證路徑一樣，讓平台團隊執行工作會帶來一些優缺點。

在優點方面，這種方法通常會縮短進行變更的交貨時間，因為需要執行工作的團隊（平台團隊）也是執行工作的團隊。一致的誘因意味著平台團隊比擁有程式碼庫的產品團隊更有可能優先處理其工作。

在負面方面，讓平台團隊自行執行遷移工作只有在產品團隊可以支援的情況下才有效。他們需要願意讓平台工程師加入他們的團隊一段時間，或者他們需要已經與平台工程師花費足夠的時間，以至於他們相信平台工程師可以獨立對其程式碼庫進行變更，或者他們需要進行重大的投資來支援內部開放原始碼方法。

另一個缺點是這種自己動手做的策略無法擴展。與產品交付團隊相比，平台團隊的工程容量總是較少，而且不將工程工作委派給產品團隊會讓所有容量都無法使用。

實際上，情況有點複雜

實際上，通常會發生這些方法的組合。負責遷移的平台團隊可能會讓計畫經理提交 15 個產品交付團隊的票證，然後花一些時間勸說他們執行工作。一段時間後，有些團隊會自行完成工作，但會有一些落後者特別忙於其他事情，或特別不願意承擔遷移工作。然後，平台團隊將捲起袖子並使用其他一些可擴充性較低的方法，並自行進行變更。

合作模式

許多平台團隊的崇高目標是建立一個完全自助服務的平台 - 類似 Stripe 或 Auth0，文件編寫完善且易於使用，產品工程師可以使用該平台，而無需平台團隊的任何直接支援或協作。

實際上，大多數內部平台並非如此，尤其是在早期階段。開始使用內部平台的產品工程師通常會遇到文件編寫不佳、錯誤訊息模糊不清和令人困惑的錯誤。通常，這些產品團隊會舉手投降，並要求平台團隊協助他們開始使用內部平台的功能。[1]

當平台使用者要求平台所有者提供實際支援時，我們會回到跨團隊協作，並且再次出現不同的模式。

專業服務

有時產品團隊可能會要求平台團隊為他們撰寫平台使用程式碼。這可能是因為產品團隊難以找出如何使用平台。或者，這可能是因為這種方法需要產品團隊付出的精力較少。有時只是誤解，產品團隊不認為他們應該自己做這項工作 - 例如，在轉移到產品團隊自行服務其基礎設施需求的 devops 模型時，可能會發生這種情況。

在這種情況下，平台團隊在工程組織中變成了一個小型的專業服務小組，代表客戶將其產品整合到客戶的系統中。

這種專業服務模型使用多種協作模式。首先，產品團隊通常會 提交工單 要求平台團隊提供服務。這是我們先前在平台遷移工作中看過的相同模式，但相反 - 在這種情況下，是產品團隊向平台團隊提交工單，請求他們的協助。然後，平台團隊可以使用 受信任的外部人員 或 內部開放原始碼 模式來執行工作。

這種協作模式的一個常見範例是產品團隊需要一些基礎設施變更時。他們想要啟動一項新服務、使用 API 閘道註冊一個新的外部端點，或更新一些組態值，因此他們向平台團隊提交工單，要求他們進行適當的變更。

這種模式通常在基礎設施空間中可見，因為它延續了一種既有的習慣 - 在自服務基礎設施之前，提交工單一直是產品團隊進行基礎設施變更的標準機制。

白手套導入

對於處於早期階段且缺乏良好文件說明的平台，平台團隊可能會選擇使用「白手套」方法來協助新產品團隊，與這些早期採用者並肩合作，讓他們入門。這有助於透過減輕率先採用平台的產品團隊負擔，來啟動新平台的採用。它也可以讓平台團隊深入了解其第一批客戶實際如何使用平台功能。

這種白手套模式通常使用 職務巡迴 協作模式來達成 - 一位或多位平台工程師會花一些時間嵌入到使用團隊中，在該團隊內執行所需的平台整合工作。

實務社群

隨著平台成熟且變得更容易使用，平台團隊可以不再進行實際的整合工作，而轉為擔任更具諮詢性質的角色。

此諮詢模式包含類似舉辦「辦公時間」讓消費團隊可以出現並提出問題，或讓平台代表提供專注的建議和指導給消費團隊的規劃和設計會議。在 團隊拓撲 術語中，這將是平台團隊以促進互動模式運作。

對於大型、豐富的平台，最終會朝向同伴支援模式，其中平台團隊投資時間為其平台使用者建立實務社群。這可能包含類似社群 Slack 頻道或寄件清單、定期實務社群會議以尋求協助和展示有趣的點子，甚至可能是年度從業人員外展活動。

親力親為難以擴展

我們可以看到平台團隊需要提供給消費者的實際支援層級會因平台的開發人員體驗成熟度而有很大差異，也就是文件編寫得有多好，整合和操作有多容易。

在平台的早期，平台消費需要平台團隊本身投入大量精力是有道理的。開發人員體驗仍然有些坎坷，平台功能可能仍在建置中，而消費團隊可能有點懷疑是否要投入自己的時間當作白老鼠。此外，與產品團隊並肩合作是平台團隊了解其客戶及其需求的絕佳方式！

然而，實際支援無法擴展，如果廣泛的平台採用是目標，那麼平台團隊必須投資於其平台的開發人員體驗，以避免淹沒在實作工作中。

清楚地向平台使用者傳達他們應該期待什麼支援模式也很重要。在平台採用初期已收到白手套支援的產品團隊會期待在未來再次享受這種體驗，除非另行通知！

提出問題單

產品團隊可以 提交問題單 給平台團隊，要求他們對其平台進行必要的變更。這往往是一種令人沮喪的方法。產品團隊通常只在需要時才意識到平台缺少某項功能，而讓平台團隊優先處理並執行工作的周轉時間可能太長，平台團隊通常會因大量的內部要求而超載。這導致平台團隊成為瓶頸，阻礙產品交付團隊的進度。

將工程師調派至工作

如果時間充裕，團隊可以透過暫時重新指派工程師來填補平台功能的空白，以執行必要的平台強化。產品工程師可以在平台團隊進行 職務輪調，或者平台工程師可以作為 嵌入式專家 暫時加入產品團隊。

在團隊之間調動工程師不可避免地會對生產力造成短期影響，但擁有嵌入式工程師可以透過減少產品和平台團隊之間所需的跨團隊溝通量，從長遠來看提高效率。嵌入式工程師擔任大使，暢通溝通管道，減少電話遊戲。

此固定前期成本和持續效益的等式表示重新指派工程師是專為大型平台改進保留的最佳選項 - 將工程師移至其他團隊數週會造成更多干擾，而非有所助益。

這些類型的暫時指派也需要相對成熟的管理結構，以避免嵌入式工程師感到孤立。對於嵌入式專家 - 被重新指派至產品團隊的平台工程師 - 也存在風險，即他們可能變成只執行平台消耗工作，而非積極處理產品團隊需要的平台改進的「額外幫手」。

遠端處理平台

如果平台團隊已採用 內部開放原始碼 方法，則產品團隊有選項可自行直接實作所需的平台變更。平台團隊的角色將主要為諮詢，提供設計建議並檢閱產品團隊的公關。經過幾次公關後，產品工程師甚至可能從平台團隊獲得足夠的信任，取得提交位元並成為 受信任的外部人員。

許多平台團隊渴望達到此狀況 - 如果您的客戶有能力實作自己的改進，並讓您免於執行工作，那不是很棒嗎！然而，內部開放原始碼的現實與一般開放原始碼類似 - 支援外部貢獻需要驚人的投資，而絕大多數消費者並未成為有意義的貢獻者。

平台團隊應小心不要在未進行周全投資以支援這些貢獻的情況下，向外部貢獻開放其程式碼庫。如果平台團隊在全體會議中自豪地宣稱其程式碼庫是共享資源，但隨後發現自己一再告訴其他團隊的貢獻者「不，不，不是那樣！」，可能會造成全面的嚴重挫折。

合作，但僅限於一段時間

在「團隊拓撲」中，他們指出設計兩個團隊之間良好邊界的最佳方式是最初以專注、高度協作的方式共同作業，想想像是 嵌入式專家 和 職務輪調 這樣的模式。這段期間可用於探索在系統之間和團隊之間建立最佳邊界和介面的地方（康威定律告訴我們這兩者是密不可分的）。然而，「團隊拓撲」的作者也警告，重要的是不要長時間處於這種協作模式。平台團隊應該努力定義他們的介面，尋求快速轉移到「即服務」模式，使用像是 提交問題單 和 內部開放原始碼 這樣的模式。正如我們在「平台使用」部分所討論的，更具協作性的互動模式根本無法擴展到平台團隊的程度。此外，協作模式會對使用團隊施加更大的認知負擔，轉移到更免動手的互動方式，讓產品交付團隊可以花更多時間專注於自己的成果。事實上，「團隊拓撲」將認知負擔的減少視為平台團隊的定義目的，我非常同意這種架構。

在我看來，從高度協作轉變為即服務，是年輕的平台團隊面臨的最大挑戰之一。您的客戶會習慣高接觸體驗。建立良好的文件很困難。說不很難。

以協作模式運作的平台團隊應密切注意擴充挑戰。隨著對轉向更具擴充性、不干預方式的需求浮現，平台團隊應開始向其客戶傳達此轉變。提早警告互動模式將如何改變，以及原因，讓產品團隊有機會準備並開始將其平台心智模式轉移到更能自給自足的方向。

轉型可能是痛苦的，但猶豫不決會讓情況更糟。產品交付團隊會感謝平台供應商清楚傳達的參與規則，說明他們將如何提供支援。此外，移除親自協作的拐杖，會強烈激勵改善自助服務介面、文件等。康威定律在此發揮作用，重新定義團隊如何整合，將對團隊系統如何整合施加壓力。