如何让工程师远离会议地狱

为什么会议会让人感觉像“地狱”

• 许多人认为，与写代码相比，会议的影响很低；很多时候没有人创造出可见的价值。
• 上下文切换是一个主要痛点；零散分布的 1 小时会议会毁掉整个原本高效的“心流”工作日。
• Zoom 让“以防万一”式地随手拉人变得极其容易，从而膨胀与会人数和时间成本。

什么让会议有效，什么让会议无用

• 强烈支持：清晰的议程、预期结果、会前阅读材料、主持人、记录员、发布会议纪要，以及明确的行动项和负责人。
• 如果没有这些，那“只是聊天”，应改为异步或 1:1。
• 适合开会的场景：真正不确定的话题、跨团队协调、需要相关方把未知问题讨论清楚的真实决策。
• 不适合开会的场景：状态更新、一起读文档、含糊的“讨论”会议，或把决策与责任从个人推给集体。

工程师用来保护时间的策略

• 拒绝或离开没有议程、需求不明确、或自己无法获得/提供价值的会议。
• 执行“两只脚法则”：如果你不能贡献，就走出去。
• 在日历上预留做事时间；有时会采用“无会议”时段，不过这反而可能吸引更多会议。
• 让组织者说明为什么你必须参加并发送议程；有些人会通过选择性参与来建立一种“神秘感”。

异步沟通 vs 会议

• 许多人认为，大多数会议都可以用邮件或聊天替代，尤其是决策、状态和信息共享。
• 反方观点：糟糕的邮件管理习惯（巨大未读数量、低回复率）会迫使人们用会议作为“保险”，以确保拿到答案。
• 有人建议使用过滤器和更好的邮件纪律，但也认为这需要持续投入；也有人认为真正的解决办法是从源头减少噪音。

站会、敏捷仪式和会议数量

• 常见抱怨：每日站会、冗长的“仪式化” Scrum 活动，以及价值很低且很快跑题的 PI 规划。
• 有反馈称个人贡献者每周要开 12–16 小时会议，几乎没有连续编码时间。
• 有些团队靠最少流程也能运转良好（每周一次短会加上临时讨论）；另一些团队则依赖简短的每日同步，并且效果不错。

结对编程之争

• 有些人把计划好的结对视为“一场很长的会议”。
• 也有人强烈反对，认为好的结对是积极的共同编码，在合适的文化下效率很高，尤其适合学习和知识共享。
• 折中观点：结对应“按需”使用；全职结对会让人疲惫，而且必须证明在一个任务上投入双倍人力是合理的。

管理、激励与职业影响

• 一些人把责任归咎于激励机制：有些管理者通过制造会议和活动来获得曝光度和重要感。
• 也有人指出，会议确实是管理工作的一部分，用于协调和对齐，尤其是在复杂的实体工程项目中。
• 极端的反会议立场可能适得其反：如果你既拒绝会议，也不参与异步协作，会被视为对职业发展不利。
• 对于“会议是职业成长的唯一方式”这一说法存在分歧；有些组织仍然把交付放在首位。