都说程序员讨厌开会。我不知道他们是否都这样做，但我真的不喜欢它。《八卦》的Fenng曾撰文称，在阿里的最后两年，他负责数据库团队的时候，周会太多，让他觉得受不了。程序员以讨厌写文档而臭名昭著，但他们讨厌会议就像讨厌写文档一样。以上推论来自漫画《神秘的程序员》，如下：有什么会议？当我准备写这个话题的时候，我反思了自己过去参加过哪些会议，发现有时莫名其妙地参加了一些完全没有意义的会议。下面我们就来看看一般程序员都会遇到哪些会议。需求会议一般由产品或项目经理召集，组织参与项目的程序员讨论需求，确定进度。这种会议的问题在于，程序员在会议上第一次知道需求，陷入对需求细节的无休止讨论中。更好的方法是让程序员提前详细了解需求。会议上只需要敲定时间表，让相互合作和依赖的程序员达成一致，形成承诺即可。讨论会的场景范围很广，比如项目过程中同组的程序员讨论设计或者实现，或者和其他项目伙伴讨论等等。这种会议容易出现的问题是一堆人们暂时被拉进会议，然后陷入混乱的自由讨论中，失去了焦点。还有一种讨论会，叫做头脑风暴会议，也很容易带一堆人来开会，开始头脑风暴。现在我很遗憾地意识到这是效率最低但最有效的方法。头脑风暴会议要求与会者提前准备、收集或阅读需要解决的问题的材料。不同的人从不同的角度提出自己的观点或计划，然后在会议上列出所有的观点和计划，然后动脑筋碰撞连接，看看能不能想出一些新的想法或方案来有效解决问题问题。周会一般来说，一个部门或小组每周都会召开一次例会，而例会很容易被视为例行工作而不受重视。定期会议应该有固定的时间和议程，并且是一群定期一起工作并且相互了解的人。仅仅因为参加例会的人都在同一个部门并不意味着他们都在同一个项目或事情上进行协作。因此，例会是一个通过了解自己的工作来了解整个部门或小组工作进展情况的机会，而不是每周固定的休闲时间。当然，我们也可以在每周的例会中留出一段自由讨论的时间，畅所欲言，增加工作之外的交流。除了每周例会外，一些实施敏捷方法的团队还举行每日站会。每日站会的大致内容是：你昨天做了什么？网络，而不是会议，让经理们了解情况。每日站会不是一个人站着聊自己工作的团队，因为发现彼此不关心对方工作内容的人站着开这个站会。这次站会的意义何在？分享会部门、公司或行业内将举办各种不同规模的分享会。想想你为什么要参加分享会？一般来说，我只有两个原因。对分享的内容感兴趣，这应该是大多数人参加会议的原因。另外，即使我已经熟悉了分享的内容，参加会议的原因一般也是对分享者感兴趣，想通过这次分享来认识分享者。另一种情况可能是参加一些完全没有面子的分享会，嗯，尽量避免这种情况。即席会议总会出现这样的情况。突然有人过来约你去参加一个临时会议，然后你就一脸茫然地去了。这种会面，似乎是身不由己，难以避免。大多数这些会议都是计划外的任务驱动会议。英特尔前CEO安迪格鲁夫说：在现实中，有20%的案例必须通过面向任务的会议来解决。但是，如果管理人员将超过25%的时间花在紧急任务导向会议上，则该组织存在问题。这种会议随时召开，根据具体情况作出决定。如果这种临时的、紧急的、任务驱动的会议太多了，问题肯定出在平时的工作上。总结会可能是项目上线或产品发布后的总结会，也可能是线上失败后的总结会。我以前开的很多总结会都变成了领导总结会。你对这种会议有什么好的想法吗？参加会议反思以上我参加过的各种类型的会议，我得出了一个以后参加的原则：如果我没有潜力在会议上发言，我就不需要参加。发言可能表明你积极参与会议，需要通过发言有所收获（建议、意见、询问、交流）。但是并不是说每次开会都要发言，只是说有这种可能。比如在参加分享会的时候，你可能想交流，问明白一些事情，但是在分享的过程中你可能已经有了答案，就没必要再开口问了。有时候你会收到一些莫名其妙的会议邀请邮件，只是因为收件人里有你的名字，当会议自动提醒弹出时，你会不自觉地跑去参加会议。其实在开会的时候，我发现自己似乎没什么事可做，但是开到一半很难离开，只好自己玩手机。这不是熟悉的场景吗？即使临时会面看起来完全被动，你也可以问告密者为什么需要你去？很可能告密者会告诉你，Boss（老板或上级）正在找你，他也不知道原因？好吧，这种情况必须过去，这里的问题不是你，而是你的老板。Boss可能只是问你一些细节，也可能需要征求你的意见。总之，完全没有准备的临时会议不利于效率和效果的提高。一位正在埋头编程的程序员突然接到通知召开临时会议。程序员也可能会卡在之前codingjob的细节上，无法切换出来，导致后续的adhoc沟通和讨论效率低下。所以，如果不是特别紧急，尽量把各种会议安排在一天的开始或者结束之前，留出一整段集中的时间给程序员进入和退出状态。您可能没有想过组织会议。一些程序员将会议设计为编程。模式现在后端分布式领域流行微服务架构，所以我也提倡微会议，一场会议专注于一件事，除了分享会，不要召集太多人开会。人多了可能会更乱更没效率，效率的损失也很大。在设计程序时，需要仔细选择组件，这样才能像编程一样设计会议，消除冗余资源消耗，保持简单。仔细分析每一个潜在参会者对这次会议是否有价值，我们不需要多余的参会者玩手机。如果您在会议中发现一个额外的人拿着电话，那不是别人的错，而是您的错。实现在正式编码之前，我们已经在脑海中或纸上做了一个设计，我们只是用代码表达出来。因此，在会议正式开始之前，请确保参会人员做好充分准备，而不是仅仅在会议桌上思考需要解决哪些问题？会议的进程也需要控制好节奏，突出主题，避免发散和偏差。代码在实现的时候，总会有一些超出原设计没有考虑到的实际问题。一些新的想法可能会在会议期间突然出现。与编码不同的是，如果你发现这些新情况很有价值，但短时间内无法讨论清楚，你可以先记录下来，放到下次会议的议程上，以免本次会议发散过多，导致会议拖延，话题分散，没有结论。……把开会分析成程序问题后，发现开会其实没那么烦人。
