Scrum,敏捷,專案管理,PMP,領導統御,甘特圖,排程軟體

    干擾退散,創建跨領域職能敏捷團隊,關鍵在哪裡?


    日前到某企業授課,午餐時,業主 IT副總向我表示,關於敏捷方法「一人專注於一個專案」的設計,施行起來實在是有困難。因為實務上,其轄下專案眾多,人力明顯不足,而且總是會有偶發事件,需要把敏捷團隊中的開發人員拉出來,緊急支援處理,這該如何是好?

    我曾經寫過為什麼 Scrum 敏捷方法倡導「團隊成員專注在一個專案上」這篇文章來探討關於「一人專注於一個專案」的問題。文中我說明了勞力型和創意型工作在本質上的差異,以及為什麼一個開發人員其實還是可以兼顧多個專案,但必須是勞力型的工作,而非創意型的工作。

    而關於「總會有偶發事件,需把敏捷團隊中的開發人員拉出來緊急支援」這個問題,我的建議是:打造一支獨立的救火隊!

    這麼建議的理由很簡單,讓每個開發團隊成員都需隨時神經緊繃,待命救火,同時又得兼顧正常專案的時程壓力,這樣蠟燭兩頭燒的結果,往往兩面不討好,賠了夫人又折兵。

    那麼,這個救火隊的職責應該是些什麼呢?主要有二,一是救火,二是健身。

    救火

    專案結案之後,就是營運階段的開始,形式可能是產品的持續量產出貨,也可能是線上系統的日常運作維護。不論是量產出狀況,或是系統出狀況,一般來說,組織都會有第一線的團隊去負責處理,可能是生管單位、品管單位、客服單位,或是技術支援單位。

    但是,這些單位往往只能排除較為初級的、較為表面的問題,對於較為深層根源所造成的問題,可能還是需要原始產品/系統的開發團隊來調查,才能有個水落石出。

    但問題來了,原始的產品/系統開發團隊,在專案結案之後早就鳥獸散,加入其他新產品專案,如火如荼地進行新工作了。那上述營運階段所遭遇的問題,究竟該找誰來處理呢?

    許多組織為了「節省人力」(注意,我用的是引號),會讓原始的產品/系統開發團隊兼著做這些維護型的工作,偏偏這類營運問題往往又都很緊急(因為影響營收的創造),因此就得「馬上」把正專注於新產品專案工作的團隊成員強拉出來支援處理,也因此造成了新產品專案的中斷和干擾,以及專案團隊效率的低落。

    新產品專案來說,上述的中斷和干擾是無法事先預估到的,因此對於專案時程的影響也可能就會相當地巨大。不僅如此,這還會讓專案團隊成員無法兌現原先的時程承諾,對士氣和自信都將是沉重的打擊!

    此時,如果能有一支團隊來專責上述的救火工作,就能避免這些林林總總的負面效應,讓新產品專案的人力所受的衝擊降到最低,甚至可以被完全消滅。

    也許你會說,那萬一都沒有火要救,或很少起火(想太多),那這組救火隊不就太爽了嗎?非也,非也。

    健身

    所謂救火隊,當然是有火時救火(解決問題),沒火時演習健身,以備不時之需。救火隊在農閒時,必須將心力投注於熟悉了解營運階段產品/系統的相關設計細節,甚至必須執行一些小規模、相對較不緊急的改版型專案,以改善產品/系統的營運效能,這些可能包含,產能/良率的提升、系統效能/容量的提升、使用者經驗/滿意度的改善等。

    這樣的救火隊就是所謂的 Sustaining team(維護型團隊)

    你也許會問,那麼,哪些人適合新產品專案團隊,哪些人又適合救火隊呢?

    就我過去的經驗,要能當救火隊成員,身體一定要夠強壯,也就是說,這個人對產品/系統的設計細節必需有非常深入的了解,學習速度也要夠快。另外,救火隊的成員在心態上也必須能很機動、夠靈活,這樣才能快速決策,應對各種百變的突發狀況,迅速控制火場,撲滅大火。

    你可能又有疑問了,這樣的人,應該都相對較為資深、較有經驗,不讓他們做新產品專案,豈不是太可惜了嗎?

    的確如此!因此,實務上我們會讓救火隊和新產品專案團隊的成員不定期、不定量地互相輪調,最佳的輪調時機就是在新產品專案結束之時。如此一來,想稍事喘息,打打游擊戰的人,就可以暫時轉入救火隊。想嘗試新東西,正規作戰的人,就去加入新產品專案團隊。

    這種輪調設計,洽好也在為組織默默培養跨領域專長人才、建置各專長領域的備援系統,為組織鍛鍊出強健的跨領域職能開發團隊!


    許多組織管理的問題,其實都需要深入細究每個專業環節,才能夠找對症、下對藥。很多時候,領導者以為「讓一人身兼數職可以節省人力」,可是事實卻往往恰恰相反而不自知,身為組織的領導管理者,對此不可不慎!

    圖片來源:pixabay.com

    相關文章: