据说程序员都讨厌开会，不知道是不是都，但我确实也不喜欢。「小道消息」的 Fenng 曾经写过在阿里的后两年，他负责数据库团队时，每周会议也是多到让其感觉无法忍受。程序员讨厌写文档是出了名的，但讨厌开会的程度是讨厌写文档的立方，以上推论来自漫画《神秘的程序员》，如下：

有哪些会？

　　当我打算写这个主题时，反思了下过去都参加过哪些会议，发现有时会莫名其妙的就参加了一些完全无意义的会议。下面我们先看看一般程序员都会碰到哪些会议。

　　需求会

　　这类会议一般是产品或项目经理召集，组织参与项目的程序员一起讨论需求并确定排期。这类会议容易出的问题是，程序员到了会上才第一次知道需求，并陷入到需求细节的无休止讨论中。更好的方式是提前让程序员详细了解需求，会上只需敲定排期并让互相有协作依赖的程序员之间达成一致和形成承诺。

　　讨论会

　　这类会议的场景比较广泛，比如：项目进行过程中同组程序员之间就设计或实现的讨论，或与其他组项目合作人之间的讨论等等。这类会议容易出现的问题是临时把一堆人拉到会上，然后陷入混乱的自由讨论，失去焦点。

　　还有一类讨论会叫头脑风暴会，也是容易把一堆人拉到会上，开动头脑风暴。如今遗憾的领悟到这是最没效率也没效果的方式。头脑风暴会需要就待解决的问题让参与人员提前准备，搜集或阅读材料，不同人从不同角度各自提出自己的观点或方案，然后到了会上将所有观点和方案列出来，再开动头脑，碰撞连接一下，看看能不能风暴出一些新的观点或方案去有效解决问题。

　　周例会

　　一般来说一个部门或小组都会每周开个例会，例会容易被当作日常的例行工作而不被重视。例会应该有固定的时间和议程，而且例会是一群经常一起工作并熟悉的人开会。虽然开例会的人都在同一个部门，但并不意味着他们都会相互合作完成同一个项目或事情。所以，例会是通过了解各自工作来完成了解整个部门或小组工作进展的机会，而不是每周固定的休闲时光。当然我们也可以在每周的例会留出一段自由讨论时间，可以畅所欲言，增加工作之外交流。

　　除了周例会，有些实施敏捷方法的团队也会开每日站立会，每日站立会的一般内容是：

　　·昨天干了什么

　　·今天计划干什么

　　·遇到了什么障碍

　　每日站立会议的主要目的是让团队成员互相交流互通工作情况，而不是为了让经理们了解情况而召开的会议。每日站立会不是一个团队的人站一圈各自说下工作情况，因为曾经发现彼此并不关心对方工作内容的人站一圈开这个站立会，其意义何在？

　　分享会

　　部门内、公司内或行业内都会有各类不同规模分享会，想清楚你为什么要去参加一个分享会？一般来说我只有两个原因，我对分享的内容感兴趣，这应该是大部分人参会的原因。另一个，即使分享内容我已经很熟悉，那么参会的原因一般就是对分享人感兴趣，想要去通过这个分享了解分享人。

　　还有一种情况可能是碍于面子参加一些完全没兴趣的分享会，恩，这种还是尽量规避吧。

　　临时会

　　总会碰到这种情况，突然有个人过来叫你临时去参加个会，然后你就一脸懵逼的去了。这种会似乎属于身不由己，不好规避，这类会议多是非计划性的任务驱动型会议。英特尔前 CEO 安迪·格鲁夫说过：

　　在现实中，有 20% 的情况还得靠任务导向会议来解决。但如果经理人将超过 25% 的时间用在应急的任务导向会议上，这个组织就一定有了毛病。

　　这种类型的会议随时召开，而且会针对具体情况产生决策，若这种临时紧急的任务驱动会议太多了，那问题肯定出在平时的工作中。

　　总结会

　　可能是项目上线或产品发布后的总结会，也可能是线上故障后的经验教训总结会。我以前开过的很多总结会都变成了领导的总结会，关于这类会大家有什么好想法吗？

参加会议

　　反思了上面参加过的各种类型会议，然后我得出了一个以后参会的原则：若我没有在会议上发言的潜在可能，就不需要参加。

　　发言的可能表明你参会是存在主动因素的，需要通过发言（建议、意见、询问、交流）去取得收获。但并不意味着每次参会都需要发言，只是说存在这种可能。比如，参加一个分享会，可能你是想去交流和询问了解一些东西，但可能在分享的过程中你已经有了答案，就没必要发言询问了。

　　有时你会收到一些莫名的会议邀请邮件，只是因为收件人中有你的名字，就会不自觉地在会议自动提醒弹出时跑去参会。其实在会上发现好像和自己又没多大关系，但进行到一半又不好离场，只好自顾自的玩起了手机，是不是很熟悉的场景？

　　即使一个临时会，看似完全被动，也可以问问通知人为什么需要你去？很可能通知人会告诉你是 Boss（老板或上司）找你，他也不知道原因？好吧，这种情况只好去了，这里的问题不在你，而在你的 Boss 身上。Boss 可能只是找你咨询一些细节情况，也可能需要咨询你的意见。总之一种完全没准备的临时会议是不利于效率和效果的。

　　一个正在埋头编程的程序员，突然被通知开个临时会议，程序员还可能陷在前一份编码工作的细节中没切换出来，导致后续的临时沟通讨论都比较低效。所以，若不是特别紧急，尽可能把各种会议安排在一天的开始或结束前，为程序员留出整段的集中时间来进入状态和脱离状态。

组织会议

　　你可能没想过，有些程序员把开会当作编程一样来设计。

　　模式

　　现在后端分布式领域流行微服务架构，所以我也主张微会议，一个会议聚焦一件事，除了分享会，不要召集太多人来参会。人越多可能越混乱和无效，效率损失也很大。

　　架构

　　设计程序时需要仔细选择组件，所以可以像编程一样设计会议，剔除多余的资源消耗，保持简洁。仔细分析每个潜在的参会人是否对本次会议有价值，我们不需要一个冗余的玩手机的参会人。如果你发现你的会议上多了一个玩手机的家伙，那不是别人的错，而是你的错误。

　　实现

　　在正式编码前，我们早已在头脑或纸上做好了设计，只是用代码将其表达出来。所以，正式开始会议前，请确保参会人都做好了准备，而不是到了会议桌前才开始想这个会议需要解决什么问题？

　　会议的过程也需要掌控节奏，集中主题，避免发散跑偏。代码实现时总会出现超出当初设计的一些现实问题没考虑到，会议中也可能突然冒出一些新想法，和编码不同，对这些新情况若发现有价值但又无法短时间讨论清楚，可以先记录下来，列入下次会议的议程，而避免本次会议过度发散，导致会议延时，主题分散，没有结论。

　　...

把开会当作一个程序问题来分析后，我发现开会其实也没那么讨厌了。