我发现，大部分会议都是无效会议，同时浪费自己和别人的生命。如果实在要开会，我建议控制在30分钟以内。
网飞的CEO里德说过，没有一件事在30分钟内说不清楚。美国经济学家高伯瑞也讽刺说，如果你不想真正做事的时候，就去开会吧。
虽然说的有点过度，但是我认为要高效开好会，是有一些策略的可以学习的。
会议控制在30分钟内
长期实践下来，我有一个习惯，在组织会议只定30分钟（绝大部分情况）。
在我的职业生涯里面，我对那种超过一个小时甚至两个小时的会议生恶痛绝。经过我的总结，发现大部分超过半个小时的会议，往往都是冗长低效的。
开着开着，下笔千言，离题万里。
所以我大部分定的日程都是30分钟，我觉得30分钟就足够可以把任何问题讲的非常的清晰和透彻，而且30分钟的紧凑感，也避免了大量无效的东拉西扯。
当然技术分享类、横向沟通类的日程除外。
很多人是个话痨，聊着聊着就会把整个会议的目的发散到三界五行之外，甚至开始唠嗑人生了。
所以对会议的主持人来说，一定要想方设法控制时间，把发散者的思维拉回正道。
30分钟，利用金字塔原则，什么问题都可以说清楚了。说不清楚的，给300分钟也说不完。
会议要聚焦具体的问题
程序员大部分要讨论的问题往往都是一些具体的点，而不是天马行空的讨论。大部分时候不需要拉会来专门讨论一些大的方向，这些问题一两个会也根本讲不清楚，而往往需要拉会沟通的就是一些比较小的点。
比如技术方案的评审，比如产品方案的沟通，比如对问题的同步，比如一次压测任务，比如一次测试计划沟通。
如果一个任务确实很大，可以拆解成多个部分，分小会的方式执行，每个会关键的5个以内人参与，而不是一个会议2个小时，参与者20个。
开个会议之前一定要想会议的目的。如果能不拉会就不拉会，如果需要拉会，一定要想清楚会议上要讲的内容是什么，要达成的目的是什么。
有些问题，主持者在会议前就应该私下找人对清楚，而不是在会议日程中讨论。
既然要拉会，就需要事先准备会议主题和会议文档。特别对于程序员来说，我们80%以上的会议都是在做技术方案的评审，所以在开会之前一定会准备好详细技术方案和待讨论的问题列表。
方案准备完成后，提前发出来，让参会者提前阅读。实际上这里面已经是一个异步沟通的过程，对该方感兴趣的人事先就会先阅读方案，并且对问题做评论或者记录。
主持人在会议中的时候往往只要过一些评论就可以了，针对里面的核心问题做重点回答和讨论。如果有会议中不确定的地方就记录下来，线下去确认，不需要进一步深入没有结果的讨论或者猜测。
在会议中可以针对一些复杂问题，难点问题，有争议的问题做适当讨论，但不应该过度发散，真有一些难题，可以小范围深入讨论。
很多冗长的会议里，他们讨论很嗨的地方，我要不就完全听不懂，要不就完全跟我无关，但是动则浪费我半个小时一个小时。经常为了五分钟，浪费一小时。
会议参与人员不应该过多
之前很多人拉会的时候喜欢面面俱到，生怕少了谁，但凡跟这个问题有一点关联的人都想把他拉上，甚至都想把保洁和门卫也拉上。
经常一个很小的主题，满满当当，会议室挤了二三十个人。知道的是开会，不知道的还以为老板要现场发钱。
这种方式，导致会议的时候就很容易浪费很多人的时间，大部分时间，这个会议往往只需要某个同学确认一下或者确认某个任务项。但是由于把他拉到会上了，他不得不跟进整个会议。
他也不想拒绝了这个会，否则搞得大家以为他要跑路了。所以，大家每个会都事必躬亲，用参会来表演自己的投入度。
奔着高效原则，所以在拉会议之前一定要确认没有这个人会议是不是完全开不成？没有这个人会不会缺少最关键的点评？没有这个人会不会缺少最关键的影响方？
如果没有，不用拉，不用浪费别人时间。一两句可以搞定的，就别浪费别人一个小时。
比如，技术方的评审，我往往只需要精简到个位数的人，超过十个人的技术方案评审，第十一个人绝对是来酱油的。
会议一定要有结论
既然开会就占用了别人宝贵的时间。既然开会就要对别人的参与负责，也要对自己负责。
鸡毛蒜皮的事情就拉会，还不如去找角落去拉二胡。
所以既然拉了会，既然开了会，就要一定要达成会议的结论。比如说方案通过还是不通过，要优化哪些点，如果是通知性质，是否确认对方已经知晓？
如果暂时没有确定的结论，那是否有对应的action，如果需要确认一些任务项，谁来确认，什么时候确认完。
如果确认方案流产，那么是达成一致，大家都不做，还是在下一次继续开会，如果是下一次开会，什么时候开始？
简单来说，一个会议结束之后必须要有点什么东西，才不会浪费这次会议的时间。有时候确定没有结果也是一种结果，但必须是一种明确的确认。
所以，最后给自己提个醒，每个人的时间无比宝贵，与其浪费时间在开会，不如坐着喝喝咖啡发发呆，或者多做事，也好过把时间浪费在毫无意义的会议上。
更多精彩内容，关注公众号：ali老蒋，或点击加我好友深度沟通：ali老蒋 - java开发者
