『七浪費』之五:Task Switching (工作切換)。等一下, 為什麼工作切換是一種浪費?現在這個高科技時代,不管是人,還是機器,不是都強調要具備『多工 (multitasking)』的能力嗎?所以:
老闆:每個工程師手邊同時至少要有三個專案,一個快結案,一個進行中,一個剛開始。
這樣才可以把工程師超到過勞死...的邊緣。
消費者:都什麼時代了,iOS 4.x 之前的版本居然膽敢不支援多工。難道我就不能邊玩 game 邊寫 mail 嗎... XD
學生:我最強,我可以邊上課,邊睡覺,邊聊天,邊玩手機,再加上邊吃泡麵邊啃雞腿。
學過作業系統的人都知道,工作切換便會形成『context switch』,只要有 context switch 就形成浪費。對電腦而言,context switch 可以是很 routine 的工作,對人腦就不同了 。如果手邊的工作類型是屬於『不需要大腦也可以搞定的工作』,例如挑大便或是拔草,那麼工作切換所造成的浪費就比較少。但是,對軟體開發而言,大部分的工作卻都是需要『絞盡腦汁』的工作(路人甲:真的嗎?!)。如果時常切換不同的工作,有可能最後花在 context switch 時間比真正去做事的時間還來的多。引用一段書中的話:
When knowledge workers have three or four tasks to do, they will often spend more time resetting their minds as they switch to each new task than they spend actually working on it.
***
問題來了,實務上,你的老闆絕對沒那麼好心,讓你只做一件工作。所以,工作切換畢竟是難免的。書中舉一個例子說明如果減少工作切換的浪費。假設你的軟體已經釋出,因此你同時必須要面對『維護舊軟體』與『開發新軟體』這兩件工作。以下是書中提到減少工作切換浪費的方法:
- 讓兩個人(或兩個小組)每個月(或每個 iteration)輪流負責開發與維護的工作。
- 每天早上花兩個小時讓整個團隊處理維護的工作,其餘時間專注於新功能開發。
- 仿效『急診室』的作法,先將每一個客戶所提出的維護需求加以分類,只立即處理『緊急』的維護需求(理論上只有很少量的維護需求是屬於這一類的),然後每一週或兩週在看看有哪些維護需求是真正需要處理的(有時候客戶的維護需求放久了會自動消失...^o^)。
- 把所有不同客戶所使用的軟體版本都放在單一的 code base,然後每週或每一個 iteration(定期)釋出一個更新版本。
***
結論:在實際的生活中,task switching 是難免的。但是請牢記以下兩點:
- 不是塞越多的工作給員工就可以得到越多的產出,有時候塞了太多的工作,員工只是在不同的工作間『空轉』而已,最後一事無成。
- 就算是需要 task switching,也有比較好的工作切換模式。例如,不要每隔 5 分鐘檢查一次 mail,那只會害你分心。最好是採用『定時定量』的方法,例如每天早上一到公司的時間,下午 1:30 以及下班前。
***
友藏內心獨白:為什麼總是在忙碌的時候,不斷收到 MSN/Skype 的訊息。
沒有留言:
張貼留言