日前到某企業授課，午餐時，業主 IT副總向我表示，關於敏捷方法「一人專注於一個專案」的設計，施行起來實在是有困難。因為實務上，其轄下專案眾多，人力明顯不足，而且總是會有偶發事件，需要把敏捷團隊中的開發人員拉出來，緊急支援處理，這該如何是好？
我曾經寫過為什麼 Scrum 敏捷方法倡導「團隊成員專注在一個專案上」這篇文章來探討關於「一人專注於一個專案」的問題。文中我說明了勞力型和創意型工作在本質上的差異，以及為什麼一個開發人員其實還是可以兼顧多個專案，但必須是勞力型的工作，而非創意型的工作。
而關於｢總會有偶發事件，需把敏捷團隊中的開發人員拉出來緊急支援」這個問題，我的建議是：打造一支獨立的救火隊！
這麼建議的理由很簡單，讓每個開發團隊成員都需隨時神經緊繃，待命救火，同時又得兼顧正常專案的時程壓力，這樣蠟燭兩頭燒的結果，往往兩面不討好，賠了夫人又折兵。
那麼，這個救火隊的職責應該是些什麼呢？主要有二，一是救火，二是健身。
救火
專案結案之後，就是營運階段的開始，形式可能是產品的持續量產出貨，也可能是線上系統的日常運作維護。不論是量產出狀況，或是系統出狀況，一般來說，組織都會有第一線的團隊去負責處理，可能是生管單位、品管單位、客服單位，或是技術支援單位。
但是，這些單位往往只能排除較為初級的、較為表面的問題，對於較為深層根源所造成的問題，可能還是需要原始產品／系統的開發團隊來調查，才能有個水落石出。
但問題來了，原始的產品／系統開發團隊，在專案結案之後早就鳥獸散，加入其他新產品專案，如火如荼地進行新工作了。那上述營運階段所遭遇的問題，究竟該找誰來處理呢？
許多組織為了｢節省人力」（注意，我用的是引號），會讓原始的產品／系統開發團隊兼著做這些維護型的工作，偏偏這類營運問題往往又都很緊急（因為影響營收的創造），因此就得｢馬上」把正專注於新產品專案工作的團隊成員強拉出來支援處理，也因此造成了新產品專案的中斷和干擾，以及專案團隊效率的低落。
對新產品專案來說，上述的中斷和干擾是無法事先預估到的，因此對於專案時程的影響也可能就會相當地巨大。不僅如此，這還會讓專案團隊成員無法兌現原先的時程承諾，對士氣和自信都將是沉重的打擊！
此時，如果能有一支團隊來專責上述的救火工作，就能避免這些林林總總的負面效應，讓新產品專案的人力所受的衝擊降到最低，甚至可以被完全消滅。
也許你會說，那萬一都沒有火要救，或很少起火（想太多…），那這組救火隊不就太爽了嗎？非也，非也。
健身
所謂救火隊，當然是有火時救火（解決問題），沒火時演習健身，以備不時之需。救火隊在農閒時，必須將心力投注於熟悉了解營運階段產品／系統的相關設計細節，甚至必須執行一些小規模、相對較不緊急的改版型專案，以改善產品／系統的營運效能，這些可能包含，產能／良率的提升、系統效能／容量的提升、使用者經驗／滿意度的改善等。
這樣的救火隊就是所謂的 Sustaining team（維護型團隊）。
你也許會問，那麼，哪些人適合新產品專案團隊，哪些人又適合救火隊呢？
就我過去的經驗，要能當救火隊成員，身體一定要夠強壯，也就是說，這個人對產品／系統的設計細節必需有非常深入的了解，學習速度也要夠快。另外，救火隊的成員在心態上也必須能很機動、夠靈活，這樣才能快速決策，應對各種百變的突發狀況，迅速控制火場，撲滅大火。
你可能又有疑問了，這樣的人，應該都相對較為資深、較有經驗，不讓他們做新產品專案，豈不是太可惜了嗎？
的確如此！因此，實務上我們會讓救火隊和新產品專案團隊的成員不定期、不定量地互相輪調，最佳的輪調時機就是在新產品專案結束之時。如此一來，想稍事喘息，打打游擊戰的人，就可以暫時轉入救火隊。想嘗試新東西，正規作戰的人，就去加入新產品專案團隊。
這種輪調設計，洽好也在為組織默默培養跨領域專長人才、建置各專長領域的備援系統，為組織鍛鍊出強健的跨領域職能開發團隊！
許多組織管理的問題，其實都需要深入細究每個專業環節，才能夠找對症、下對藥。很多時候，領導者以為｢讓一人身兼數職可以節省人力」，可是事實卻往往恰恰相反而不自知，身為組織的領導管理者，對此不可不慎！
圖片來源：pixabay.com
相關文章：