使用DDD等方法實現社會技術架構和團隊管理：你的經理還用拍腦袋劃分團隊嗎？ - Nick Tune

將社會技術架構視覺化為戰略與投資
在核心領域上佈置您的技術能力可以傳達技術戰略的各個方面。它顯示了您認為哪些功能是實現業務目標的關鍵。
核心領域是關鍵戰場，提供比競爭對手更具吸引力的產品至關重要。通用服務只是構成了一個平臺，使核心領域的團隊能夠更頻繁，更經濟地交付價值。（banq注：平臺團隊和業務團隊的區別）

透過發現核心、通用和支援領域就能表達對價值所在的信念。但是策略是需要做出選擇的，是關於資源分配的，需要選擇專注於某些事情而犧牲其他事情。
因此，團隊管理的重點在於需要檢查：我們所說的重要內容是否與我們實際投入時間和資源的方式保持一致？
首先。量化或視覺化的第一步是為核心子域、通用和支援三個子域中的功能分配FTE（全職等效僱員），根據投入FTE數量來代表你的實際投入實際和資源，當然您也可以改用預算或其他承諾指標。

最佳化投資
當您重視了技術遠景和投資時，就會出現許多問題和選擇。你會發現：為什麼我們要為支援子域分配FTE數量是核心域的兩倍？”，也就是說，寶貴資源並沒有投入到核心子域上。
追查原因時，我們可能會發現是因為意外的複雜性：這些都是我們的舊程式碼庫，使用起來非常痛苦。如果程式碼更易於更改，並且需要的實時支援更少，那麼我們只需要一半的人員。
透過減少這種意外的複雜性，FTE將被投放在核心域上工作。
下一步是降低意外複雜性的成本並衡量預期收益。我們知道數字並不能完全準確，但是我們可以做出更明智的風險/回報決策。
我們可以想象有無窮的戰略作用。關鍵是我相信在視覺化信念和承諾以及在視覺化條件下可以協同模擬和評估策略性行為方面具有巨大優勢。
根據我的經驗，這個門檻太低了，以至於即使是這種簡單的方法，對許多公司來說也是一個很大的進步。

分析團隊之間的關係
無論我們多麼努力，軟體元件和管理它們的團隊之間總會有依賴關係。大型企業級別的計劃將導致跨多個團隊的工作計劃。
我們需要視覺化團隊之間的依存關係，並量化這將如何影響我們執行策略的能力：還是要將大部分精力投入到我們的核心領域。
我喜歡將團隊拓撲互動模式用作描述團隊之間關係型別的語言。如果您不熟悉，這裡有一個簡短的介紹：
X-as-a-service：X-as-a-Service：一個團隊提供了一些技術功能，例如API，其他團隊卻在最少的支援和協作下就可以使用它們。
協作：多個團隊緊密合作，以完成大量工作
促進：一個團隊暫時在幫助另一個團隊實現目標
在核心領域圖表上顯示這些關係會突出我們可能沒有意識到的重大問題或機會。

定義團隊邊界
強調團隊和軟體邊界之間的依賴性為更高階別的組織設計奠定了基礎。瞭解軟體中的哪些變化是確定團隊組織方式的關鍵。
不幸的是，系統的共同變更是多維的。系統的不同部分將根據待辦事項中的內容進行共同更改和不同時間。透過視覺化這些依賴關係，我們可以針對要最佳化的哪種型別的合作變更做出戰略決策-我們以最能使我們改善核心領域的方式組織團隊。
組織團隊還有另一個方面，那就是超越物理界限。這是團隊根據他們正在發展的概念的演變而定的心態。
在高度未知的空間中具有很大的不可預測結果的大賭注核心領域需要發現心態。學習速度是關鍵，這意味著流程和技術實踐會發生變化。
應該根據團隊的實際聯絡或開發的產品的心態對團隊進行分組（這就是Simon Wardley所說的“ 先驅者”，“定居者”和“城市規劃者”）。
量化或視覺化這些關係會迫使我們考慮由此產生的動態以及它們如何影響我們的戰略選擇。為了充分利用我們核心領域的機會，我們需要仔細，自覺地考慮社會技術架構的各個方面。

不斷髮展的社會技術架構技術
很長時間以來，我一直不滿意我們用於使技術戰略與業務戰略保持一致的方法，尤其是我們如何組織開發團隊。
但是在過去的幾年中，我感到勢頭正在增強。《團隊拓撲》一書產生了巨大的影響。西蒙·沃德利（Simon Wardley）將進化置於我們所做工作的最前沿。這些新方法與DDD等更為傳統的概念完美地結合在一起，後者更加強調複雜性。
具有上下文對映的戰略性領域驅動設計始終似乎是一個好主意，但是卻缺少一些東西。在團隊拓撲和Wardley Mapping的影響下，我覺得我們終於可以開始釋放他們的真正力量了。