約定好「問問題時間」，幫團隊減少 context switch

「欸，問你一下。」

寫程式的人聽到這句話，心裡多半會抖一下。

問題本身通常不難，五分鐘就能回答完。麻煩的是被叫住的那一刻，腦袋裡正疊著一整座還沒寫完的東西：這個變數從哪裡來、那支 API 為什麼回傳 null、下一步本來打算改哪裡。回答完轉回螢幕，那座東西已經垮了，得從頭再疊一次。

這就是工程師常說的 context switch：切出去很快，切回來很貴。

我寫了二十年程式，這句話聽過無數次。後來當了主管，換我站到另一邊。

所以在李開復的臉書上讀到他分享的一個微軟主管的故事，我看得特別有感。

天天被問問題的新人工程師

故事的主角是潘正磊（Julia Liuson）。她大學一畢業就進了微軟，從工程師做起，一路做到微軟開發者事業部的總裁，今年才退休。李開復說她是微軟晉升最快的經理之一，而這個故事，是她剛進微軟時學會「保護時間」的經過。

那時她是軟體工程師，所在小組的產品長得很快，幾個月內就出了三個版本，每個版本又要支援六種語言。十八種組合，需求都有一點不一樣，還得跟很多其他小組打交道。

於是她的辦公室每天人來人往，每個人都帶著不同的問題進來。只要有人來，她就停下手邊的事，先幫對方解決。

結果是每天忙得不可開交，做得卻很不開心。工時很長，卻覺得自己沒學到東西，也沒有進步。

後來她跟老闆談了這件事，意識到自己的時間才是最寶貴的。在老闆的指導和支持下，她設了一段「回答問題時間」：其他人只有這個時段能來找她，其餘時間她專心寫程式。這樣她才有了整塊的時間，可以照計畫做完想做、也該做的事。

同時還定了一個目標：讓其他小組學會自力更生，不要事事都跑來問。花了一段時間「授人以漁」之後，她才真的騰出時間，去學新的技術和管理經驗。

李開復在文末補了一句：要不是有這段經驗，她大概還待在同一間辦公室，每天回答各種問題，直到精疲力盡。

她叫它「回答問題時間」，換成來問問題的人的角度，就是「問問題時間」。原文沒寫這段時間是幾點到幾點，重點也不在那裡。

我最有感的，是那位老闆

李開復把這個故事放在講時間管理的文章裡，重點是「保護時間」。

但我讀完一直想到的，是故事裡一個很容易被略過的角色：她的老闆。

一個剛進公司的新人，要自己跟大家說「請你們只在這個時段來找我」，老實說很難開口。來問問題的人裡，可能有資深同事，也可能有別組的主管。沒有老闆撐腰，這種規矩很難立起來，就算立了，大概也撐不了幾天。

她做得到，是因為老闆站在她那邊。

Context switch 的代價，比想像中大

「只要五分鐘。」問的人通常真心這麼覺得，但被打斷的人付出的，從來不只五分鐘。

Context switch 這個詞本來是作業系統的術語：CPU 從一個程式切到另一個，要先把手上的狀態存起來，再把另一個程式的狀態載進來。切換的那段時間，兩邊的正事都沒在做。

人腦也一樣，只是慢得多。開頭講的那座東西，每被叫住一次就要重疊一次。一個下午被叫住兩三次，傍晚回頭看，常常覺得什麼都沒做完。

我後來好奇去查了一下，有個研究在 27 位微軟員工的電腦上記錄了兩週，結果跟我的體感差不多：被 email 或訊息的通知岔開之後，平均要將近 10 分鐘才處理完岔出去的事，處理完之後，還要再 10 到 15 分鐘，才重新專注回原本的工作。有 27% 被中斷的工作，隔了兩個小時以上才接回來。

偏偏打斷的頻率高得嚇人。微軟去年分析 Microsoft 365 的使用數據，發現大家在核心工作時段平均每 2 分鐘就被會議、email 或聊天訊息打斷一次，一天 275 次。

兩個數字放在一起，就不難理解為什麼很多人一整天都很忙，下班卻想不起來自己做了什麼。這跟潘正磊當年的感覺一模一樣。

主管為什麼常常沒感覺

這件事，我是兩邊都待過才看懂的。

當工程師的時候，下午中間卡一場會，整個下午就差不多廢了：會前那段不敢開始難的東西，會後那段又短到做不了什麼。

當了主管以後，行事曆本來就切成一小時一小時的格子，多一場會只是多佔一格，不痛不癢。

所以主管打斷人的時候，通常不覺得自己造成了什麼損失。這跟體不體貼無關，是兩種工作算成本的方式不一樣：主管的時間是一格一格的，寫程式的人要的是整塊的時間。

主管的工作本來就是一直在切換，切久了不覺得痛。寫程式的人每切一次，都要重新載入一次。

我以前一直把專注當成自己的事

回頭看我寫過的東西，講專注的那幾篇，全都在講怎麼管好自己：起床先不帶手機、用番茄鐘、每天排兩段九十分鐘的深度工作，剩下的時間才回訊息、開會。番茄鐘寫在〈遠距工作第一年〉，兩段深度工作寫在〈怎麼在遠距工作裡保持高效〉。

說穿了，這些做法都是同一招：把 context switch 集中起來，不讓它散落在一整天。潘正磊的「回答問題時間」也是這一招，只是用在別人來問的問題上。

這些方法都有用，但有一個前提：你能決定自己的時間。

遠距工作、一個人扛後端的時候，這個前提大致成立。在團隊裡就不一定了。你把 Slack 關掉，別人還是會直接打給你；你想說「我現在在專心」，如果對方是主管，這句話其實很難說出口。

潘正磊的故事讓我想通的是：個人能管的是自己的注意力，團隊的專注要靠主管來守。

如果要在團隊裡試，我會這樣做

一天兩個時段，時間要固定

如果是整個團隊一起用，我會開兩段：上午一段、下午一段，各三十分鐘左右。只開一段的話，早上卡住的人要等到下午，等太久，大家還是會直接來敲門。

時間要固定。大家知道幾點一定找得到人，才敢放心把問題先存起來。今天有、明天又因為開會取消，很快就會回到隨時敲門的老樣子。

大學裡其實早就這樣做了，叫 office hours：教授每週固定幾個小時待在辦公室，等學生來問問題。

問題先寫下來

平常卡住，先把問題寫進一個大家都看得到的地方，Slack 的 thread 或共用文件都可以。寫的時候附上三件事：想做什麼、試過什麼、卡在哪裡。

好處有三個。到了問問題時間，不用再花時間重建脈絡；很多問題寫到一半，自己就想通了；答案留在那裡，下一個卡在同一個地方的人，直接給他連結就好。

講清楚什麼事可以直接打斷

問問題時間最怕被誤會成「其他時間都不准問」。線上出事、客戶受影響、卡住會擋到別人的，都不用等，直接來。其他的，照這個流程走：

flowchart TD
    Q["想問同事一個問題"] --> URGENT{"等到下一個時段<br/>會有人付出代價嗎？"}
    URGENT -->|"會"| NOW["直接找人<br/>先講為什麼急"]
    URGENT -->|"不會"| TRY["自己先查 15 分鐘<br/>把卡點寫下來"]
    TRY --> SOLVED{"寫完就想通了？"}
    SOLVED -->|"想通了"| SHARE["繼續做事<br/>答案留給下一個人"]
    SOLVED -->|"還是卡住"| SLOT["留到問問題時間<br/>一次問清楚"]

判斷的核心只有一句：這件事等到下一個時段，會不會有人付出代價？會，就直接來找我；不會，就先寫下來。

圖裡的「15 分鐘」是我自己的經驗值，不是研究結論，每個團隊可以自己調。

新人要有例外

新人、或剛接手陌生模組的人，不適用這套。對他們來說，卡住一個下午的代價，遠大於打斷我五分鐘。

我在〈20 年寫程式的 10 個體悟〉寫過，帶人最難的是抵抗「自己做比較快」的衝動：你花一小時教同事做一件事，他這次可能要三個小時才做完，但下次同樣的事，一個小時就能搞定。潘正磊故事裡的「授人以漁」，講的也是這件事。問問題時間的目的是讓問問題更有效率，要是新人因此不敢問，就本末倒置了。新人的前幾週，我寧願被多打斷幾次。

主管自己要先守

這條最難。團隊裡最常打斷人的，往往就是主管自己：「那個東西好了嗎？」「等一下來我這邊一下。」主管嘴巴說要保護專注，自己卻隨時敲人，大家很快就會知道哪個才是真的規則。

這種規矩最常見的結局是虎頭蛇尾。我讀過一個很經典的實驗：一家大公司的軟體團隊試過「安靜時間」，一週三天，中午以前大家不互相打擾。那幾週，覺得自己生產力高於平均的工程師有六成左右，換成別種排法時只剩四成。產品後來準時上市，是那個部門史上第二次，事業部副總裁直接把功勞歸給這個實驗。

可是實驗結束後，慢慢就沒人守了，後來想再推一次也推不動。研究者的看法是問題出在誘因：公司獎勵的還是隨時救火、看起來最忙的人。只改時段、不改誘因，規矩很快就會回到原樣。

所以我會把自己想問的事也存起來，留到同一個時段，或是每週的一對一。真的急才直接找人，而且先講清楚為什麼急。

最後

潘正磊能把時間拿回來，靠的是自己開口、老闆撐腰，還有花時間教會別人自己解決問題。

一個工程師要守住自己的專注，需要很多自律；一個團隊要守住專注，需要有人站出來說：「這段時間，大家都不要打擾彼此。」這個人通常只能是主管。

如果你也帶團隊，下週可以先試一件小事：挑兩個固定時段，跟大家說這兩段你一定在，其他時間除非真的急，先寫下來。

然後自己先守住。