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