iT邦幫忙

2021 iThome 鐵人賽

DAY 5
1
IT管理

初階主管求生指南系列 第 5

[Day05] 團隊無雜事,只有混亂的訊息流

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

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

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

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

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

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

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

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

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


上一篇
[Day04] 空降主管的戰地生存術
下一篇
[Day06] 團隊系統設計 - 張力分析
系列文
初階主管求生指南30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言