跨團隊溝通：避免依賴 - pd

banq發表於2021-12-07

改善交付時間應該是每個組織的目標。阻礙交付流程加速的一個主要減速器是組織中的不同團隊傳統上一直在孤島中工作。為了解決這個問題，在大多數情況下會出現一個簡單的解決方案：增加不同團隊之間的溝通。
但是，這個解決方案就足夠了嗎？當公司成長時，“增量溝通解決方案”如何擴充套件？我們將在本文中解釋其中的一些內容，但作為劇透：適當的團隊互動是一個複雜的問題，而複雜的問題很少有簡單的解決方案。
 

跨團隊溝通如何擴充套件
《團隊拓撲》一書解決了這個溝通問題，定義了四種基本的團隊拓撲和三種團隊互動模式：
團隊拓撲如下：

  • 流對齊的團隊：與來自（通常）業務領域的一部分的工作流對齊。
  • 賦能團隊：幫助與流對齊的團隊克服障礙。還檢測缺失的功能。
  • 複雜的子系統團隊：需要大量數學/計算/技術專長的地方。
  • 平臺團隊：一組其他團隊型別，提供引人注目的內部產品以加速流對齊團隊的交付。

關於互動，他們介紹了以下三種互動模式：
  • 協作：團隊在規定的時間內一起工作以發現某些東西。
  • X-as-a-Service：一個團隊提供，一個團隊“作為服務”消費。
  • 促進：一個團隊幫助和指導另一個團隊。

根據團隊拓撲，他們建議嘗試互動模式或其他模式。
當您想應用這些概念時，如果不瞭解具體的團隊背景，就沒有正確或錯誤的答案。但是檢查您當前的團隊互動並對其進行評估是一個很好的起點。一些例子：
  • 在我目前的公司Audiense 中，流對齊團隊每次想要建立一些基礎架構元件（例如新佇列、事件主題等）時都需要與系統團隊進行“協作互動”。流對齊團隊沒有在他們的開發過程中沒有這個基礎設施建立部分，所以協作總是在功能開發的最後，導致一些塊。幾個月前，平臺團隊建立了一項服務，不同的流對齊團隊能夠在其中建立編寫一些程式碼的基礎架構元件，並且這些元件是在 CI 過程中自動建立的。這種互動現在是X-as-a-Service，並且我們已經刪除了該依賴項。我們現在有其他部分正在做同樣的事情，但這種依賴導致了許多塊。
    對於類似的情況：在您負擔得起 X-as-a-Service 的部分，長期採用協作互動模式是否有意義？
  • 如果你通常需要等待一些人做出一些決定：這樣做有意義嗎？您能否透過在特定時間使用促進互動模式來消除這種依賴性？

這些是你應該問自己的問題型別。
與往常一樣，將問題作為一個持續的過程來處理，採取小步驟來改善您當前的情況：
  • 評估您當前的團隊依賴關係及其互動模式。
  • 首先處理阻塞依賴項，這樣功能就不會閒置了，這些依賴項是您當前的瓶頸。
  • 更新該互動模式並刪除該依賴項。
  • 找到下一個瓶頸。
  • 重新開始。

相關文章