以前的周会是什么样的
如果你所在的团队也有周会，大概率会有这些画面：一个人念 Jira，另一个人看手机，后排有人在默默改代码。大家轮流报进度，形式主义地说几句「本周主要做了 xxx，下周计划 xxx」，然后就散会了。
我们组之前就是这样。最夸张的一次，一场周会开了1小时20分钟，结果所有人出来之后，问一句「今天有啥结论？」——没人能说出来。
被点名「改造周会」
某次 OKR 复盘，老板直接问我：「你觉得我们现在的周会还有意义吗？」我下意识想说「没啥意义」，但又不敢太直接，只说「信息密度有点低」。
于是这事就落在我头上了：「那你来想想怎么改吧，下个季度试一版新的。」
第一版：改成「项目看板驱动」
我的第一反应是：既然念 Jira 很无聊，那不如干脆用看板来驱动，让大家围着「卡片」说话，而不是围着「人」说话。
于是第一版改造方案是这样的：
- 周会只看「本周新增 / 未完成 / 卡住」的卡片
- 每张卡片有明确的 Owner，由 Owner 来讲
- 没有卡片的事，不在会上聊
结果还不错，会的时间从1小时缩到30分钟左右，但问题也很快暴露出来：信息更聚焦了，但很多「跨项目」的隐性问题没地方冒头。
第二版：强制纪要模版
真正改变体验的是第二版——我们给周会纪要上了模板，而且是强制执行的那种。
模板很简单，只有三块：
- 一页纸 Summary：本周最重要的三件事（不超过3条）
- 决策清单：本周在会上拍板的事情，以及 Owner / 截止时间
- 风险&阻塞：需要上升的风险、需要协调的资源
周会开始前 30 分钟，我会把上周的纪要发出来，先对一下「上周说要做的事，现在做得怎么样了」。然后再按模板补充本周的内容。
这个变化很小，但效果非常明显：大家开始意识到，周会不是「汇报进度」，而是「对齐决策」。
怎么写一份「有用」的周会纪要
下面是我们现在用了一年的纪要写法，基本稳定了：
1. Summary 不要写成流水账
一开始大家写 Summary 会写成这样：
- 完成了 A 需求开发 - 修复了 B Bug - 跟进了 C 项目 现在我们强制要求改成这种风格：
- 本周 A 需求前后端联调完成，预计下周二上线，对 D 客户的影响是：老版本接口将下线 - B 模块线上错误率从 3% 降到 0.4%，主要通过xx优化，后续还需要观察 1 周 - 新项目 C 完成技术预研，已确认用方案 X，放弃方案 Y 的原因是... 也就是说：不要只写「做了什么」，要写「为什么做」「影响是什么」。
2. 决策一定要落到人和时间
决策清单我们用的是类似这样的格式：
- 【技术选型】新项目 C 前端统一使用 React + Vite + Zustand - Owner：阿杰 - 截止时间：2024-07-20 完成脚手架搭建 - 【流程调整】线上 Bug 必须先在监控看数据，再决定是否回滚 - Owner：顾一帆 - 截止时间：本周内在团队内宣导，并更新值班手册 很多团队的会议纪要只有一句「决定采用方案 B」，但没有人跟，也没有时间点。过两周再看，根本没人记得这事是谁负责的。
3. 风险一定要写「谁需要知道」
我们在「风险&阻塞」里，后来加了一个字段：「需要通知谁」。 因为很多风险，其实是「别的团队」或者「老板」需要知道的。
- 【风险】支付改造可能影响 A 业务的结算周期 - 说明：新接口结算时间会延后 1 天 - 需要通知：运营负责人、小程序团队 最后的效果
改造周会这件事，前后大概折腾了两个月。现在的情况大致是这样：
- 周会时间从 1 小时缩到了 30 分钟以内
- 纪要每周都有，真的有人会回头看（尤其是复盘时）
- 新人加入团队，翻几周纪要，大致能知道最近发生了什么
它没有变成什么「高效会议模板」，但至少不再是大家眼里的时间黑洞了。
给也想优化周会的你
如果你也想改造团队周会，我的建议是：
- 先不要碰形式，先从「纪要怎么写」入手
- 想清楚周会是为谁开的：老板？跨部门？还是小组内部对齐？
- 把「决策」和「闲聊」分开，能线下解决的就别放会上
- 不要指望一周就见效，给自己留两个月的试错期
周会本身不是问题，真正的问题是：我们到底想用这一小时换来什么？ 想明白这个问题，后面怎么改就顺多了。
评论区