微软300人团队算过一笔账：站会1年偷走56年工时

一个被写进敏捷教材的仪式，正在成为科技公司最大的时间黑洞。

2024年，微软内部一个300人工程团队做了次测算：如果每人每天花90分钟开站会，一年下来，相当于18.8到56.3个全职员工全年啥也不干，就站着说话。这个数字不是估算，是按人头和工时硬算出来的。团队负责人把结果发在内网，帖子底下最高赞评论是："所以我们招了这么多人，其实是在给自己开会？"

站会是怎么从解药变成病的

站会的设计初衷很干净：15分钟，站着说，三句话——昨天干了啥、今天打算干啥、卡在哪了。这个模板来自2000年代初的极限编程运动，当时大部分团队连像样的项目管理工具都没有，代码提交记录分散在CVS里，需求文档在共享文件夹里发霉。

信息看不见，所以得靠人嘴说。

但"15分钟"是个理想态。微软那个团队的测算假设已经算温和：按30分钟算，一年吃掉130小时；按90分钟算，直接飙到390小时。这还没算上下文切换的成本——工程师平均需要23分钟才能重新进入深度工作状态，而站会前的15分钟和会后的15分钟，大脑基本在"待机"。

真正的成本不是会议时长，是会议前后那片被切碎的时间。

更隐蔽的问题是"日报"这个词的语义漂移。严格说，"daily"是节奏，"standup"是仪式，但实践中人们直接用"daily"指代整个会议。语言偷懒的背后，是目的感的流失：当团队不再区分"同步信息"和"解决问题"，站会就变成了轮流念稿的广播体操。

AI没杀死沟通，杀死了"手动同步"的借口

现在的工程师手里有什么？Git提交记录自动关联工单，CI/CD流水线状态实时推送，LLM（大语言模型）能在30秒内总结一个Sprint的进度偏差。信息已经从"需要被问出来"变成"已经在那里，只是需要被看见"。

站会最初解决的是可见性问题。当可见性不再是问题，强行把所有人拉进会议室同步状态，就成了对注意力的系统性浪费。

微软团队的测算有个细节很扎心：他们假设的是"会议准时开始、准时结束、没人迟到"。现实里，等那个总在开会的后端负责人上线，等产品经理把需求讲清楚，等有人去叫那个戴着降噪耳机的算法工程师——90分钟的会，拖成两小时是常态。

AI没有改变团队需要协调这件事。它改变的是"协调必须通过同步会议完成"这个前提。

那些还在开站会的团队，到底在怕什么

取消站会不等于取消沟通。微软团队给出的替代方案很朴素：把状态更新异步化，用AI摘要替代人工汇报，只在真正需要实时讨论时才拉会。他们试点了三个月，工程师的"深度工作时段"增加了27%，而阻塞问题的平均解决时间反而缩短了——因为问题被记录在工单系统里，而不是淹没在某人的"昨天我遇到个事"里。

但阻力不在工具层面。

一位在三家大厂带过团队的技术负责人跟我说，站会最大的隐形功能是"让管理者感到掌控感"。哪怕每个人都在念已经写在系统里的内容，只要看到全员到齐、依次发言，管理者就觉得"团队在运转"。这是一种仪式性的安全感，和实际的信息流动效率无关。

当会议的价值从"解决问题"滑向"证明问题在被关注"，它就变成了组织版的安慰剂。

更微妙的阻力来自工程师自身。有人担心取消站会等于减少曝光机会，影响绩效评估；有人习惯了被结构化的一天，突然的自由反而带来焦虑。这些都不是技术问题，是组织信任和习惯的问题。

站会该死吗？看你能不能回答这个问题

微软团队最后没一刀切取消站会。他们换了个问法：如果这场会必须存在，它解决的是什么异步工具解决不了的事？

答案通常很具体：两个模块的接口对不上，需要当场画图；一个技术决策涉及三个团队，需要实时对齐优先级；某个工程师的情绪状态不对，需要面对面感知。这些场景值得开会，甚至值得开长会。但"轮流念一遍Jira状态"不值得。

他们的新规则是：站会保留，但默认取消，需要开的时候由阻塞方发起，15分钟硬截止，站着开，解决完就散。试点半年后，会议频次从每天一次降到每周两次，工程师满意度上升，项目交付周期没变。

这个模式后来被写进微软内部的工程实践手册，标题叫《从仪式到工具：重构同步沟通》。

站会不是原罪，把站会当成信仰才是。当信息流动的方式已经变了，坚持旧仪式就像在高速公路上赶马车——马很累，路很宽，但速度是错的。

你们团队现在每天站会多久？最近一次会上，有人说了系统里查不到的新信息吗？