BBC如何使用團隊拓撲構建內部核心平臺?
在軟體工程方面,我們的願景是讓 BBC 以其工程和內容而聞名。為此,我們必須進一步發展 BBC 作為產品和技術公司的理念。
我們的資產中有數百個微服務,所以我們有跨學科團隊負責每一個。我們盡最大努力在賦予每個團隊權力和確保我們全面進行高度協作之間取得平衡。
我們希望 BBC 以其工程質量和內容質量而聞名。
背景
BBC 網站由多種數字服務組成,包括iPlayer、Sounds、News和Sport。
每項服務本身就是一項主要服務——每週有數百萬次訪問——而且它們在幾年內相互獨立發展。
這反映在組織的形成方式上——每個數字服務都由不同的部門負責。
服務之間存在不匹配的技術和重複。許多功能儘管在概念上相似,但被多次實施——總維護成本也支付了多次。跨領域能力——例如個性化和分析——是每個產品開發團隊必須自己解決的主要任務。
WebCore
這是一項名為 WebCore 的更廣泛計劃,WebCore 是重新構想 BBC Online 併為所有數字服務建立單一網站的戰略的一部分。
對單一技術集進行標準化,建立共享的 "水平 "能力,並在團隊之間共享商品元件--將使BBC更好地利用技術,為觀眾建立更多的創新功能。
WebCore 既是對組織的重構,也是對技術的重新實現。
高度自治對於高績效的產品開發團隊至關重要。之前解耦的技術棧讓自治更容易實現,所以 WebCore 策略迫使我們思考如何平衡自治與標準化技術。
跨越組合變得困難
BBC 數字產品的演變反映在與數字服務所有權相一致的內部部門結構中。
跨越這些傳統的部門界限例如,改進將新發布的內容呈現給觀眾所需的時間是長而困難的。
一個早期的改革辦法是建立一個新的內部部門,稱為核心服務——一個不以提供面向受眾的服務為導向的部門(核心平臺部門)。
WebCore 平臺是一個內部產品,由一組通用元件(系統、服務和框架)組成,客戶是內部產品開發團隊。(核心平臺共享給其他產品線,屬於共享核心)
這些團隊不是將成功建立在觀眾參與度上,而是努力在整個組織中提升併為依賴平臺的租戶團隊提供支援。
隨著時間的推移,使用該平臺的團隊數量不斷增加。
不久之後,超過 100 名工程師正在建立元件——跟蹤正在製造的元件變得更加困難。
早期“零重複”的高標準正在製造摩擦:團隊如何快速行動、迭代並保持好奇而不造成重複?
答案是對技術債務形成一種更務實的心態:技術債務並不總是壞的,零債務帶來高成本。
就像金融債務一樣,技術債務並不總是壞事。
如果債務不被追蹤、變得過大或無法追究債務人的責任,債務就會成為問題。
這突出了一個重要原則:必須將控制權從核心平臺部門轉回給其使用方:租戶團隊。
使用共享技術已經在新的核心平臺團隊中產生一種被剝奪權力的感覺。
當產品開發團隊習慣於擁有和控制其整個技術堆疊時,轉向依賴他人的情況可能會讓人不舒服。
然而,從作業系統到框架,沒有一個團隊是從零開始編寫所有東西的。
團隊拓撲——互動模式
在早期階段,我們傾向於將支援視為“核心團隊和租戶使用者團隊之間的協作”。
這在早期是合適的——一切對每個人來說都是新的,互動團隊的數量是可控的。然而,隨著貢獻元件的團隊數量的增加,我們現在對我們可用的團隊之間的一系列互動模式有了更細緻的瞭解。
協作:這是一個團隊共享相同任務的時候。當多個團隊在這種模式下互動時,它可能看起來像是一個跨團隊的小隊,他們整天、每一天、在同一個任務上工作很長時間。非常適合開拓。
合作/促進:這看起來像是一種支援模式;我們有團隊可以在需要時尋求幫助的機制。它也可以是關於鼓勵跨社群支援,無論是來自主題專家還是來自更廣泛的產品開發社群。非常適合定居。
系統化 - 這是關於消除人工干預。它可以是檔案、流程、工具或使用者介面。對town planning來說是完美的。
協作是昂貴的,但當新的領域被打破時是理想的。它加速了租戶和核心平臺團隊之間的反饋,使平臺中的差距得以迅速解決。然而,它本質上是一種人工干預,而且不能擴充套件。
系統化是指消除人工干預,是平臺的地平線目標。當模式被證明了,那麼後面的團隊就可以踏上這條路了。
黃金路徑工具可以用來加速團隊,使他們保持在已知的良好路徑的護欄內。
在這些護欄的範圍內,租戶團隊有高度的自主權,可以在最小的阻礙下向他們的受眾提供服務。
合作和促進是這兩者之間的灰色中間地帶。雖然工具和程式可以減輕一些負擔,但這始終是可能需要的。
尋求幫助的個人、人員流動等總是會產生這樣的需求。
經驗教訓
這並不總是美好的--但這是一個迷人的旅程,我想很多組織都會踏上這個旅程。
圍繞正確的任務進行組織--無論是團隊還是部門結構,這都是創造一致性和團體凝聚力的主要方式。如果它不正確,結果也不會是這樣。
最佳化,不要理想化--有很多人分享和貢獻於同一個程式碼庫,需要有一些規則來保持每個人的正直和狹隘。
在人與人之間,儘量把這些作為經驗法則。隨著時間的推移,使用儀表板和工具來指導人類,並讓機器人來創造執行。
一起工作,但要深思熟慮--分享技術將需要工程師與其他工程師跨越傳統的組織邊界合作。這很容易讓人不知所措,所以要根據情況選擇正確的互動模式。可能沒有一個單一的最佳互動模式,所以需要一個混合的方法。
從平臺的角度來看,關鍵是要努力擺脫困境,讓租戶團隊不受阻礙地交付。這意味著要堅持不懈地尋找並消除開發生命週期中平臺所帶來的障礙。這可能意味著為租戶團隊提供控制--配置、工具、使用者介面等,但也可能意味著同意並執行某些標準。
自主性不是銀彈--如果團隊之間沒有一致性,自主性會滋生低效率和低價值的變化。統一可以透過組織有明確目的的人和團隊來創造。它也可以透過一個有意見的平臺來創造--這個平臺使做正確的事更容易,做錯誤的事更難。在這些約束條件下,有很多高度團隊自主的空間。
WebCore的最終成功將隨著時間的推移而得到衡量:
在未來的十年裡,優秀和創新的數字產品將為BBC的觀眾提供資訊、教育和娛樂。這種組織結構的重構是在最佳化標準化的商品元件和創新功能所需的自主權之間的一種權衡。
改變是困難的。當人類參與到像產品開發這樣複雜的、創造性的和技術性的工作中時,保持對大局的關注可能是一個挑戰。但是,透過認識到一個組織是一個系統--儘管是一個非常複雜的系統--我們就可以運用槓桿來引導有效的變革。
相關文章
- Pipefy如何使用團隊拓撲方法建設敏捷團隊?敏捷
- AdHoc使用團隊拓撲方法打造其工程團隊
- 團隊拓撲快速參考圖
- 架構團隊如何重構內部系統架構
- 企業如何構建內部開發者平臺?
- DDD、Wardley對映和團隊拓撲
- 什麼是DevOps團隊拓撲? - atlassiandev
- 什麼是Spotify模型的團隊拓撲?模型
- [Apache][Nginx]構建僅對團隊內部公開使用的web應用ApacheNginxWeb
- 團隊拓撲:減少軟體團隊的認知負擔 - mimacomMac
- 加拿大如何在社保數字領域內實施產品管理和團隊拓撲?
- 如何低成本,快速構建企業 Wiki 和團隊知識分享平臺
- 智和網管平臺·拓撲,構建“智慧發現 動態感知”的視覺化智慧運維平臺視覺化運維
- TeamTopologies/Team-API-template:用於定義團隊拓撲中團隊API 的模板API
- 使用團隊拓撲發現並提高敏捷DevOps可靠性質量 - joaorosa敏捷devROS
- 聊聊如何構建自驅團隊(3)
- 網路拓撲結構
- 團隊拓撲:軟體與組織之間的完美融合 - Matthew Skelton
- DDD與團隊拓撲以及微服務之間的關係圖 - aleixmorgadas微服務
- 私有云:基礎平臺部門如何為企業內1500名工程師構建PaaS?- srvaroa工程師
- 聊聊自驅團隊的構建
- 建設 TiDB 自動化平臺:轉轉 DBA 團隊實踐TiDB
- Shadow DOM 內部構造及如何構建獨立元件元件
- 大資料分析平臺如何構建大資料
- CMP雲管理平臺該如何構建?
- 拓撲排序排序
- Noc拓撲
- 聊聊自驅團隊的構建(二)
- 聊聊自驅團隊的構建(四)
- 構建dubbo分散式平臺-maven構建ant-framework核心程式碼Base封裝分散式MavenFramework封裝
- 事件風暴建模中Wardley Maps和團隊拓撲型別對元件的影響 - Markus事件型別元件
- 2022年DDD新書推薦:領域驅動設計+Wardley對映+團隊拓撲新書
- 如何構建測試團隊的軟實力 - 高學文
- Spring Boot 構建多租戶SaaS平臺核心技術指南Spring Boot
- Docker Buildx使用教程:使用Buildx構建多平臺映象DockerUI
- 拓撲排序,YYDS排序
- 騰訊雲容器團隊內部Istio專題分享
- 事件風暴創始人Alberto:團隊拓撲和DDD上下文對映的關係事件