在構建可擴展的軟件時，它是最關鍵的團隊。
現實沒有技術債管理團隊，也沒人願意加入這樣隊伍。這種團隊每天就是給其他開發人員收拾爛攤子，誰願意給別人擦屁股呢，畢竟又不是年薪百萬？
但確實有一些名字聽起來更專業的團隊，如基礎設施團隊、架構團隊、核心團隊，這聽起來是不是就吊炸天了？這種團隊負責處理所用應用程序的核心主體，如下圖中的核心協調/依賴項小組：
回想鴻蒙混沌時期，你剛開始開發，完全用不到核心團隊，牛逼到自己所在一個團隊就搞定所有事。然而，團隊也在壯大。我們現在需要更細緻分配工作，讓一些團隊負責特性交付，一些團隊負責公共代碼：
爲提升可維護性和可擴展性，負責公共代碼的團隊要探索開發跨各個特性團隊的代碼，以便重構、改進和更好地對齊。這項工作本質上和管理技術債是一回事。因此，把小組叫技術債管理小組挺合適。
別扯遠了，本文可不是教你小組命名規則，你大可叫它核心、基礎設施或架構小組——而是展示這樣一個小組面臨的各種挑戰，並探索對應的解決方案。
本文我將交替使用核心小組、基礎設施小組和架構小組這三姓家奴描述這樣一個小組的挑戰。
1 團隊的邊界
組建這個核心團隊時，團隊的邊界或範圍是什麼？
對某些組織，這裏沒有邊界。架構團隊負責一切事務。他們定義特性團隊的所有活動：他們編碼的方式、他們實現的類，等等。這樣這些活動就會高度一致對齊。
但這大大降低了特性團隊的靈活性。他們只能做出與架構團隊所提供的內容完全一致的東西。若想做一些超出架構團隊定義的事情，就要諮詢架構團隊。於是架構團隊成爲瓶頸。
由於這並不是理想局面，也許核心小組應該只負責所有現有的通用代碼。但是通用代碼的定義是非常模糊的。也許這些代碼只是一些常見的數據層和實用函數。如果我們將通用代碼定義爲所有特性小組都使用的代碼，那麼它只能是全部代碼的很小一部分。
這種結構很棒，因爲它讓每個特性團隊都可自由處理自己的特性，而不受核心團隊阻礙。缺點是（上圖不同顏色所示)每個特性團隊的工作方式有很大差異。潛在的通用模式、特性和數據可能以不同方式在各特性團隊復現，而沒人探索如何將它們抽象爲通用內容，因此開發工作的可擴展能力受限。
找到核心團隊應該負責的內容的正確邊界是一個棘手的難題。它還在很大程度上取決於核心小組的團隊能力，以及他們可以承擔多少職責。
可行方案
組建核心團隊的初始階段肯定很難。建議從小入手，定義核心團隊可負責，併爲特性小組帶來價值的一個重點領域，如一些實用函數。
隨時間推移，核心團隊能力也會提升，可接手更多職責。可抽象出跨各特性團隊通用的組件，並從那裏開始延伸。
2 靈活性與一致性
有時，組織需要讓架構小組定義其他所有團隊要遵守的標準或規則。該想法可追溯到工業化時代，標準化工廠生產車間更易擴大規模，浪費更少。
甚至OOP在早期也通過定義基類來推行一致性。基類由核心團隊定義，而特性團隊只需實現基類。
這種方法有很多收益，特性團隊無需自己實現通用代碼就可以享受它帶來的種種好處。以上圖，依賴項 1、2 和 3 都被注入基類，這樣特性類都可獲得它們而無需額外成本。
爲確保一致性，所有特性團隊都不應創建自己的基類。每個新類須由架構團隊經手。這樣做原因是避免跨特性團隊的意外重複類。若一個特性團隊想要新東西，只能與架構團隊覈對，看是否已有可用東西。如果沒有，架構團隊將爲他們製作所需的基類。
綜上，這是一種專制的開發方法，很難擴展，架構團隊成爲瓶頸。架構團隊提供東西可能無法滿足每個團隊需求。架構團隊可能疲於奔命，爲各團隊構建他們所需種種變體或他們提供的通用類無法被特性團隊充分利用。不管哪種都不理想。
相反，可走向另一極端：核心團隊不定義任何事情。只提供通用實用程序，特性團隊可考慮是否使用它們。正如最近行業首選的編程方法一樣，“人們更喜歡組合而不是繼承”，如下所示。
特性團隊沒有義務遵守基礎團隊提供的任何規範。對於基礎團隊提供的內容，他們可以只使用自己需要的東西，甚至什麼都不用。特性團隊擁有充分的靈活性，可以自由實現他們喜歡的東西。
這種極端方法也有自己的缺點。如果沒有對常見實踐的一定程度的定義，也沒有一致和對齊，各個團隊可能走上五花八門的道路。潛在的浪費和重新發明輪子的現象可能會出現在不少團隊中。
可行解決方案
我們要在：
- 需要遵守的規範
- 做哪些“有用的支持實用程序”
- 及介於兩者間的東西
之間平衡。對須遵循的規範，一個很好例子是分析需求，我們需要所有特性都有一致的觸發方式。至於“有用的實用程序”，這些工具可以是團隊能輕鬆採用的通用 UI 組件，讓他們無需創建新組件。（一些設計師可能會說這類組件需要完全一致，才能確保整個團隊的一致設計風格。）
介於二者之間的事物，顏色集就是一個例子。某些顏色需保持一致，而對其他顏色，特性團隊可靈活從一系列預定義顏色中抉擇。
不是每個人都會同意這案例，但聰明的你應該能明白。核心團隊需要與所有團隊合作，定義什麼是必不可少的、什麼是靈活的。這不是個簡單過程。
3 核心團隊的組成
好的，所以我們要組建一個核心/架構/基礎設施團隊。應該讓誰加入呢？一般會選擇一名專家開發和一名初級開發的組合（假設沒太多人才可選）。
那特性團隊呢？也許他們的組成與核心團隊是相同的。然後每個團隊都有相同的團隊成員搭配，公平分配。
雖然這聽着合理，但這種組成方式可能存在挑戰。須認識到：
- 核心團隊成員實現的是由所有人使用的通用組件或要設計與所有組交互的公共抽象。這不是初級開發能應付的。同時，不能只依靠一位專家開發定義一切
- 核心小組的主要“客戶”是特性小組，後者包含一組開發，其中還有一些專家。同樣，初級開發沒足夠能力來同更有經驗的“客戶”聯絡並做出可靠和有意義東西。只靠核心組中的一位專家開發來應付所有特性組也不夠
鑑於此，也許我們要在覈心小組配置所有專家開發。這要好得多，因爲在與特性小組合作時就能應對可擴展性的挑戰。但把所有專家都放在一個團隊，爲這個團隊定義方向可能就遇到麻煩。或許可在專家中找出一位領導，讓他來確定方向。
另一個挑戰是讓核心團隊支持多少個特性團隊。若後者數量太多，如何擴展核心團隊來提供最出色的交互和支持？
可行解決方案
在我看來，若想建立一個穩固的核心團隊，團隊肯定需要配置更多經驗豐富高級開發。該團隊要定義和開發大部分核心內容或可能是所有人都使用的架構，因此它的工作需在技術上足夠穩固可靠。
最重要的，若可以，我們應該在每個特性團隊中都配置一名來自核心團隊的大使（下圖特性組中的綠色人員），這會是很有價值的。在組織結構上，他們可以是特性團隊的成員，但他們在實踐中會積極參與決策以及核心團隊產品的開發。
他們在特性團隊中還能充當監督者，確保特性開發過程中進行必要調整，並持續定義核心團隊可擴展的領域。同樣，這位大使還需足夠技術經驗才能擔此大任。
這樣一來，核心小組領導者就要能管理一組專家開發，不僅包括核心小組內專家，也包括各特性組中的大使角色。
4 產品和利益相關者管理
通常有產品經理監督工作，判斷各種產品特性需要哪些改進。他們與利益相關者溝通，並不斷與客戶羣互動，找出接下來最佳的工作方向。
某特性的開發從產品經理那裏獲得單一輸入源，獲知下一步的開發方向和優先級。開發人員無需與利益相關者打交道。他們工作重心都在開發。核心小組不再直接處理外部使用的特性。他們不面對外部客戶。這裏沒有真正的“產品”，也無需團隊的“產品”經理。
但核心團隊確實有自己的利益相關者，他們就是各大特性團隊。核心團隊需要與一組開發保持聯繫，後者進行各特性的開發並交付成果。
與各特性小組中的開發聯絡、討論具體需求及對各需求優先級妥協等過程，需特定的產品和利益相關者管理技能。一般來說，開發不具備此類技能。若無合適的產品和利益相關者管理方法，小組就無法確定自身工作方向和重點，因爲每個特性組的需求可能截然不同。
可行方案
理想國中，這樣的小組會有一名技術產品經理，他既精通技術，又精通產品和利益相關者的管理工作。擔任該職的人也可以是小組技術負責人，他爲小組提供指導。他須有足夠時間工作，並與其他特性團隊聯絡，還須犧牲自己時間來專注技術工作。這是個艱難角色，因爲他在完成其他任務同時還不能讓自己技術退步！
退而求其次，另一種選擇是讓一位首席開發或架構師負責監督核心團隊，並對各特性團隊產生影響。處於該位的成員可設定產品重點和方向，以確保整個產品高層次上的優先級得到合理安排。核心團隊的各位成員（具有一定專業知識水平）可與各特性團隊一起確定更細節工作內容。
不管咋樣，利益相關者管理是確保核心團隊成功所需的技能，這種技能並非單純技術知識。
5 工作結果的可見性
我記得當我參與一個軟件特性的開發工作時，看到那個特性發布時我太高興了。我開發的軟件是由大衆使用。因此，當我看到朋友圈也在用那款軟件，我就告訴他們那是我開發的——多麼有成就感的事兒。
或者當有人問我做啥的，我很容易向他們展示自己的產品，告訴他們並讓他們瞭解我的工作。當一個軟件特性新版發佈，我可以讓他們去體驗。每次版本發佈後，我們一般都會開香檳慶祝。
但人們在基礎設施團隊工作時，這裏沒任何能讓外部用戶輕易看到的有形特徵。他們完成的工作可能只是又一個噁心枯燥的API或現有服務的一個新屬性——這種成果遠不足以發任何對外公告，看公告的用戶如果真看到這細枝末節東西，說不定還會很生氣。但沒有公告，他們所做的工作就不會被公衆注意。
有時，核心開發會改進核心庫，讓代碼更易維護或做輕微性能改進（如減少內存佔用）。這樣的工作不會改接口。使用核心庫的人們甚至都感覺不到。沒有人注意到或欣賞這些成果。
有時，核心庫會迎來新版發佈，但發佈公告看上去也就是那樣。若新版改進沒有給特性團隊帶來太多價值，後者可能還不會欣賞甚至謾罵前者。相反，特性團隊可能會討厭這樣的公告和更改，因爲他們必須多做一些事情才能使用新版庫或做一些更改才能適應新接口。
相比之下，若核心團隊成員編寫的代碼導致核心庫質量下降或影響特性團隊，那使用這些代碼的人們可能很快就會注意到。不開心的“客戶”可能會“升級”問題。
這樣的環境對團隊所做的工作評價很低，對他們犯的錯誤懲罰卻很高，於是核心團隊中的開發人員很快就會士氣低落，沒有人願意呆在這樣的團隊裏面。這個團隊現在實際上就是技術債管理團隊了：高風險、低收益。沒人願意加入這種羣體。
可行解決方案
也許核心團隊也應該像特性團隊一樣對待他們的工作。每次迭代都應該有要達到的里程碑。計劃中的內容（例如他們可以爲特性團隊或整個產品帶來的價值）應該提前讓大家知道，這樣大家就有了對新版本的期待。
核心團隊的領導需要與特性團隊協商制定高層計劃。領導還要跟蹤自己的團隊過去取得的所有成就。所有重大里程碑都需要慶祝一番。團隊的優秀作品需要廣泛傳播和分享。
關鍵在於讓核心團隊成員感受到其成果被他人看到和欣賞。畢竟，工作不只爲錢，也爲成就感。
6 成功的衡量標準
學術界，已有很多衡量產品成功的研究。有很多分析工作會探索軟件特性的使用情況及它如何轉化爲組織底線。
開發人員衡量一個特性是否成功，部分標準包括能否及時向用戶交付特性，以及特性的質量（例如崩潰率、資源利用率、性能）。
但核心小組如何衡量成功？他們甚至都沒有有形的、面向客戶輸出的產品。當然，我們可以說我們提供了這個庫、那個 API 服務，等等，但這樣做有什麼意義呢？拿組織底線來說，核心團隊如何爲組織的潛在成功做出貢獻？
可行解決方案
評價核心團隊成果的一種方式是，把它看作是爲公司提供所有所需計算機和基礎設施的 IT 部門那樣。它就像一個對支出做出重大貢獻的部門。
一般情況下，管理層希望儘可能優化這樣的部門的成本，除非這個部門能夠證明其貢獻，證明他們是如何提高所有人的生產力的。
因此，如果我們有一種方法來衡量特性小組獲得的生產力或開發擴展能力，那肯定是非常有價值的。也許一種簡單的方法是統計特性團隊使用了多少 API，當然這個例子太簡單了。這裏沒有一目瞭然的公式，說起來容易做起來難。
也許第一個衡量標準是特性團隊對核心團隊提供的支持的感受。如果所有特性團隊都感受到了核心團隊的價值，那至少是一個很好的開始。
沿着這些思路，有幾個行業案例展示了這樣一個核心或基礎設施團隊的巨大成就。一個例子是 AWS，它的服務器最初只是在亞馬遜內部提供服務，現在已經成爲亞馬遜最大的業務部門。
像 Airbnb 和 Square 這樣的公司也是類似的例子，他們開發了很多核心庫供其他開發人員使用，這對組織在開發社區中的聲譽做出了重大貢獻。雖然這些工作沒有直接的收入收益，但組織因爲這些成果而更容易招納人才了。
7 不斷變化的軟件技術
軟件開發是變化最快的行業之一，甚至可能是變化最快的。業內每年都會推出一些新的東西。有些變化是漸進的，有些是革命性的。
一般來說，核心基礎架構團隊或架構團隊負責定義特性團隊應該採用什麼技術框架來確保一致性。
這也意味着隨着軟件技術的不斷變化，核心團隊感到自己有義務站在曲線的頂端，並能夠正確識別出下一個要採用的最佳技術選項，然後朝着這個方向努力。
這也是我之前建議核心團隊應該由一羣非常瞭解並密切關注技術趨勢的專家組成的原因之一。
雖然理想情況下核心團隊可以推動這一進程，但它不是一個可擴展的解決方案，因爲核心團隊的開發人員只佔全體開發人員的一小部分。
可行解決方案
應對和探索最新技術趨勢的責任不應該只由核心團隊來承擔。每個小組的開發人員都應該對新事物充滿熱情。此外，如果我們不讓其他小組的開發人員成爲探索某些新技術的先行者，我們也是在打壓他們。
雖然核心團隊有責任向所有人部署最新技術，但每個團隊（包括特性團隊）都應該有試驗新事物並提出建議的自由。
這種自由很棒，因爲它可以跨團隊進行可擴展的探索活動。並非所有新學到的技術都應該被採用。從特性團隊中吸取的教訓可以幫助組織過濾掉不適合的技術。那些表現很出色的技術可以推薦給核心團隊，後者可以考慮讓其他團隊也採用它。
當然，出現相互矛盾的技術時，核心團隊是仲裁者並決定哪個應該優先採用。
8 總結
技術債管理團隊是組織希望擴展產品開發工作時必不可少的重要團隊。我們可以將其命名爲核心團隊、基礎設施團隊、架構團隊，甚至像 SWAT Team 這樣有趣的名稱。
爲了確保可擴展性，核心團隊需要在強制的一致性和放鬆的靈活性之間做出平衡，對特性團隊提供適當的支持。這種錯綜複雜的平衡只能與特性團隊之間緊密協作才能實現，這需要團隊具備穩定出色的技術能力，同時還要妥善管理利益相關者事宜。
雖然核心團隊可能沒有任何直接、有形、面向客戶的外部輸出，但它的貢獻對整個產品開發工作的成功都非常關鍵，所以應該是可見的。如果我們能夠量化它的工作，那將進一步確保團隊的貢獻可以持久，並提升團隊的士氣。
確保產品技術健康水平的責任不應僅僅由核心團隊承擔。所有團隊在產品的技術進步過程中都扮演着重要的角色。核心團隊負責仲裁和促進流程，確認所有團隊的重點方向。
組建這樣一個核心技術債管理團隊並不容易，維持和擴展它是更難的事情。但是，如果我們真的想擴大我們的開發規模，這樣的團隊是必不可少的。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都國企技術專家兼架構，多家大廠後端一線研發經驗，各大技術社區頭部專家博主，編程嚴選網創始人。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
參考：
本文由博客一文多發平臺 OpenWrite 發佈！