你早就知道站会不管用了。难的是把这话说出口。

你们团队里，已经有人把那条消息打出来过了，大意是：“我觉得每天的站会对我们不太管用了。”然后那个人盯着看了一会儿，想了想对方读到后会是什么反应，把它删掉，点进了会议。

删掉的那一下，才是这篇文章真正要谈的事。关于站会的研究不难找，而且大多指向同一个方向。难的是那句话。你想说的这件事，同时带着三种各不相同的社交风险，而这三种风险，全都会落到你个人头上。

风险一：你显得偷懒。任何取消会议的请求，默认都会被读成你想少被盯着。

风险二：你显得不是个好队友。大家都把站会说成是让所有人保持同步的办法，反对它，听起来就像在反对同步。

风险三：你像是在攻击一个人，而不是一套流程。这个会总有人在负责，可能是 Scrum Master，可能是经理，也可能是两年前把它办起来的那个人。对方会把对这套仪式的批评，听成对自己判断力的批评，因为在多数团队里，两者确实就是一回事。

再往下说之前，我得先交代一件事：我是 Subtext 的联合创始人，这款应用就是为这类消息做的，也就是措辞带来的风险比论点本身更大的那种。你认同“难的是那句话”，对我显然有好处，所以这一点你自己掂量，下面的每一项研究，也最好自己去核对。文章接近结尾处，有 Subtext 的一次真实运行，读的是一条照说话的方式打出来的进度更新，写的人卡在一位同事那里，对方从周一到现在都没回。

于是大家什么也不说，这个会就一直开下去，只因为没人找到合适的措辞。

好消息是，这些措辞是有的，而且并不复杂。你只需要按特定的顺序把它们组合起来，而顺序比证据更要紧。

---

换个角度，才能赢下这场争论

别去争论站会是在浪费时间。这种争法每次都会输，原因就是上面那三个。

要争的是另一件事：你们现在开的这一版，已经不是这个会本来该有的样子；然后提出一个随时可以退回去的试验，把它修正过来。

在这一点上，《Scrum Guide》站在你这边，可大多数人从来没去查过。2020年版指南¹把 Daily Scrum 定义为一场为 Scrum 团队里的开发人员举行、时长15分钟的活动，目的是检视朝着 Sprint 目标的进展，并调整计划。指南没有把它定义成向经理做的汇报。2020年的修订版还取消了规定好的三个问题，而多数团队至今仍在每天早上照着念。¹

如果你们的站会是围成一圈，每个人向在场职位最高的那个人汇报昨天和今天的事，那么保留它并不是在捍卫 Scrum，因为规则手册早就放弃了这种形式。这话你可以直接说出口，不指责任何人。

你要的不是少一点问责，而是按框架本来的描述来开这个会，并试试一种成本更低的形式能不能站得住。

把这个思路用到文章开头那条消息上，也就是人们通常删掉、没有发出去的那一条。

草稿 “我觉得每天的站会对我们不太管用了。”

读起来像抱怨，不像提案 · 开头那三种风险全占了 · 没有给对方留下任何可以答应的东西

改写后 “我觉得我们现在的站会，已经不是 Scrum Guide 描述的那个样子了。我想试一种成本更低的形式，看看行不行。如果不行，我们马上改回来。”

---

第1部分：经得起推敲的理由

这个话题上流传的数字，我删掉了很多，删了哪些、为什么删，我写在了文末的说明里。下面这些，是我愿意摆到一位心存怀疑的经理面前的东西。

1. 它变成了向上级做的状态汇报，而框架说它不该是这样。 这是记录最充分的一种失效方式。Stray、Sjøberg 和 Dingsøyr 对每日站会做的扎根理论研究发现，参与者看重站会，是因为它能共享信息、一起解决问题；而当会议变成向经理做状态汇报，或者开得太频繁、太久时，参与者的反应是负面的。² 同一个研究小组面向从业者写的文献里，也出现了同样的发现。⁴

2. 那三个固定问题带来的是复述，而不是协调。 “昨天我在做那个任务，今天继续做那个任务。”没人追问，也不会因此改变任何事。这种形式鼓励的是表演忙碌，而不是检视朝着目标的进展，这也正是2020年版指南取消这三个问题的原因。¹

3. 资深工程师和大团队从中得到的最少。 Stray 等人调查了专业开发人员，发现总体评分集中在中性附近，初级开发人员更正面，资深开发人员和较大团队的成员则更可能觉得价值不大。³ 如果你们最有经验的人在会上投入度最低，那说明的是这种形式有问题，不是他们有问题。

4. 它把上午切成了两半。 Paul Graham 在2009年提出的观点¹³至今仍然成立。做东西的人需要大块不被打断的时间，上午中间放一场会，就可能把整个上午切成两段，每段都短得没法做难的事。上午10:30的站会就是最典型的例子。此外还有一笔提前就要付出的成本：会前的那45分钟里，人们会避免开始任何需要深度投入的事。

5. 任务切换会拖累会议前后两边的工作。 Sophie Leroy 的研究提出了“注意力残留”（attention residue）这个概念：从一项任务切换到另一项任务时，一部分注意力还留在前一项任务上，后一项任务的表现就会变差。⁵ 站会让每位参会者切换两次，一次进去，一次出来。

6. 回到手头的工作，要花实实在在的时间。 Gloria Mark 关于被打断的研究，是那个流传很广的数字的来源：回到被打断的任务大约要23分钟。她与 Gudith 和 Klocke 合作的研究还发现，人们会靠加快工作速度来补偿被打断的损失，代价是压力、挫败感和感受到的工作量都上升。⁶ 引用这个数字要小心。它是谈效率时被滥用得最厉害的数字，见过它被驳斥的经理，会拿这一点来对付你。

7. 阻塞项被说出来了，却没有被解决。 留意一下你们团队有没有这种情况。有人说自己被卡住了，大家点点头，真正的解决发生在四十分钟后，是两个人在私聊里完成的。如果规律就是这样，那么会议并没有解决这个阻塞项，它只是约定了后来真正解决问题的那场对话。

8. 会议的负荷会在身体上累积。 Microsoft 的 Human Factors Lab 用 EEG 监测了一场接一场开会的参与者，发现压力指标在整个过程中不断上升，而短暂的休息能减轻这种累积。⁸ Steven Rogelberg 的会议科学研究，则从问卷调查的角度记录了同样的现象。他还记录了一场糟糕的会议过后，人们要花时间缓过劲来，这段恢复时间是在会议本身的时长之外另加的。⁷

9. 它不适合分布式团队。 总有人要在很不合适的钟点参加。GitLab 的《all remote handbook》¹⁴是公开资料里最完整的一份论证，主张改用异步方式同步进展。它值得参考，恰恰因为它出自一家大规模按这种方式运作的公司，而不是出自某个博客。

10. 固定每天开一次，不管有没有要协调的事，都得每天付一次代价。 在工作彼此依赖较少的团队里，真正需要协调的时候是断断续续的。固定开会，等于在每个风平浪静的日子里都多付了一笔。

---

第2部分：反方的证据，该由你自己先拿出来

和对方谈之前，先把反对你的理由自己讲一遍。这是让人认真对待你的最快办法，也让经理不必觉得自己得一个人站出来替这个会辩护。

站会开得好，能做到三件很难替代的事。

站会能让阻塞项早点浮出水面。一个问题要是不在09:30摆上桌面，本来会耗掉整整一天，光这一点就值回那十五分钟。你要提出的替代方案，必须把这项功能接住。

站会能建立起“谁在做什么”的共同认知，减少重复和互相冲突的工作。Stray 和 Dingsøyr 把这一点记录为人们提到的好处之一。²

站会有助于心理安全感。Rietze 和 Zacher 发现，每日站会与心理安全感之间呈正相关，而心理安全感又与工作满意度和对团队绩效的感知相关。¹⁰ 这建立在 Edmondson 的奠基性研究之上，后者把心理安全感与团队的学习行为联系在一起。⁹ 一个固定出现、风险很低的碰头机会，对建立信任多少有些作用，对新团队或分布式团队尤其如此。

所以，在对方说得对的地方，就认下来。如果你们团队规模小、工作上彼此紧密依赖、成员偏初级，或者才组建三周，站会很可能是值回成本的，你应该直说。

---

第3部分：开口之前，先拿到你自己的数据

两周，三件事。要在谈话之前做完，因为拿意见去对抗仪式会输，拿算术去对抗仪式就不会。

量一下实际时长，而不是日程上排的时长。每天都计时。多数团队会发现，那个15分钟的会实际要开22分钟。

把人力成本算出来。参会人数，乘以实际时长（以小时计），再乘以一年的工作日数。八个人的团队，严格按15分钟算，每天是2人时，每周约10人时，一年大约460人时。按每小时60欧元的综合人力成本计算，约合2.7万欧元，而且这个数字还没把会议前后的恢复成本算进去。用你们自己团队的数字，这样就没人能在你代入的数据上挑你的毛病。

数一数阻塞项。连续十个工作日，把站会上提到的每一个阻塞项记下来，并标明它是在会上解决的，还是会后在别处解决的。通常是这个数字让争论到此为止。

匿名问一问团队。只问一个问题：站会对你做好工作有没有帮助，是或否，为什么。匿名才能拿到真实的答案，也意味着你是在替团队说话，而不是替自己说话，这就化解了开头那份清单里的风险二。

---

第4部分：怎么措辞

四种场合，四套话术。具体内容按你的情况改，结构要保留，因为起作用的是结构。让工作消息读起来坚定而不冰冷的，也是这同一种结构。

每一套都遵循同样的四个节拍。先肯定对方需要什么。用对方在乎的标准说出代价。提出可撤回、限定时间的方案。把举证的责任和搭建的工作都揽到自己身上。你会发现，这四步没有一步是在证明自己是对的。

对你的经理，一对一谈

“我想保护好团队的专注时间，同时不让你失去对进展的掌握。我手头有两周的数据，能看出我们的站会实际是怎么用的。它实际要开22分钟，不是15分钟。八个人加起来，一年大约是675人时。这十天里，一共提出了六个阻塞项，在会上真正解决的只有一个，其余的都是会后在私聊里解决的。

我想试四周。每个人在共享频道里于09:30前发一份书面更新，你随时都能看；再开一个专门放阻塞项的频道，谁被卡住了，就马上直接@你；另外每周开一次现场同步会。我会拿阻塞项的解决时间跟现在的情况做对比。如果变差了，我们就改回来，我会在回顾会上说明。这些我来搭。”

对你的 Scrum Master

“我最近又把2020年版的 Scrum Guide 读了一遍。它把 Daily Scrum 定义成开发人员自己的会，还取消了那三个问题。我们现在的站会，慢慢变成了一轮冲着在场职位最高的人做的汇报，而这恰恰是指南专门想避免的。

我们能不能试一个 Sprint，不再围成一圈轮流说，改成对着看板来开？结束后再问问开发人员，这样是不是对他们更有用了。”

看看这段话做了什么。它把框架交给对方当权威，你自己就不必扮演这个角色；它也让对方成为恢复这项实践的人，而不是在替一个已经走样的版本辩护的人。

先对同事说，在做任何别的事之前

“跟我说句实话，站会对你到底有没有用，还是只是熬过去就算了？我想把这事提出来，但前提是我能代表团队，而不只是代表我自己。”

这一步一定要先做，每次都是。如果有两个人说，站会是他们唯一能开口求助的时候，你的提案就必须保住这一点，而且你是在公开表态之前就知道了这一点。

在回顾会上

“今天我想检视一件事。我把我们的站会记录了两周，这是它的成本，这是它实际解决了多少个阻塞项。我不是要大家取消它，我想问的是，能不能先把形式改一个 Sprint，看看数字，再决定要不要做任何长期的改动。”

写成书面提案

主题：站会改为异步，为期四周的试验

目前我们每天的站会，八个人开下来要22分钟，一年大约是675人时。过去十个工作日里，站会上共提出了六个阻塞项，在会上解决的有一个。

提案，为期四周，完全可撤回：

每人在 #team-standup 里于09:30前发书面更新，三行即可：朝着 Sprint 目标的进展、今天的重点、有没有被卡住的事。 阻塞项一出现就直接@到相关的人，不再留到第二天早上。 每周一开一次30分钟的现场同步会，用来做计划，以及处理所有需要当面聊的事。

我会跟踪阻塞项的解决时间、周期时间和一次简短的团队状态调查，并把这三项带到[日期]的回顾会上。如果阻塞项的解决时间变长，我们就恢复原样。工具我来配置，试验我来负责。

那条消息里最重要的一句，是明确写出的撤回条件。正是它把你的提案从一次变更变成了一次测试，通常也正是它换来了对方的点头。

---

第5部分：对方会怎么回你

“我需要知道每个人都在做什么。” 书面更新让你看到的比开会更多。它们可以搜索，会留存，你在07:00或19:00读都行，不用非得在09:30坐在会议室里。

“阻塞项会被晾在那儿。” 恰恰相反。一出现就发出来的阻塞项，比留到第二天早上的，更快得到关注。这正是我提议要跟踪的那项指标，也是会让我自己叫停这次试验的那一项。

“才十五分钟而已。” 这是十五分钟乘以八个人，每个工作日都要来一遍，再加上每个人回到原来工作状态所需的时间。全年的总数，第3部分已经算出来了。

“Scrum 要求有 Daily Scrum。” Scrum 要求的是开发人员自己的 Daily Scrum，而且2020年版指南已经取消了我们还在用的那三个问题。我们现在开的，并不是指南所描述的那个东西。¹

“团队会失去凝聚力。” 这确实是个风险，所以每周同步会要保留。试验期间我还会跟踪团队状态调查，凝聚力要是下降，我们看得到，不用靠猜。

---

第6部分：人们输掉这场争论的五种方式

把它说成是自己想少干点活。这恰好印证了对方一进门就带着的那个怀疑。你本想提的是一个试验，可草稿实际传达出来的却是一句抱怨，这两者之间的差距，正是 Subtext 在你发出之前能抓住的。

直接砍掉会议，却没说拿什么来替代。随之而来的混乱，大家会记在你一个人头上，也确实该记在你头上。

一个人说了算。团队的仪式要靠团队一起决定才改得动，不然一个月内它就会自己回来。

跳过试验和指标，会把一个可以检验的提案变成与现状的意见之争，而在这种较量里，赢的总是现状。

忽视站会对哪些人有用。如果团队里的初级成员要靠它，就围绕他们来设计方案，并且在会上明说。这不花你任何成本，还能在有人提出最有力的反对意见之前就把它化解掉。

---

第7部分：拿什么来替代

一共七个选项，每一个我都附上了它的缺点。

用机器人收集的异步书面更新。Geekbot、Standuply 或 Range 会提醒每个人填写，并把内容发到共享频道。¹⁷ 能跨时区使用，还留下可搜索的记录。如果没人回应大家发的内容，就可能退化成没人读的走过场式汇报。

每周两次的站会。保留现场同步，只是降低频率。改动小，所以容易说服别人。遇到紧急的事，还需要一个配套的频道。

对着看板过一遍，取代围成一圈轮流说。把工作项从右往左过一遍，聊的是任务，不是人。立刻就能终结那种每个人轮流汇报的模式。前提是团队让看板保持最新。

专门的阻塞项频道。这是价值最高的一环，增设起来也最便宜。需要大家自觉去发，还要有人盯着。

按需结对。解决速度最快，也没有旁人围观。但全团队能看到的信息会变少，所以要留下书面记录。

每周一次的深度同步会。给15分钟的会装不下的那些对话留出空间。频率太低，单靠它不行。

无会议日。Shopify 在2023年清理日历，是被引用最多的企业案例；Bloomberg、Fortune 等媒体报道称，这次清理从公司日历上清除了数千场重复会议。¹⁵ 这是一项保障专注的政策，不是协调机制，所以要搭配上面的任意一种来用。

最常奏效的组合是：用书面更新了解每天的情况，用阻塞项频道处理一切紧急的事，其余的交给每周一次的现场同步会。

如果大家抗拒的是打字写更新，可以直接说出来。Subtext 接受语音，也接受你照说话的方式打出来的文字。下面这条更新是我为这次测试编的，就是照说话的方式打的：“嗯那个，昨天我把导出那个bug修完了，呃，基本上吧，csv那部分大文件还是会挂，今天我在弄账单页面，然后说实话我有点卡住了，因为我需要Dana那边的API key，她从周一到现在都没回我，嗯对，这就是我要发团队群的进度”。

Subtext 只给了一个标签，叫“隐性指责”，并把底下的情绪命名为“受阻”。标签的理由点出了“她从周一到现在都没回我”这几个字，说它们放在群里“可能被读成在点名指责Dana”。情绪的理由是“有点焦虑也有点无奈”。它开头说“卡在别人那边确实让人着急”，接着说自己把进度理成了团队群里好发的样子。

它给了三个版本。第一个标着“简洁直接”，请 Dana 帮忙的一句是“@Dana 方便的话帮我看一下”，标为“可放心发送”。第二个标着“温和带点歉意”，里面有一句“周一我问过”，标为“需要留意”，标记背后的说明指出这样写“仍有一点追责意味”。第三个在最后给 Dana 留了个出口，“告诉我找谁拿也行”，也标为“可放心发送”。应用最后说，“找谁拿也行”是它自己加的选项，“不合适可以删”。以上是应用的真实输出，没有改动。

和上面每个选项一样，它也有缺点。三个版本里，保留了“周一”的只有第二个，而它正是标为“需要留意”的那个。另外两个标为“可放心发送”的版本都没有写这个日子，应用在最后那条回复里也说明了：它没写“周一到现在没回”，是为了“避免群里显得在点名”。可是一个阻塞项已经挂了多久，恰恰是第8部分要你盯的数字。补救办法是自己把日子补回去，同时不指向任何人（从周一起一直卡在 API key 上）。

---

第8部分：把试验设计好，让它经得起回顾会的检验

开始之前就把成功指标定下来，而且要选经理本来就信得过的。

交付。选一项 DORA 式的指标，通常是变更前置时间或部署频率。¹² 如果你们不常部署，用周期时间也行。

阻塞项解决时间。这是你针对主要风险设的保险。这项指标应当有权叫停试验，而把这一点说出口，试验才有可信度。

团队状态调查。每周一个问题，匿名。它对应 SPACE 框架里的满意度维度；这个框架之所以存在，正是因为只用单一指标来衡量效率，容易出问题。¹¹ 没有它，你可能一边提高了吞吐量，一边把人耗垮，却始终没有察觉。

四周是合适的长度。两周太短，除了新鲜感，什么也看不出来。八周又长到让撤回开始像一次公开的失败，于是大家会去替试验辩护，而不是去读它显示了什么。

---

真正难的部分

上面这些，任何人花一个下午读一读都能找到。可大多数需要它的人，仍然不会把那条消息发出去。

缺的不是证据，而是这句话的一个版本：既能说出这个会不管用，又不暗示负责这个会的人不称职。这比写一份引文清单难得多。人们在 Slack 的草稿框里改了六遍，最后还是放弃了。

我们做 Subtext，原因就在这道缺口。人们发不出去的消息，大多数在内容上并不复杂，可是光有道理还不够，全部的风险都在措辞上。站会提案只是其中很小的一例。同样的局面，还会出现在要求加薪、拒绝额外的工作、告诉创始人产品路线图有问题，以及拒绝朋友这些场合。

就这份提案来说，把草稿粘贴进去，或者把它要发到的那段对话截图给它。它会标出可能让这条消息读起来像指责的字词，并点出底下的情绪。再给出几个仍然保留你自己口吻的版本，因为一份换了别人口吻才送到对方手里的提案，自己就先输了。提案本身、《Scrum Guide》和退路，得由你自己带上。

如果你只从这篇文章里带走一样东西，那就是：发出那条消息，并且把撤回条件写进去。“如果阻塞项的解决时间变长，我们就改回来，这一点我会明说。”光是这一句，就让任何人都没了说不的理由。

---

关于我没有采用的数字

这个话题上有好几个数字流传很广，但我无法为它们担保，所以上面的正文里没有用它们。

人们通常把“80%的开发人员把无关的更新列为站会上最大的烦恼”这一说法，算到 Stray 的那份调查头上。我查过，里面没有这个数字。“80%的会议行动项从未完成”这个说法，我也找不到来源。常被引用的“耗时多40%、错误多50%”这个统计，人们说它出自《Journal of Experimental Psychology》上的一篇近期论文，但它看起来是2001年 Rubinstein、Meyer 和 Evans 那项研究被传歪了的版本；那项研究测的是实验室里的任务切换，不能简单地推广到上午的一场会议上。¹⁸ 各种“每个团队每年因会议浪费多少美元”的数字，完全取决于背后的假设，所以第3部分的计算用的是你自己团队的数字。

还有一处空白。我没有找到一项严格的对照研究，直接比较异步书面状态更新和同步状态会议在交付结果上的差别。GitLab、Doist 和 Basecamp 都主张书面形式，而这三家都有各自要维护的立场。如果你的经理要这样的对比，我的回答是：它目前似乎还不存在，而你的四周试验，正是为你自己的团队做出这份对比的办法。

---

觉得你们的站会值回了它的成本，或者觉得我读错了证据？欢迎到 LinkedIn 上告诉我。

Samet Durgun 是 Subtext 的联合创始人。这款应用会捕捉你消息里的情绪语气，并用你自己的口吻改写。他常驻柏林。

---

参考来源

凡有原始来源的，上文每个链接都直接指向它。

1. The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, . 对这场论证来说最有用的一份文件。直接读 Daily 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., practitioner writing in IEEE Software on adapting daily stand-up practice. 主张死板的站会仪式应当按团队情况调整，而不是默认照搬。确切的标题和年份尚未核实，网上流传的版本里有一些参与者人数，我无法验证。

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 study on breaks between meetings, published via Microsoft WorkLab and the 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., research on daily stand-up meetings, psychological safety, work satisfaction and team performance perceptions, 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 calendar purge, January 2023, as reported by Bloomberg, Fortune and others. 据报道，这次清理删除了公司日历上数千场重复会议，并禁止在周三举行超过两人参加的重复会议。收回多少小时这个具体数字来自公司，所以要归到 Shopify 名下，而不是当作测得的事实来陈述。

16. Atlassian Agile Coach, standup guidance. 行业指南，建议站会保持简短，并根据团队需要调整，包括采用异步形式。有用之处在于，它来自你的经理在敏捷实践上本来就信任的来源。

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%的有效工作时间”的任务切换说法的真正源头。列在这里，是为了让你自己核对，而不是去重复那个以讹传讹的版本。