[職場求生] 多工處理! 失去的遠比得到的更多

老闆: Kris啊,你手邊那三個問題現在情況如何了

Kris: 正在處理第一條問題,另外兩條問題都還沒看

老闆: 那三個問題都很急,你可不可以同時處理啊!

Kris: %#$T%GW$

工程師真的可以多工處理問題嗎?真的有好處嗎?

 

上述情境在我過去的工作經驗中經常都會遇到,以前每次遇到這種要求,心中總是翻了個大白眼 "你以為我是多工電腦喔!還同時處理勒" .不過抱怨歸抱怨,倒也沒有真的確認過如果同時處理多個問題,它的可行性以及效益到底是好是壞. 前一陣子閒來無事,我就拿自己來做了一下實驗

實驗對象: 三個還未分析過但是狀似簡單的問題
實驗方法:
1. 將一般debug流程切割為: trace code, add log, build code, test, analysis的五個步驟循環
2. 將三個問題的處理,類似於pipeline方式處理. 類似於

實驗結果:
其實從上面的pipeline stage,就可以預測出來,省下的時間就是build code+test時間. 以我實際操作的情況,在我非常非常專注的情況下(為了減少工作切換時的time cost),原本六個工作天可以處理完的三個問題,大概可以因為多工而縮短了半天的工時.

 

失去的遠比得到的更多

 

帳面上,看起來工時縮短了,但是實際上這背後隱性成本卻更是巨大
1. 任何工作的切換時,都會有切換的時間成本.例如傑拉爾德．溫伯格(Gerald M. Weinberg)所寫的 溫伯格的軟體管理學一書中,就列出他發現工做切換的時間損失數據

同時進行的專案數	各專案獲得的時間比例	工作切換的時間損失
1	100%	0%
2	40%	20%
3	20%	40%
4	10%	60%
5	5%	75%

如果要在有一定的切換時間損失前提下,工程師必須投入非常非常高的專注力,或者是工作的複雜度必須低到一個程度,才能利用多工來節省時間.

2. 被縮短的時間,往往來自於"犧牲更進一步思考". 是的,在大量的工作切換中,我們會很自然的減少思考的深入程度,往往在得到了很表面的結果就快速做出結論. 以工程師解問題來說,就是很可能解了一個問題,但是又創造了三個問題;或者是提出了一個只能解決表面問題的做法,但是類似的問題卻仍然存在.

 

你知道, 我知道, 對面坐著的獨眼龍也知道, 但是老闆卻不知道!

 

諸多管理文章都早已指出,工程師的多工有百害而無一利,那為何老闆總是會說出"問題都很急,你可不可以同時處理啊"這種話啊?

讓我用一樣的情境來說明:

原本我手上有三個問題,每個問題要花兩天解決掉,所以老闆要等到第五天才有機會知道全部問題要多久才能處理完.但是如果我三個問題先多工做完初步分析,那可能第二天下班前就可以跟老闆說"三個問題我都知道怎麼處理了",老闆就會很開心的稱讚說"你的效率真是高!" 殊不知,其實我最後還是花了六天才把解決方案正式提交

這中間對老闆最大的不同,只是得到一個"心安" (雖然老闆通常會稱這個叫"風險管理")

 

知道老闆的心理話

 

老闆問說"這些問題能不能同時處理啊?",通常指的是 "我想盡早知道每個問題的情況".所以你千萬不要傻傻的就多工處理事情到尾,你還是必須先問出: 每件事情的優先性;如果真的都很重要,那有無其他的人力資源可協助? 如果真的又急又沒人,那你就先用很短的時間對每個問題做出初步分析,多提供一些資訊讓老闆安心,順便也為後續所需的問題處理時間,爭取到合理的籌碼.

但是最終,你還是要告訴老闆跟你自己 "一次只做一件事"

(圖片來源： Ryan Ritchie , CC Licensed）