怎么开一个不浪费人的技术会议

软件团队里，会议很容易越开越多。

需求评审、技术评审、站会、周会、复盘会、临时对齐会。日历看起来很充实，群里也一直有人说“拉个会聊一下”。

但很多人心里其实清楚：有些会开完以后，问题并没有变清楚，只是大家一起把时间花掉了。

技术会议尤其如此。

我现在判断一个技术会议有没有价值，不太看它开了多久，也不看参加的人多不多。

我会看会议结束以后，有没有少掉一个不确定性。

如果开完会，大家只是把各自的立场又讲了一遍，纪要里写着“后续继续跟进”，那这个会大概率没有解决问题。

真正有用的会，哪怕只有二十分钟，也应该让团队知道下一步谁做什么、风险在哪里、什么时候再看结果。

一、不是所有问题都需要开会

有些问题适合开会。

比如方案有明显分歧，涉及多个模块，风险需要一起判断，或者需要当场做决策。

但有些问题不适合。

比如只是同步一个接口字段，说明一个简单规则，确认一个时间点。这些用文档、评论、群消息可能更快。

我见过一些会，五六个人坐在一起，讨论的其实是一个字段叫什么。最后半小时过去了，大家都累。

开会之前可以先问一句：这件事需要大家同时在线讨论吗？

如果不需要，就不要开。

二、会议要从问题开始，不要从流程开始

很多会议一开始就进入流程。

“我们今天评审一下方案。”

然后从第一页 PPT 开始讲，讲背景、讲架构、讲模块、讲数据流。讲完以后，大家有点困，也不知道该反馈什么。

我更喜欢会议一开始先把问题说出来。

比如：

今天主要定三件事：
1. 订单状态是否要拆成独立状态机。
2. 库存扣减失败后是否允许重试。
3. 这版上线是否包含历史数据迁移。

问题清楚了，参会的人才知道自己要贡献什么。

否则会议很容易变成一个人讲，其他人礼貌地点头。

三、参会人越多，不代表越稳

很多人开会喜欢多拉几个人，觉得这样比较保险。

但会议人数越多，成本越高，讨论也越容易发散。

技术会议最好只叫和决策真正相关的人。

需要拍板的人要在，需要提供关键信息的人要在，需要承担后续动作的人要在。

只是“可能了解一下”的人，可以看会议纪要，不一定要坐完整场。

保护团队的专注时间，也是技术负责人该做的事。

四、没有结论的会议，要写清楚卡在哪里

不是每个会议都能当场定结果。

有时信息不够，有时风险没评估完，有时需要业务确认。这都正常。

但会议不能以“再看看”结束。

如果没有结论，至少要写清楚：

现在卡在哪个问题。
谁去补充信息。
什么时候回来继续定。
在结论出来前，哪些开发不能开始。

否则会议开完以后，大家会各自按自己的理解往前走。

这比不开会还危险。

五、会议纪要不是流水账

很多会议纪要写得像聊天记录。

谁说了什么，谁补充了什么，谁提出一个疑问。看起来很完整，但真正有用的信息反而被埋住了。

我更喜欢会议纪要只保留三类东西：

结论：已经定下来的事情。
待确认：还没定、但会影响后续工作的事情。
动作项：谁在什么时候完成什么。

这三类信息能让没参会的人快速知道状态，也能让后续追踪有依据。

会议纪要不是为了证明开过会，而是为了让事情继续往前走。

六、小结

一个不浪费人的技术会议，不在于开得多正式。

它应该有明确的问题，必要的人，能落地的结论，以及会后的动作。

如果一个会开完以后，大家只是更累了，问题没有更清楚，责任没有更明确，那它就不是协作，而是集体消耗。

技术负责人要敢于少开会，也要把必须开的会开得更像解决问题。

本系列：