你早就知道站會出了問題，難的是怎麼說出口

你的團隊裡早就有人把那則訊息打好了，內容大概是「我覺得每日站會對我們沒什麼幫助」。打完看了一遍，想著對方會怎麼讀，最後還是刪掉，照樣加入了會議。

這篇文章真正要談的，就是那個「刪掉」的動作。關於站會（daily standup）的研究並不難找，而且大多指向同一個方向。難的是那句話。你想說的這件事，同時帶著三種各自獨立的社交風險，而且全都落在你個人身上。

風險一：聽起來像在偷懶。任何想取消會議的要求，預設讀起來都像是想少被盯著。

風險二：聽起來不像團隊的一分子。大家都把站會當成讓所有人方向一致的做法，反對它，聽起來就像在反對方向一致。

風險三：你攻擊的是一個人，而不是一套流程。那場會議是有人負責的，可能是 Scrum Master、主管，或是兩年前發起這場會議的人。他們會把你對這套儀式的批評，聽成對自己判斷力的批評，而在多數團隊裡，這樣聽也沒聽錯。

在繼續之前，我得先說明一件事：我是 Subtext 的共同創辦人，這款 App 就是為這類訊息而做的，也就是用詞的風險比論點更大的那種。我在這件事上有明顯的利害關係：我希望你同意難的是那句話。所以請斟酌看待，下面的每一項研究，也請自己查證。接近文末，有一次 Subtext 的真實執行，讀的是一份照說話方式打出來的進度更新，寫的人卡在一位從週一之後就沒回覆的同事身上。

於是大家什麼都沒說，這場會議就靠著沒人找到那句話，繼續開下去。

好消息是，那些話是存在的，而且不複雜。你只需要照特定的順序把它們組合起來，而這個順序，比證據還重要。

---

換個框架，就能贏得這場爭論

不要主張站會是浪費時間。這種主張每一次都會輸，原因就是上面那三種風險。

改成這樣主張：你們團隊現在開的，不是這場會議本來該有的樣子；然後提出一個隨時可以退回原狀的實驗來修正。

《Scrum 指南》（Scrum Guide）在這件事上站在你這邊，只是多數人從來沒去查過。2020 年版指南¹把每日 Scrum 定義為一場 15 分鐘的活動，為 Scrum 團隊的開發人員（Developers）而辦，用來檢視朝 Sprint 目標前進的進度，並調整計畫。指南沒有把它定義成向主管報告。2020 年版還拿掉了規定好的那三個問題，而多數團隊至今仍每天早上照著念¹。

如果你們的站會是大家圍成一圈，向會議室裡職位最高的人報告昨天和今天做了什麼，那麼保留它並不是在捍衛 Scrum，因為指南已經把這種形式拿掉了。這句話你可以大方說出口，不必指責任何人。

你要的不是讓大家少交代一點進度，而是照框架的描述來開這場會，再測試一個成本更低的形式站不站得住腳。

把這個思路用在文章開頭那則訊息上，也就是大家通常寧可刪掉、也不送出的那一則。

草稿 「我覺得每日站會對我們沒什麼幫助」

讀起來像抱怨，不像提案 · 開頭那三種風險全都帶上了 · 沒有給對方任何可以點頭的東西

改寫後 「我覺得我們現在的站會，已經不太像 Scrum 指南描述的那樣在運作了，想試一個成本更低的形式，看看撐不撐得住。如果不行，我們就直接改回來」

---

第 1 部分：經得起檢驗的理由

這個主題上流傳的數字，我刪掉了很多。刪了哪些、為什麼，我在文末的說明裡交代。下面這些，是我會拿到一位持懷疑態度的主管面前的內容。

1. 它變成了向上報告的進度會議，而框架說它不該是這樣 這是記錄最完整的失效模式。Stray、Sjøberg 和 Dingsøyr 針對每日站會做的紮根理論研究（grounded theory study）發現，參與者看重站會，是因為它能分享資訊、一起解決問題；一旦會議變成向主管報告進度，或是開得太頻繁、太久，他們的反應就轉為負面²。同一個研究團隊寫給實務工作者的文獻裡，也看得到同樣的發現⁴。

2. 那三個問題只會讓大家各自念稿，沒有協調 「昨天我做了那張工單，今天我會繼續做那張工單。」沒有人追問，也不會因此有任何改變。這種形式鼓勵的是表演自己很忙，而不是檢視朝目標前進的進度，這也是 2020 年版指南拿掉那三個問題的原因¹。

3. 資深工程師和大型團隊得到的最少 Stray 等人調查了專業開發人員，發現整體評分集中在中性附近，資淺的開發人員比較正面，資深的開發人員和較大團隊的成員，則比較可能覺得價值不高³。如果你們經驗最豐富的人，在會議上投入最少，這是在告訴你形式有問題，不是他們有問題。

4. 它把整個早上切成兩半 Paul Graham 在 2009 年提出的論點¹³至今仍然成立。需要動手做出東西的人，需要一大段不被打斷的時間；早上正中間的一場會議，就能把整個早上切成兩小塊，每一塊都短到沒辦法做需要專注的事，整個早上就這樣毀了。10:30 的站會就是最典型的例子。另外還有一種預期成本：會議開始前的 45 分鐘，人們會避免開始任何需要深入投入的工作。

5. 切換工作，會拖累會議前後兩邊的工作 Sophie Leroy 的研究提出了注意力殘留（attention residue）：從一項工作換到另一項時，有一部分注意力會留在第一項工作上，第二項工作的表現因此變差⁵。站會會逼每位出席者切換兩次，一次進去，一次出來。

6. 重新回到工作狀態，真的要花時間 那個廣為流傳、說被打斷後大約要 23 分鐘才能回到原本工作的數字，出自 Gloria Mark 對工作中斷所做的研究。她與 Gudith 和 Klocke 合作的研究還發現，人們會靠加快工作速度來彌補被打斷的損失，代價是壓力、煩躁和自覺的工作負荷都變高⁶。引用這個數字要小心。它是生產力討論裡被濫用得最嚴重的數字，看過這個數字被人拆穿的主管，會拿這一點來反駁你。

7. 阻礙（blocker）被點名了，卻沒有被解決 在你自己的團隊裡留意這一點。有人說自己卡住了，大家點點頭，真正的解決辦法卻是在四十分鐘後，兩個人的私訊裡談出來的。如果模式是這樣，那場會議並沒有解決那個阻礙，它只是把真正解決問題的那場對話約了出來。

8. 開會的負荷會在生理上累積 Microsoft 的 Human Factors Lab 對連續開會的參與者做了腦波（EEG）測量，發現壓力指標會隨著會議一場接一場而攀升，而短暫的休息可以減少這種累積⁸。Steven Rogelberg 的會議科學研究，則是從問卷調查的角度記錄了同樣的現象，也記錄了糟糕的會議之後，人們得花多久平復心情，而這段恢復時間要再加在會議本身的長度之上⁷。

9. 它不適合分散在各地的團隊 總有人得在很不方便的時段參加。想了解改以非同步方式處理進度的主張，GitLab 的全遠端工作手冊¹⁴是目前公開資料裡最完整的一份論述。它之所以是很有用的參考，正是因為它出自一家以這種方式大規模運作的公司，而不是出自某個部落格。

10. 每天開一次，就是每天付一次代價，不管有沒有事情需要協調 在工作關聯不緊密的團隊裡，真正需要協調的時候是斷斷續續的。固定開會的做法，在每一個沒事的日子都多付了錢。

---

第 2 部分：反面的證據，應該由你自己先提出來

進場之前，先把反對你的論點自己講完。這是最快讓人認真看待你的辦法，也不會讓你的主管覺得得獨自替這場會議辯護。

站會只要開得好，有三件事是很難取代的。

站會能讓阻礙及早浮現。一個在 09:30 就被提出來的問題，若是拖著不說，可能會耗掉一整天，光這一點就值回這十五分鐘。這是你的替代方案必須補上的功能。

站會能讓大家對「誰在做什麼」有共同的認識，減少重複和互相衝突的工作。Stray 和 Dingsøyr 把這一點記錄為人們提到的好處之一²。

站會有助於心理安全感（psychological safety）。Rietze 和 Zacher 發現，每日站會與心理安全感之間有正向關係，而心理安全感又與工作滿意度和對團隊績效的感受有關¹⁰。除此之外，還有 Edmondson 的奠基性研究，把心理安全感與團隊的學習行為連結起來⁹。一個固定出現、壓力很低的接觸點，對信任多少有些幫助，尤其在新成立或分散各地的團隊裡。

所以，這幾點屬實的地方，就大方承認。如果你的團隊人數少、成員之間關聯緊密、經驗資淺，或是才成立三週，那站會大概已經值回它的成本，你應該直接這麼說。

---

第 3 部分：開口之前，先拿到你自己的資料

兩週，三件事。在談話之前先做完，因為拿意見去跟儀式對抗只會輸，拿算術去跟儀式對抗就不會。

量實際的時長，不是排定的時長。每天計時。多數團隊會發現，那場 15 分鐘的會議，實際上是 22 分鐘。

算一算薪資成本。出席人數，乘以實際時長（以小時計），再乘以一年的工作天數。八個人的團隊，如果剛好開 15 分鐘，每天是 2 個工時，每週約 10 個，一年大約 460 個工時。以每小時 60 歐元的人力總成本計算，大約是 27,000 歐元，而這個數字還沒把會議前後的恢復成本算進去。用你自己團隊的數字，這樣就沒有人能質疑你代入的條件。

數一數阻礙。連續十個工作天，把站會上提出的每一個阻礙都記下來，並標註它是在會議中解決的，還是事後在別的地方解決的。這通常就是能結束爭論的那個數字。

匿名問問團隊。只問一個問題：站會有沒有幫助你把工作做好？回答有或沒有，並說明原因。匿名才問得到真話；而且這樣一來，你代表的是團隊，不是自己，開頭那份清單裡的風險二也就消掉了。

---

第 4 部分：具體的說法

四種情境，四份說法。細節可以依你的情況調整，結構要保留，因為真正發揮作用的是結構。讓工作訊息讀起來堅定而不冷淡的，也是這套結構。

每一份都照同樣的四個步驟走。先肯定對方的需求。用對方在意的角度說出成本。提出可以退回原狀、有時間限制的做法。把舉證的責任和設定的工作都攬在自己身上。你會發現，這四個步驟沒有一個是在爭誰對。

對你的主管，一對一的時候

「我想保護團隊的專注時間，又不讓你失去對大家進度的掌握。我手上有兩週的資料，記錄我們的站會實際上是怎麼被使用的。它開 22 分鐘，不是 15 分鐘。我們八個人加起來，一年大約是 675 個工時。這十天裡，站會上提出了六個阻礙，真正在會議中解決的只有一個，其餘都是事後在私訊裡解決的。

我想試跑四週。大家在 09:30 以前，把文字更新貼在共用頻道，你想什麼時候看都可以；另外開一個專門的阻礙頻道，有人卡住時，當下就直接標記你；再加上每週一次的即時同步會議。我會拿阻礙的解決時間，跟我們現在的情況做比較。如果變差了，我們就改回去，我也會在回顧會議上講明。這一切由我來設定。」

對你的 Scrum Master

「我最近又重看了一遍 2020 年版指南。它把每日 Scrum 定義為開發人員的活動，而且拿掉了那三個問題。我們的站會慢慢變成輪流更新，而且是講給會議室裡職位最高的人聽，這正是指南特別想避免的事。

我們能不能試一個 Sprint，改成對著看板開，不要再一個接一個輪流報告，結束後再問問開發人員，這樣對他們來說有沒有變得更有用？」

注意這段話做了什麼。它把框架當成權威交給對方，你自己就不必扮演那個角色；它也讓對方成為把做法恢復原貌的人，而不是替一個壞掉的版本辯護的人。

對你的同事，在做任何事之前

「老實跟我說。站會對你真的有幫助嗎？還是只是例行公事，撐過去就好？我想把這件事提出來，不過我只想在能代表大家、而不只是代表我自己的時候才提」

先做這一步。每次都是。如果有兩個人說，站會是他們唯一能開口求助的時機，你的提案就得保留這一點，而你在公開表態之前，就已經知道了。

在回顧會議上

「今天我想檢視一件事。我追蹤了我們的站會兩週。這是它的成本，這是它實際解決了多少阻礙。我不是要大家取消它。我想問的是，能不能先把形式改一個 Sprint，看過數字以後，再決定要不要做出長久的改變。」

寫成書面提案

主旨：為期四週的非同步站會實驗

目前我們的每日站會有八個人參加，每次 22 分鐘，一年大約是 675 個工時。過去十個工作天裡，站會上提出了六個阻礙，在會議中解決的有一個。

提案，為期四週，完全可以退回原狀：

每天 09:30 以前，大家在 #team-standup 貼出文字進度，每人三行：朝 Sprint 目標的進展、今天的重點、有沒有卡住的事。

阻礙一出現，就直接標記相關的人，不要留到隔天早上。

每週一開一場 30 分鐘的即時同步會議，用來做規劃，以及處理所有需要談一談的事。

我會追蹤阻礙解決時間、週期時間，以及一份簡短的團隊脈動調查，並在 [日期] 的回顧會議上把三項結果都帶來。如果阻礙解決時間變差，我們就改回去。工具由我來設定，試行也由我來帶。

那則訊息裡最重要的一句，就是明確寫出的還原條件。正是它把你的提案從「改變」變成「測試」，通常也是它換來那聲「好」。

---

第 5 部分：對方會怎麼回

「我需要掌握每個人在做什麼」 文字更新能給你的，比開會還多。可以搜尋，會留下紀錄，你可以在 07:00 或 19:00 讀，不必一定要在 09:30 坐在會議室裡。

「阻礙會一直擱在那裡」 剛好相反。阻礙一出現就貼出來，會比留到隔天早上更快被注意到。這正是我提議要追蹤的那項指標，也是會讓我喊停這次試行的那一項。

「不過就是十五分鐘而已」 這是十五分鐘乘以八個人，每個工作天都要開，再加上每個人回到原本工作所需要的時間。全年的數字，第 3 部分算過了。

「Scrum 規定要有每日 Scrum」 Scrum 規定的是給開發人員的每日 Scrum，而 2020 年版指南已經拿掉了我們還在用的那三個問題。我們現在開的，並不是指南描述的那種東西¹。

「團隊會失去凝聚力」 這是個真實的風險，所以每週的同步會議會保留。試行期間我也會追蹤團隊脈動，所以如果凝聚力下降，我們看得到，不必靠猜。

---

第 6 部分：大家輸掉這場爭論的五種方式

把提案說成是想少做一點。這會證實對方一進門就抱持的懷疑。你原本想提的是一個實驗，而草稿實際傳達的卻是一句抱怨，這兩者之間的落差，正是 Subtext 會在你傳送之前抓出來的。

沒有說出替代方案，就把會議砍掉。接下來出現的混亂，大家會算在你頭上，而且這樣算也沒錯。

一個人說了算。團隊的儀式，要靠團隊一起決定才改得動，否則一個月內就會捲土重來。

跳過試行和指標，這會把一個可以驗證的提案，變成對抗現狀的意見比賽，而這種比賽，贏的都是現狀。

忽略站會對哪些人有用。如果團隊裡的資淺成員要靠它，就圍繞著他們來設計，也在會議上講明。這不花你任何代價，還能在有人提出之前，先化解最強的那個反對意見。

---

第 7 部分：用什麼取代它

一共七個選項，每一個我都附上了它的缺點。

用機器人收集的非同步文字簽到。Geekbot、Standuply 或 Range 會提醒每個人，並把內容貼到共用頻道¹⁷。可以跨時區，也會留下可搜尋的紀錄。如果沒有人回應大家貼的內容，可能會淪為沒人看的進度作秀。

一週兩次的站會。保留即時同步，把頻率降低。因為改動小，所以很容易說服別人。需要另外搭配一個頻道，處理緊急的事。

用看板逐項走過，取代圍成一圈輪流報告。由右往左一項一項過工作項目，談的是工單，不是人。那種每個人輪流報告的互動模式，立刻就消失了。前提是團隊要讓看板內容隨時保持最新。

專門的阻礙頻道。價值最高的一塊，也是最便宜就能加上的一塊。需要大家自律地貼，也需要有人盯著。

有需要才找人結對。解決得最快，也沒有旁人看著。全團隊對進度的掌握會降低，所以要留下文字紀錄。

每週一次深入的同步會議。有空間容納 15 分鐘會議裝不下的對話。頻率太低，無法單獨撐起來。

無會議日。Shopify 在 2023 年的行事曆大清理，是最常被引用的企業案例；Bloomberg、Fortune 等媒體報導，那次行動從公司行事曆上清掉了數千場定期會議¹⁵。這是一項專注政策，不是協調機制，所以必須搭配上面的其中一種。

最常奏效的組合是：用文字更新掌握每天的狀況，用阻礙頻道處理緊急的事，其餘的交給每週一次的即時同步會議。

如果大家抗拒的是把更新打成文字，那也可以用說的。Subtext 接受語音輸入，也接受你照說話的方式打出來的文字。下面這份更新，是我為了拿給 Subtext 跑一次而編的，就是照說話的方式打的：「好，那個，昨天我把匯出的 bug 修好了，嗯，大部分啦，csv 那部分碰到大檔案還是會失敗，今天我在弄帳單頁面，然後老實說我有點卡住，因為我需要 Dana 那邊的 API key，可是她從禮拜一就沒回我，所以對，這就是我要發到團隊頻道的進度更新」。

Subtext 回傳的標籤只有一個，「責怪」，沒有附上理由；它把底下的感受命名為「焦慮」，理由是「你有點卡住，又等不到 Dana 的回覆，語氣裡帶著擔心」。它先回了一句「卡在等人回覆真的很悶，不過進度你都有交代清楚。我幫你整理成頻道裡好讀的版本。」，接著給了三個版本，三個都標為「可放心傳送」。最接近原稿的版本標著「貼近原意」，內容是「進度更新：昨天把匯出的 bug 修好了大部分，不過 csv 遇到大檔案還是會失敗。今天在做帳單頁面，目前有點卡住，因為需要 Dana 那邊的 API key，從週一到現在還沒收到回覆。」，標示背後的說明寫著「事實清楚，只是陳述卡關原因，沒有指責 Dana，團隊容易讀懂」。另外兩個版本，「條列清楚」和「自然口吻求助」，都把卡點改成開口請大家幫忙，第三版的問法是「如果有人比較容易聯絡到她，可以幫我問一下嗎？」。以上是 App 實際回傳的內容，未經修改。

和上面七個做法一樣，它也有缺點，只是不在「週一」這件事上：三個版本都把那個時間留著了，「貼近原意」那版甚至拿掉了「她」，只寫「從週一到現在還沒收到回覆」，而一個阻礙已經卡了多久，正是第 8 部分要你盯著看的數字。缺點在它多加的一句承諾。第三個版本寫了「我後面會再補」，原稿沒有這句話。Subtext 自己也指了出來，在版本下方說「後面會再補 csv」是它加的，「你沒明講，不想承諾的話可以拿掉」。要不要留下這句承諾，由你決定。

---

第 8 部分：設計試行方案，讓它撐得過回顧會議的檢驗

開始之前就先選好成功指標，而且要選你的主管本來就相信的指標。

交付。選一項 DORA 類型的指標，通常是變更前置時間（lead time for changes）或部署頻率（deployment frequency）¹²。如果你們不常部署，週期時間（cycle time）也行得通。

阻礙解決時間。這是你針對主要風險設下的防護。這項指標必須有能力讓實驗喊停，而把這一點明白說出來，實驗才可信。

團隊脈動（team pulse）。每週一個問題，匿名。這對應的是 SPACE 框架裡的滿意度向度，而 SPACE 之所以存在，正是因為只用單一指標衡量生產力會出問題¹¹。沒有這一項，你可能一邊提高產出，一邊讓人倦怠，卻始終沒發現。

四週是剛好的長度。兩週太短，除了新鮮感之外什麼都看不出來。八週則長到讓改回去開始像一場公開的失敗，大家就會變成在替這次試行辯護，而不是解讀它顯示了什麼。

---

真正困難的部分

上面這些，任何人花一個下午讀一讀就能掌握。但多數需要它的人，還是不會把訊息傳出去。

缺的不是證據，而是這樣一個版本的說法：既能講出這場會議行不通，又不暗示主持會議的人不行。這比整理一串引用文獻難寫得多。很多人在 Slack 的草稿裡改了六遍，最後還是放棄了。

這道落差，就是我們做 Subtext 的原因。多數人傳不出去的訊息，內容並不複雜，但光是自己有理還不夠，風險全都在措辭上。站會提案只是其中小小的一個。同樣的模式也出現在要求加薪、拒絕額外的工作、告訴創辦人產品路線圖不對，以及對朋友說不的時候。

以這個情況來說，你可以把提案草稿貼進去，或是把這則訊息要送進的那個對話串截圖給它。它會標出可能讓提案讀起來像指控的字詞，並為底下的感受命名。接著它會提供幾個聽起來還是你自己的版本，因為用別人的口吻送到對方手上的提案，自己就先輸了。提案本身、Scrum 指南，還有退回原狀的辦法，這些要由你自己帶來。

如果你只想從這篇文章帶走一件事，那就是：傳出那則訊息，而且要把還原條件寫進去。「如果阻礙解決時間變差，我們就改回去，我也會講明白。」光是這一句，就拿掉了任何人拒絕的理由。

---

關於我略去的數字的說明

這個主題上有好幾個數字流傳得很廣，但我無法為它們背書，所以上面的內文沒有採用。

有一種說法是，80% 的開發人員把無關緊要的更新，列為站會最讓人煩躁的地方，人們通常把這個說法歸給 Stray 的調查。我查過了，裡面沒有這一項。至於「80% 的會議待辦事項從來沒有完成」這個說法，我找不到出處。常被引用的「時間多花 40%、錯誤多 50%」這個統計數字，人們把它歸給最近一篇《Journal of Experimental Psychology》的論文，但它似乎是 2001 年 Rubinstein、Meyer 和 Evans 那項研究被傳得走樣的版本；那項研究測量的是實驗室裡的工作切換，不能直接套用到早上的會議上¹⁸。各種估算每個團隊每年浪費在會議上多少錢的數字，完全取決於背後的假設，所以第 3 部分的算式，改用你自己團隊的數字。

還有一個缺口。我找不到任何嚴謹的對照研究，直接比較非同步的文字進度更新和同步的進度會議，在交付成果上有什麼差異。GitLab、Doist 和 Basecamp 都主張用文字的版本，而這三家都有自己要捍衛的立場。如果你的主管要求看那份比較，我的回答是：它目前似乎還不存在，而你這次為期四週的試行，就是為你自己的團隊把它做出來的方法。

---

覺得你們的站會值回它的成本，或覺得我讀錯了證據嗎？歡迎到 LinkedIn 告訴我。

Samet Durgun 是 Subtext 的共同創辦人。Subtext 是一款 App，會抓出訊息裡的情緒語氣，並用你自己的口吻改寫。他住在柏林。

---

資料來源

上面的每個連結，只要有原始來源，都直接連到原始來源。

1. The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, . 對這場爭論最有用的單一文件。請直接讀每日 Scrum 那一節，並逐字引用。它確立了這項活動是給開發人員的、長度為 15 分鐘，而且那三個問題在 2020 年版中被刪除。

2. Stray, V., Sjøberg, D. I. K., and Dingsøyr, T. (2016). “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, volume 114. 經同儕審查。記錄了站會的價值（資訊分享、共同解決問題），也記錄了它的失效模式（向主管報告進度、頻率過高、時間過長）。這一篇值得傳給 Scrum Master。

3. Stray, V., Moe, N. B., and Bergersen, G. R. (2017). “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams.” XP 2017, Lecture Notes in Business Information Processing. 針對專業開發人員的調查。報告的數字包括：87% 的敏捷團隊會舉行每日站會，平均評分在中性附近，資淺的開發人員比較正面，資深的開發人員和較大的團隊則比較不然。我採用的是方向性的發現，而不是百分比。

4. Stray, V. and Moe, N. B.，發表於 IEEE Software、談如何調整每日站會做法的實務文章。主張僵化的站會儀式應該配合團隊調整，而不是預設照做。確切的標題和年份尚未確認，網路上流傳的版本所附的參與者人數，我無法查證。

5. Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, volume 109, issue 2. 注意力殘留這個概念的出處。這是敏捷領域之外的有力證據，顯示工作切換會拉低接下來那項工作的品質。

6. Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. 以及 Mark, G. (2023). Attention Span. Hanover Square Press. 工作被打斷相關發現的出處，也是到處流傳的「大約 23 分鐘」恢復工作時間的出處。這個數字是真的，但引用時常常比原始研究能支持的更精確，所以請引用原始研究，並寫成「超過 20 分鐘」。

7. Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. 談會議浪費與會後恢復的標準參考書。我採用的是定性的發現，而不是特定的百分比，因為各項調查的數字不一。

8. Microsoft Human Factors Lab，關於會議之間休息的 EEG 研究，經由 Microsoft WorkLab 和 2021 年 Work Trend Index 發表。生理證據，顯示壓力會隨連續的會議累積，而休息可以降低壓力。它之所以有用，是因為它是測量，不是問卷調查。

9. Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. 心理安全感最基礎的引用文獻。談的是一般的團隊，不是專門針對站會，所以不要過度宣稱有因果關係。

10. Rietze, S. and Zacher, H.，關於每日站會、心理安全感、工作滿意度與團隊績效感受的研究，刊於 European Journal of Work and Organizational Psychology。已發表的研究中，最有力支持站會的一篇論述，這正是你應該自己先提出來的原因。發表年份尚未確認；流傳的版本標的是 2025 年，我無法獨立查證。

11. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. 可免費閱讀。可以用其中的滿意度與福祉向度，說明為什麼要在交付指標之外，也追蹤團隊脈動。

12. Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. 四項 DORA 交付指標的出處。請用其中一項作為你的產出量指標，這樣指標才站得住腳，而不是為了這次場合臨時編出來的。

13. Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” . 簡短、免費，也是轉寄給還在猶豫的同事時，最有說服力的一篇。

14. GitLab all remote handbook, . 一家大型組織公開以非同步方式更新進度。證明這種模式可以大規模運作，不過 GitLab 在這個論點上有自己的利害關係。

15. Shopify 的行事曆大清理，2023 年 1 月，由 Bloomberg、Fortune 和其他媒體報導。報導指出，這次行動從公司行事曆上清除了數千場定期會議，並禁止在週三舉行超過兩人的定期會議。換回多少小時的具體數字，是公司自己提供的，所以請歸給 Shopify，而不要當成測量到的事實來寫。

16. Atlassian Agile Coach，站會指南。業界指南，建議站會要簡潔、依團隊需求調整，包括採用非同步的形式。它之所以有用，是因為你的主管在敏捷實務上本來就信任這個來源。

17. 工具：Geekbot 和 Standuply 用於 Slack 和 Teams 上的非同步站會，Range 用於團隊簽到。在內部推薦其中一個之前，請先確認目前的價格和產品狀態。

18. Rubinstein, J. S., Meyer, D. E., and Evans, J. E. (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance. 「多達 40% 的生產時間」這個工作切換說法的真正出處。列在這裡，是讓你自己去核對，而不是重複那個以訛傳訛的版本。