在前公司時，有一天，同事愁眉苦臉的來找我：

「學長，PM 跑來問我 A 同事的東西什麼時候會搞定，QA 來找我要新的測試版本，等下的 Planning 會議一開就是一個下午，我自己還有幾個 Bug 還沒修，當初 X 主管跟我說，當 Scrum Master 就是要處理很多團隊的雜事，跟當主管差不多，先習慣一下對我有好處。可是覺得實在好累。」

在台灣，願意聘雇專職 Scrum Master 的公司，仍屬少見。由主管兼任 Scrum Master ，變成普遍的權宜之計。但是否這樣就意謂著，主管一定會被所謂的「雜事」淹沒呢？對開發者出身的主管來說，我們太習慣，也太喜歡享受寫程式時，進入「心流」狀態的感覺，對於寫程式以外的事情，一概視為「雜事」。換了位子，一定也要換腦袋。我認為，團隊中，沒有所謂的雜事，而是存在著複雜的「訊息流」。

舉例來說，任 2 個團隊成員間的溝通行為，就會產生１道訊息流。而 5 人團隊的的訊息流，最多就會高達 20 道。以此推論，愈大的團隊，溝通的成本也就愈高。當團隊中有跨職能 (PO/PM、QA、RD、設計師) 的訊息需求時，與其自己面對這麼複雜的訊息網路，生物本能會趨使我們使用最節省能量的方式達到目的：「不如去找 Scrum Master 吧。」於是，就產生了半調子的僕人式領導（servant leadership) ，簡單來說，主管成了僕人。

此時回頭拆解同事的困境：

• PM 需要任務何時可以完成的訊息
• QA 需要知道何時拿到新版本的訊息
• Planning 會議是整個團隊在交換訊息

只要能將訊息自然地流動到它該去的地方，而不經過主管這個節點，所謂的「雜事」其實也就不存在了。人可以透過改變地貌的結構，來引導水流方向；訊息流，也是一樣的道理。所謂的結構，其實就是「系統」。

工程上，系統的定義很單純：將資訊輸入，系統經過處理、運算後，將結果輸出。一個穩定的系統，可以在最小的監督與維護下，持續的運作與產出。Scrum 團隊，其實就是一個系統，根據客戶需求（輸入），進行開發迭代，交付產品（輸出）。每個成員，就是系統的組成「要素」（Factor)。多數無法高效產出的 Scrum 團隊，一部分問題就是出在成員間的訊息交流，導至需要主管／Scrum Master 居中協調。我認為主管就是團隊的「系統架構師」，而系統的最終目標是，即使沒有 Scrum Master ，整個團隊對能有自導航、獨立運作的能力，這與 Scrum 精神提倡的「自組織」，其實也是相互呼應。

良好的團隊系統，就是主管能過上幸福日子的解藥。如此，主管才能空出手來，精進自己，突破天花板。接下來的文章，我將細節地與大家分享，設計與修正 Scrum 團隊開發系統的實務經驗，我們明天見。