我還是一個年輕的，天真的軟件開發人員,我渴望結構和分析思維模式來設計最佳解決方案。
令我感到震驚的一件事是任意劃分團隊邊界。
令人驚訝的是，我正在從從事設計業務的領域進行思考。我對這個領域中不斷增長的動力感到非常興奮。通過結合團隊拓撲，映射，動態再分配和域驅動設計，我感到我們正在開始開發必要的工具，以有目的地，有效地設計現代技術組織。
總結一：將社會技術架構可視化爲戰略與投資
在覈心領域上佈置您的技術能力可以傳達技術戰略的各個方面。它顯示了您認爲哪些功能是實現業務目標的關鍵。
核心領域是關鍵戰場，提供比競爭對手更具吸引力的產品至關重要。通用服務只是構成了一個平臺，使核心領域的團隊能夠更頻繁，更經濟地交付價值。（banq注：平臺團隊和業務團隊的區別）
通過發現核心、通用和支持領域就能表達對價值所在的信念。但是策略是需要做出選擇的，是關於資源分配的，需要選擇專注於某些事情而犧牲其他事情。
因此，團隊管理的重點在於需要檢查：我們所說的重要內容是否與我們實際投入時間和資源的方式保持一致？
首先。量化或可視化的第一步是爲核心子域、通用和支持三個子域中的功能分配FTE（全職等效僱員），根據投入FTE數量來代表你的實際投入實際和資源，當然您也可以改用預算或其他承諾指標。
總結二：優化投資
當您重視了技術遠景和投資時，就會出現許多問題和選擇。你會發現：爲什麼我們要爲支持子域分配FTE數量是核心域的兩倍？”，也就是說，寶貴資源並沒有投入到核心子域上。
追查原因時，我們可能會發現是因爲意外的複雜性：這些都是我們的舊代碼庫，使用起來非常痛苦。如果代碼更易於更改，並且需要的實時支持更少，那麼我們只需要一半的人員。
通過減少這種意外的複雜性，FTE將被投放在覈心域上工作。
下一步是降低意外複雜性的成本並衡量預期收益。我們知道數字並不能完全準確，但是我們可以做出更明智的風險/回報決策。
我們可以想象有無窮的戰略作用。關鍵是我相信在可視化信念和承諾以及在可視化條件下可以協同模擬和評估策略性行爲方面具有巨大優勢。
根據我的經驗，這個門檻太低了，以至於即使是這種簡單的方法，對許多公司來說也是一個很大的進步。
總結三：分析團隊之間的關係
無論我們多麼努力，軟件組件和管理它們的團隊之間總會有依賴關係。大型企業級別的計劃將導致跨多個團隊的工作計劃。
我們需要可視化團隊之間的依存關係，並量化這將如何影響我們執行策略的能力：還是要將大部分精力投入到我們的核心領域。
我喜歡將團隊拓撲交互模式用作描述團隊之間關係類型的語言。如果您不熟悉，這裏有一個簡短的介紹：
X-as-a-service：X-as-a-Service：一個團隊提供了一些技術功能，例如API，其他團隊卻在最少的支持和協作下就可以使用它們。
協作：多個團隊緊密合作，以完成大量工作
促進：一個團隊暫時在幫助另一個團隊實現目標
在覈心領域圖表上顯示這些關係會突出我們可能沒有意識到的重大問題或機會。
總結四：定義團隊邊界
強調團隊和軟件邊界之間的依賴性爲更高級別的組織設計奠定了基礎。瞭解軟件中的哪些變化是確定團隊組織方式的關鍵。
不幸的是，系統的共同變更是多維的。系統的不同部分將根據待辦事項中的內容進行共同更改和不同時間。通過可視化這些依賴關係，我們可以針對要優化的哪種類型的合作變更做出戰略決策-我們以最能使我們改善核心領域的方式組織團隊。
組織團隊還有另一個方面，那就是超越物理界限。這是團隊根據他們正在發展的概念的演變而定的心態。
在高度未知的空間中具有很大的不可預測結果的大賭注核心領域需要發現心態。學習速度是關鍵，這意味着流程和技術實踐會發生變化。
應該根據團隊的實際聯繫或開發的產品的心態對團隊進行分組（這就是Simon Wardley所說的“ 先驅者”，“定居者”和“城市規劃者”）。
量化或可視化這些關係會迫使我們考慮由此產生的動態以及它們如何影響我們的戰略選擇。爲了充分利用我們核心領域的機會，我們需要仔細，自覺地考慮社會技術架構的各個方面。