運營多個專注於各自技術業務領域的平臺比運營一個平臺團隊更好。平臺思維是關於促進演進的，而不是關於重用的，而專注於重用會破壞這種機會。將平臺思維灌輸到所有團隊中，給自主領域和平臺出現的機會，而不應強加於事。
超過一定規模的大多數技術公司都開始考慮創建一個內部平臺團隊來構建/管理供多個團隊/產品使用的系統。這是一個槓桿率非常高的團隊，因爲他們可以同時對許多產品產生有益的影響，併爲能給組織帶來巨大的動力。但是，今天，我想提出一些內部平臺團隊無法順利工作的情況，至少我遇到過這樣的情況。
TL;DR——運營多個專注於各自技術業務領域的平臺比運營一個平臺團隊更好。平臺思維是關於促進演進的，而不是關於重用的，而專注於重用會破壞這種機會。將平臺思維灌輸到所有團隊中，給自主領域和平臺出現的機會，而不應強加於事。
這個團隊是做什麼的?
擁有一個獨立的平臺團隊通常意味着所有水平關注點都會被推到他們身上。最終，這個團隊將無法識別它的客戶，只能以支持許多有用但互不關聯的系統而告終。很難爲這樣的一家公司設定目標和“北極星”，因爲它們“從定義上”就是與最終用戶脫鉤的。這樣團隊的唯一目的是在不考慮這些系統的目的和運行這些系統所需的專業知識的情況下，最大限度地重用組織內的這些系統。
更糟糕的情況是，其他團隊會毫無顧慮地構建可重用的組件。但是，當涉及到在生產中支持重用、尊重其他團隊的SLO和SLA時，人們會立即開始尋找平臺團隊來進行操作。其結果是，一個操作繁重的中央小組一直忙於滅火，因爲他們對自己所擁有的東西缺乏瞭解。
隨着公司共享用例數量的增加，平臺團隊將會變成各種無連接的組件的存儲庫，這些組件的業務用途與這些組件是分離的。最終，我們得到了一個“團隊”，但這個團隊的成員根本不知道其他人在做什麼，因爲每個成員最終都只專注於各自的某個部分。我們有技術專家，但他不是對業務影響最大的領域專家。如果業務開始陷入困境，平臺團隊及其工作通常是第一個被砍掉的。這是因爲很難向業務方解釋這批“準專家”是如何幫助他們賺錢。
開發人員淘金熱
從根本上講，對於一個組織的技術棧，採用流行的二維視圖是不合理的。它會使我們產生偏見，認爲底層的事物在本質上更基礎或更復雜。當然，底層比上層支持更大的“規模”。所有這些都會導致開發人員急於加入剛剛孵化出來的內部平臺團隊。在某種程度上，這項工作被視爲是對組織來說更具聲望或更爲核心的。事實上，在本質上講，它充其量是更技術性的，這樣開發人員就不必處理現實世界的混亂，不必面向客戶的產品了。
這在很多方面對組織構成了挑戰。一個是管理誰來做什麼，以及哪些角色被認爲很酷（爲什麼非平臺角色不被視爲“業務特性”，而是“出色的工程”）。另一部分是管理最終形成團隊的期望值，創建團隊很容易，但是要讓他們保持以業務/客戶爲中心比預期的要困難。許多平臺團隊都深陷到了一種混合狀態中，即技術傲慢且與客戶脫離，這使得他們的實力遠遠低於他們的能力。
其他團隊就不是平臺團隊?
如果有一個平臺團隊，那麼是否意味着其他團隊就不是平臺團隊了？有了一個“無所不能”的團隊，其他團隊開始放棄平臺思維，開始在產品孤島中思考。
如果平臺化是有價值的，那麼它應該是所有團隊的心態和策略，而不是單個團隊的領域。由於所有業務問題都是由領域和組織環境所組成的，因此有理由認爲，所有團隊都應該生產和運營平臺化組件。這些平臺可以在其他團隊所擁有的平臺之上生成。平臺或通用產品的目的不僅僅是重用，而且要爲集中組織專業知識的領域邊界進行建模。平臺團隊不能在任何出現水平組件的地方都繼續使用它們，因爲那樣他們必須是業務各個方面的專家。擁有底層可重用事物的平臺團隊的典型定義與組織的工作方式並不兼容。
這導致我們……
所有權範圍
一個公司的技術棧可以通過頂層的高階系統抽象和底層的低階系統抽象進行可視化。這意味着，操作架構的技能集可以隨着你的深入而發生很大的變化。這就證明了較低層與較高層的“不同”，應該以不同的方式進行管理。
當我們看技術棧時，所有權範圍應該如何運行？它們應該沿着具有類似抽象級別的組件水平運行，還是應該垂直運行，將系統分組以生成端到端的業務價值？
如果你正在運行一個自主的、跨職能的團隊（許多公司都聲稱要這樣做），那麼技術棧的深度是否重要？這個團隊的基本前提是能夠在技術棧的所有級別上工作，並且在每個級別上與其他團隊都能保持鬆散的一致性。在這種情況下，建立一個具有固定水平章程的平臺團隊的想法是毫無意義的。每個團隊都會創建自己需要的平臺層，並根據需要與其他團隊共享。這樣可以保持低開銷的對齊流程的運行，因爲創建組件不僅僅是爲了重用，它首先是爲了使用而創建的，然後纔是在需要時再進行重用。
這種所有權還解決了孤立組件的問題，每個人都非常依賴這些孤立組件，但又沒有一個團隊對其進行維護。開源對於編寫代碼來說是個好主意，但對於操作來說卻是個糟糕的主意。軟件必須有一個可操作的所有者——一個負責確保軟件按預期運行並達到預期基準的團隊。自主團隊操作他們構建的東西，如果我們可以教會他們如何構建平臺，那麼我們就不需要明確地創建平臺團隊了。
話雖如此，但反對自主團隊的一大論點是，他們往往最終不得不做一堆重複的工作。這顯然是次優的，那麼我們如何才能將其最小化呢。
解決重用問題
這個問題可以通過以平臺化的方式解決所有問題來最小化，這樣，一旦被創建出來，所有團隊都可以從出現的系統中獲益。在調整發布日期等方面可能存在短期問題，但從長遠來看，某個特定功能或實體的所有用例開始集中在一個地方。
然而，這並不意味着構建這個平臺的團隊不再擁有它。重用並不意味着將所有權與創建分離。一個設計良好的平臺旨在將平臺團隊排除在客戶的決策週期之外（外部可編程性），因此，如果一個通知平臺是由營銷團隊構建的，並且它被其他許多人所採用了，那麼營銷團隊可以繼續擁有並運營它，這沒什麼錯。
一旦一個可重用的東西找到了3個以上的客戶（Atwood定律），那麼可能是時候考慮一下這是一個橫向的責任，並把它轉移到一個單獨的團隊。我並不是說把它轉移到一個通用平臺團隊，而是轉移到一個特定的團隊，這個團隊可以專攻組件建模領域，並致力於將其發展以使其所有客戶都受益。例如， 一個通知系統可以完全啓動一個全新的商業領域，它本身就是小一點的Twilio。或者，它可能只是一種共享的技術能力，如託管Elasticsearch，可以由存儲平臺團隊/ES平臺團隊中的存儲/Elasticsearch專家團隊來處理。
上面的例子表明，如果團隊最初擁有其工作中的所有抽象級別（也就是全棧團隊），那麼新的團隊和領域可以從每個團隊的工作中派生出來，這些團隊和領域可以在相同的抽象級別上產生。從某種意義上說，新領域是一個全新的可重用組件。我們通過對組件進行分層來垂直擴展組織，並且這些層是在彼此之上創建可重用組件的。我們還通過添加需要解決的全新問題空間來水平擴展組織，而每一個問題空間反過來又會帶來新的深化機會。
這種有機的過程與固定的、共同定位的平臺憲章的理念背道而馳。“平臺團隊”的概念混淆了所有權和重用的概念，正如它混淆了技術棧中平臺的“深度”與領域知識的概念一樣。我認爲最好是從特定領域的團隊角度來考慮，每個團隊都開發自己的平臺，並在發現冗餘或重用時跨團隊轉移併合並。
在我看來，今天唯一的平臺團隊是基礎設施團隊（管理硬件設備），也許還有身份驗證/授權團隊，甚至我認爲這些都是業務/技術能力，而不是重用/技術棧深度驅動的團隊。所有其他平臺都應該來自產品團隊內部。想想細胞分裂而不是神之手。
原文鏈接：
https://kislayverma.com/organizations/a-case-against-platform-teams