最近有开始纠结开周会这件事了，每每在会议室里看着大家轮流把我几乎知道每个人在做什么的事情再说一遍，就浑身难受。
作为一个效率至上的人，实在是无法接受这种事情出现。
但是「我知道」不等于「大家对齐」。真正的痛点是：
所以问题就变成了：周会到底有没有必要？如果有，它到底要产出什么？
于是在和 GPT 探讨了这个问题之后，决定调整成「无状态周会」的模式。
所谓的「无状态周会」，即：
并且我还纠结了这些内容让所有人写在同一张表上还是单独私我给我更好。 从管理学和工程实践的角度来拆解，各自单独写的优点是：
但是缺点也很明显：
如果共同写在同一张表上，优点就是：
但是缺点反而变成了：
综合考量来看，第一种方式比较适合团队初创期，团队成员心理暗去哪干不足且敏感问题较多的时候；第二种方式就更适用于团队稳定，工程协作密集且有跨端依赖的情况，这种情况就是我们现在所处的位置。
不过为了保护好部分同学，也额外告知大家，有敏感问题可以找我 1:1，保留私密通道，维护大家的心理安全。
最终，pre-read 的表格设计如下：
| 成员 | 本周 Top-3 输出 | 阻塞 / 依赖 | 待决策议题 | 指标红/黄项 | 需要帮助 | 状态 |
|---|---|---|---|---|---|---|
| Mario | 25.3.21 Patch 提交 / AppStore 审核跟进 / 热修回归完成 | 等待 BE 接口上线 | 是否砍掉 debug log 优化？ | Crash-free 下降到 98.5% | 需要 QA 支持回归 | 🟢 Ongoing |
| Allen | Feature Flag 收尾 / Android 电量回归 / iOS 冷启动优化 | 依赖 QA 回归 slot | 是否推迟 iOS 冷启动优化到下个版本？ | 冷启动 P95 未达标 | 无 | 🟡 Risk |
| … | … | … | … | … | … | … |
把这个方案拆开来看，就会发现它踩中了几条“老而硬”的原则：
当然，一切还需要运行一段时间才能有新的体会和收获，拭目以待。
重新思考周会这件事，本质不是换模板，而是把德鲁克的管理观放进一支工程队的“日常操作系统”里：时间的敬畏、成果的执念、决策的纪律、学习的循环。当周会只剩 10-20 分钟、只聊三件事、每周有回看，我们可能就会发现团队的注意力正在向“真正重要的那 20%”聚拢。