站会：怎么开出值得那 15 分钟的一场会

九个人在同一个通话里。第四个人说"昨天我基本上还是在推进前天提到的那件事"，宫格里某处的摄像头悄悄关掉了。现在是 9:47。这场会 9:30 就开始了。

站会本该花掉 15 分钟，产出一份当天的计划。可有相当多的站会花了 25 分钟，产出的是一份讲给会上级别最高的那个人听的状态汇报——那是另一种会议，只是还挂着一个已经不合身的名字。

解法不是纪律，而是这场会到底在问什么——而大多数团队问的，仍然是这套格式的作者们早在很多年前就不再推荐的那三个问题。

站会到底是什么

站会是一个共享同一个目标的团队每天做的一次短同步。所有人看着同一批工作，说清楚哪里卡住了，然后调整当天的计划。它不是进度汇报，也不是做决定的地方——尽管它常常是你发现"有个决定得做了"的地方。

这套做法有两个源头。Ken Schwaber 和 Jeff Sutherland 于 1995 年在 OOPSLA 大会上首次共同发表了 Scrum，这个框架里就包含一个每日事件；而 "scrum" 这个词来自竹内弘高与野中郁次郎 1986 年发表在《哈佛商业评论》上的那篇文章，借用的是橄榄球里全队一起把球推进的画面。1990 年代末，极限编程的实践清单里也出现了每日站会。今天大多数人用这两个名字指同一件事。

站着是个小把戏，不是什么原则：站着开会会不舒服，而不舒服会给会议长度封顶。《Scrum 指南》的任何一个版本都从未要求过它，而坚持要求站着，会把所有没法舒服站立的人排除在外。

有一条边界要划清：这是团队每天的同步。它不是管理者带着团队逐条过优先级的那种周期性会议——那是另一个物种，我们在如何开好一场部门例会里写过。它当然更不是面向全公司的全员会议。当站会的内容开始往这两者里搬家时，说明上游有东西坏了。

现在的《Scrum 指南》说了什么，又不再说什么

大多数团队正在跑的格式，来自一份早就不再是他们以为的那个样子的文档。

2020 版《Scrum 指南》——也就是现行版本——把每日 Scrum（Daily Scrum）描述为"Scrum 团队开发人员的一个 15 分钟事件"，在冲刺期间每个工作日的同一时间、同一地点举行。它的目的是检视朝向冲刺目标的进展，并调整冲刺待办列表。产品负责人和 Scrum Master 只有在自己也在处理该列表中的条目时才参与。

接下来是几乎没人读过的那句话：只要会议聚焦于朝向冲刺目标的进展，并产出下一个工作日可执行的计划，开发人员就可以自行选择任何结构和技巧。

这意味着那三个著名的问题已经没有了。更早的版本确实规定过它们；2020 年的修订连同大量其他规定性措辞一起把它们删掉了。现行 Scrum 里没有任何一条要求谁必须说自己昨天做了什么。指南还顺带提了一句：这并不是团队唯一可以重新规划的时刻。

那三个问题为什么老化得这么难看

我昨天做了什么。我今天要做什么。什么卡住了我。对一个从没做过这件事的团队来说，把它当辅助轮，没问题。但把它当成永久结构，它会以四种可预见的方式失败。

它问的是人，不是工作：九个人乘以三个回答，就是二十七段小独白，而任何一位听众真正需要的大概只有四段。目标从头到尾不会出现，因为没有任何一个问题问到它。

"昨天"是一句审计式的提问：让一个人当着同事的面交代自己前一天干了什么，你拿到的会是一份辩护，而且会被填充得听上去很饱满。这正是这个问题本身在邀请的东西。

汇报的方向会漂移：目光会飘向在场级别最高的那个人，三周之内，这就从同侪之间的同步变成了给他一个人做的简报。

它把冲刺的真实状态藏了起来：所有人都很忙，没有人被卡住，而目标照样在往后滑。这套格式没有任何办法把它显示出来。

今天就试一次：开一场谁都不准说自己昨天做了什么的站会。如果它照样能完成任务——通常都能——那么那个问题从来就没有承载过价值。

更好的站会问题

能修好大多数站会的那个转变，是走工作，而不是走人。把看板打开，一条一条过，从右往左——先从离完成最近的开始，因为做完比开始更值钱。轮到谁的条目，谁就开口，没有人需要表演一份日报。

真正配得上一席之地的问题：

• 今天必须发生什么，这个条目才能往前走？问的是条目，由手上拿着它的人回答。
• 什么有风险，我们什么时候会知道？把阻塞问题重写成一个能被诚实回答的版本。承认有风险不需要付出什么代价，说自己被阻塞了却像在认罪。
• 从昨天到现在，有什么变化是别人需要知道的？这条能抓住那个只有三个人听说过的私下决定。
• 散会之后，谁需要谁的十分钟？这是整场会里回报率最高的问题，也是让另外十四分钟保持干净的那一个。
• 我们还能达成目标吗？一周里当众问上两三次。一个答不上来的团队没有共享目标——那是一个套着站会外衣的规划问题。

15 分钟，都花到哪里去了

这个时间盒不随人数增长——不管你是四个人还是十个人，15 分钟就是 15 分钟。给一个十人团队算一下，每人 90 秒，这是"轮流发言是错误的形状"能给出的最清楚的信号。

站会会以三种方式膨胀。有人当场开始解决问题。有人在给一个不在场的干系人做简报。还有人靠叙述来证明自己的努力——这是这场会过去被怎么用的症状，不是懒惰。

三种情况的解法是同一个：点名它、给它找个主人、给它定个时间。"这是个设计问题——Rosa 和 Tunde，散会之后马上聊，15 分钟。"任何变成承诺的东西都要以一个像样的任务的形式离场，而怎么把它写出来是有方法的，见我们那篇怎么写出真的会被做完的行动项。

如果超时几乎天天发生，就别再把它叫作纪律问题了。超出去的那部分本身就是一场你的团队需要的会议——而一场每周一次、背后有一份真正的会议议程模板撑着的工作会，比每天早上多焊上十分钟要好得多。

一份可以直接抄走的每日站会模板

一块看板，一个计时器，六个步骤。这个格式刻意把条目放在前面：只有当某个人需要另一个人做点什么时，名字才会出现。

模板 — 15 分钟每日站会

[团队] 站会 — [日期] · 15 分钟 · 计时：[谁]

我们正在朝着走的目标：[一行——只有当它变了才念出来]

从右往左走看板

[条目] — [状态] — [今天必须发生什么它才能往前走] — [谁拿着它]

有落不了地的风险

[条目] — [为什么] — [我们什么时候会知道]

昨天之后发生的变化

[别人需要知道的那件事——决定、故障、新信息]

今天需要找人

[名字] 需要 [名字] 的 [什么] — [他们什么时候碰头]

挂起

[话题] → [谁负责] → [什么时候进行]

填好的例子 — 15 分钟站会

支付小组站会 — 9 月 1 日（周二）· 15 分钟 · 计时：Meg

目标：让退款在 12 日之前走通新账本。

从右往左走看板

退款冲销 — 评审中 — 需要 Nils 在午饭前看一眼 — Rosa

对账任务 — 进行中 — 今天在 9 月的数据上跑 — Tunde

部分退款 — 未开始 — 冲销上线之前没人接手

有落不了地的风险

对账任务 — 9 月的导出少了两天的数据 — Tunde 会在 14:00 之前知道结果

昨天之后发生的变化

财务把截止时间提前到了 10 日。比看板上写的日期早了两天。

今天需要找人

Rosa 需要 Nils 的评审 — 午饭前 · Tunde 需要数据工程那边补上缺掉的导出 — Meg 会在 10:00 去催

挂起

部分退款到底要不要放进这一批 → Meg → 散会后 20 分钟，和 Tunde 一起

跑得好的话，这些大约花七分钟。剩下的八分钟是缓冲，它的作用是让那个真正需要聊一聊的条目不必被赶时间。

异步站会，以及它什么时候只是状态表演

异步站会用"在截止时间前发到某个频道里的书面更新"替换掉会议本身。做得好，它对很多团队来说都胜过实时版本。做得差，它就是一个没人读的仪式——比它取代掉的那场会还糟，因为至少在会议里人们还会听。

异步在这些情况下胜出：团队跨越的时区超过几个小时，任何一个实时时段都会惩罚到某个人；工作之间是松耦合的；以及团队的价值来自长段不被打断的时间，此时一个固定的 9:30 就是一次打扮成协作的打断。

在这些情况下保持实时：大家在改同一批文件，一次撞车就要赔上半天；团队还很新；或者那些帖子已经悄悄地没人读了——花一分钟看看有没有人回复，就能查出来。

既要实时又是分布式，排时间比看上去难得多，因为每日会议没法像月度会议那样轮换：一个不友好的时段，会对同一个人不友好一整年。把它放进真实的重叠窗口里，而不是总部早晨的开头。重叠时间不到三小时左右时，异步是诚实的答案，不是偷懒的答案。

让异步真正成立的那条规则：一条点了别人名字的帖子是请求，不是状态行；而请求要在同一个工作日内得到回应。没有它，你有的只是一面更新墙，没有协作。

模板 — 异步站会帖

#[团队]-standup — [日期] · 在 [时间，你的本地时间] 之前发出

四行。细节放到 thread 里。

在推进

[你今天会做完的那一件事。不是一个清单。]

有风险

[什么可能落不了地，以及你什么时候会知道]

请求

[@名字 — 你需要什么、什么时候之前要 — 或者写"无"]

提醒一声

[一件团队没听到会不高兴的事]

填好的例子 — 异步帖

#payments-standup — 9 月 1 日（周二）· Tunde，09:10 WAT

在推进

对账任务正在 9 月的数据上跑——目标是在我下班前拿到结果。

有风险

导出里少了两天。如果 14:00 UTC 之前修不好，这件事就会滑到周四。

请求

@meg — 能不能去数据工程那边催一下 3 日和 4 日的数据？14:00 UTC 之前要。

提醒一声

财务把截止时间提前到了 10 日。看板上还写着 12 日。

关于工具，说点实在话：一场 15 分钟的站会不需要转录稿，谁要卖给你一份，那是在解决一个你没有的问题。例外很窄——那种"站会"其实是一段录像、有一半人事后才看的分布式团队，以及那种总是变成决策会、却没人留下记录的站会。对这两种情况，一个能录音并总结通话的 AI 会议助手才配得上它的位置：Laxis 覆盖 Zoom、Google Meet 和 Teams，把行动项和它们的负责人抽出来，并支持 100 多种语言。而对一场正常的七分钟同步，一块看板加一个计时器胜过任何软件。

站会死掉的四种方式

怎么杀掉或者修好一场没人觉得有价值的站会

别在站会上投票表决。一个一个单独去问，因为在一群人面前，没人愿意当着安排这场会的人的面说它是浪费时间。

然后做那个实验。把它取消两周，什么都不拿来替代——不是换一场会，是什么都没有——并且先把你预期会坏掉的东西写下来。大多数团队能撑大约四天，然后就会有两个人在同一件工作上撞车，或者同一个决定被做了两遍。那次撞车就是这场会一直在提供的价值，而现在你知道它有多大了。

如果什么都没坏，那说明这个团队本来就没有在共享工作。站会一直在为几条并不需要每日协作的平行轨道做补偿，而诚实的解法是改变工作的切分方式，而不是让这个仪式继续活着。

如果还不到杀掉它的程度，就把频率砍一半。在 Scrum 之外，一周三个早上是完全正当的；在 Scrum 之内，这意味着你已经离开了这个框架——只要那是你决定的，而不是不知不觉滑过去的，那也没问题。而如果活下来的是一场决策会而不是同步会，就按决策会来对待它：一份议程、一个引导者、一份书面记录。记住东西，恰恰是站会最不擅长的事。

给那些确实需要记录的会议

Laxis 会加入 Zoom、Google Meet 和 Teams 上那些真正重要的通话，写好摘要，并把每一条行动项连同它的负责人一起列出来。免费方案每月包含 300 分钟转录。

免费试用 Laxis

这把你留在了哪里

站会是少数几种价值很容易被检验的会议之一，而几乎没有人去检验它。取消它，看看什么会塌。换掉一个问题，听听人们说话的方式会有多不一样。把它往后挪半小时，看看那个早晨到底值不值得保护。

写规则的那些人已经悄悄不再告诉你这 15 分钟该怎么花了。那是一份邀请，不是一次疏忽。

常见问题

站会是什么？

站会是一次简短的每日同步，通常 15 分钟，一个朝着共同目标工作的团队在这里一起检查进展、调整当天的计划。它存在的意义是把卡住的地方和谁需要谁暴露出来，而不是向上汇报状态。在 Scrum 里，与之对应的事件叫每日 Scrum（Daily Scrum）。

每日站会应该开多久？

15 分钟，而且这个数字不随人数变化。2020 版《Scrum 指南》把每日 Scrum 固定为 15 分钟，与团队规模无关——这正是为什么一人一轮的轮流发言在超过六七个人之后就不再管用。如果你稳定地需要 30 分钟，那你是在站会里开一场工作会。

站会的三个问题是什么？

我昨天做了什么、我今天要做什么、什么在阻塞我。更早版本的《Scrum 指南》规定过它们，但 2020 年的修订把这条规定完全删除了。团队仍然可以用它们，很多新团队也确实觉得这套辅助轮有用，但现行 Scrum 里已经没有任何一条要求这么做。

开站会一定要站着吗？

不用。站着只是一个让会议不舒服到必须保持简短的小手段，《Scrum 指南》从来没有要求过它。坚持要求站着，还会把所有没法舒服站立的人排除在外，而且对远程团队毫无作用。改用一个所有人都看得见的计时器吧，它能做同样的事，还不用演。

管理者应该参加每日站会吗？

只有当他在看板上有工作时才参加。《Scrum 指南》把每日 Scrum 定位为开发人员的事件，而一位管理者以观众身份出席的那一刻，这场会就悄悄变成了讲给他听的状态汇报。如果你作为管理者需要可见性，去读看板，或者要一份每周摘要。

异步站会比实时站会更好吗？

当团队跨越的时区超过几个小时、工作之间是松耦合的，或者保护专注时间比即时性更重要时，异步站会胜出。当大家在改同一批文件、团队还很新，或者书面更新已经没有人读的时候，实时站会胜出。