每日站会议程模板（工程师真正会用的那种）
大多数站会模板的问题所在
大多数站会模板是为那些其实并没有在认真开站会的团队设计的。每人三个问题，五个人，如果团队放任其膨胀，15 分钟就会变成一场规划会。下面这份模板只为一件事而优化：把站会控制在 10 分钟以内，同时确保关键信息浮现并被记录下来。这些提问是刻意收窄的。轮流发言之后的各个环节负责处理其余的一切。
议程（复制粘贴即可）
时长： 最多 10 分钟
形式： 同步进行，每人发言一次
对每位团队成员（每人 90 秒）：
- 上次站会以来完成的事 — 已交付或已合并，而非进行中
- 今天计划做的事 — 你打算收尾的内容，而非空想式的冲刺工作
- 阻塞项 — 指明负责人；"在等设计评审"只有在有人负责去解除阻塞时才算数
轮流发言之后（剩余时间）：
- 需要拍板的决策 — 任何当下就需要定夺的事项；如果超过 2 分钟，就另约一场会议
- 公告 — 每条一句话，站会期间不展开讨论
待议事项：当轮流发言中冒出一个并不需要全体参与的话题时，把它记下来，会后或异步处理。待议事项的讨论——通常是 2-3 人而非全团队——往往比站会本身更有价值。
大多数站会模板搞错的地方
排名靠前的站会模板会落入两种失败模式。
那个最简骨架（"你做了什么？你要做什么？有阻塞吗？"）本来没问题，直到团队开始把阻塞项当作可选项来对待。没人会写下"在等安全评审"，因为写了也不会发生任何事。依赖关系就此丢失，直到下周碰巧有人问起才被解除。
而过度堆砌的版本会加上 8-12 个提问外加一次团队健康度检查。那会把站会变成一场部门例会。工程师们在前两位发言者之后就不再听了。
这两个版本共享同一个根本问题：它们把站会框定为一次汇报活动。站会是一次对齐活动。汇报产出信息；对齐产出行动。这个区别关系到你如何为各提问设定时限，以及轮流发言结束之后会发生什么。
模板忽略的第二件事，是通话结束后这些信息的去向。即便是运作良好的站会，也会产生没被跟踪的阻塞项、没人记下的决策，以及没有负责人的行动项。
为什么站会回顾纪要总是崩掉
轮值记录员的做法几周内就会失效。轮到谁,谁就忙得焦头烂额，略过细节，发一段含糊的东西，没人会看。团队先是不再信任这些笔记，然后不再阅读，最后这些笔记不再有任何用途。
异步优先的站会——在通话前把你的更新发到 Slack——解决了出勤问题，却丢掉了现场轮流发言带来的那份担责感。人们当天晚些时候还是会问"我们关于 X 到底定了什么？"。
隐性成本累积得很快。想了解丢失的站会上下文在一个季度里会让团队付出多少代价，参见会议税。
Pavleur 如何处理回顾纪要
按这份议程开站会，同时打开 Pavleur。通话结束时，报告会自动生成——没有记录员，也没有站会后那 5 分钟的收尾整理。回顾纪要会记下每个人的完成/计划/阻塞，提取所做的决策，并按会议中点名的方式列出带负责人的行动项。
纯音频工具遗漏的部分：如果有人在站会中途调出 PR 面板、Jira 看板或部署图表，Pavleur 会把它捕捉下来并连同上下文写进报告。像 Otter 或 Fireflies 这样的工具给你的是文字；而屏幕上曾显示过什么的截图记录并不存在。任何错过站会的人都能读到完整报告，而不必再去问发生了什么。如果你正就这个维度对比工具，对比页面涵盖了这些差异。
落实时间限制
"每人 90 秒"的纪律最常在工程经理开始在轮流发言中途回答问题时崩溃。要训练出这样的本能：说"这个我们会后再谈"，并把它写进待议事项。
如果站会持续超过 10 分钟，原因通常是以下之一：人太多（把站会拆开）、冲刺规划的议程项渗了进来，或者某个反复出现的讨论话题需要它自己的固定会议。要修正结构性成因，而不只是治标。