作为互联网民工一枚，平时的主要工作总有一项是无法避免的。那就是参与大大小小的各种会议，需求评审会、头脑风暴会、即兴讨论会等。正常来说，万物存在即合理，会议作为一种交流的形式载体，肯定有着它独特的优势，才得以一直流传至今。但是为什么现在逐渐有了一种”天下苦会议久矣“的趋势呢？一提到开会就脑壳疼，相信这应该不是我一个人的痛苦。想到接下来几年还要一直忍受这种折磨，我就头皮发麻。为了自救，必须要好好想一想怎么优化会议的体验了！
为了优化会议的体验，首先就要先分析清楚会议这种交流方式，有怎样的优势和不足呢？
一个有效率的会议可以节省大量的沟通成本，把相关信息同步给参会各方，并即时得到反馈，得出最终结果。但它的缺陷也很明显，很容易就会造成大家时间的浪费。为了保证会议的效果，我认为可以从两个身份去考虑：会议发起方和会议参与方。这里主要讲的是作为会议发起方时，如何保证会议的效率。
作为会议发起方，主要注意一下几点：①明确会议的目的。②确定前期准备是否充分。③根据会议目的确定参会的人员、会议的流程。④保证会议按既定的流程进行。
①明确会议的目的。这一步非常重要，我遇到过非常多次需求澄清会聊着聊着变成了需求讨论会。其实根本原因就是会议的目的不明确。那我们作为发起方的话，首先要明确好我们想开的这个会，目的是什么。把需求跟开发讲一下？不，这个不是目的。目的应该是一个结果，而不是一个行为描述。我做了这件事情之后希望能达到什么效果。比如：我开需求澄清会的目的是，让开发充分理解需求背景和产品方案，并及时反馈一些技术可行性上的问题。
②确定前期准备是否充分。不知道大家有没有经历过，需求澄清会上争议太多导致会议被打回延期重启，的情况。我之前参与的一个同事发起的澄清会就遇到过。过早的让开发介入导致需求经不起拷问，自圆其说都难。既浪费自己时间又浪费开发时间。所以针对你定下的会议目的，一定要足够确认你的前期准备已经足够充分。比如：会议目的如果是想讨论需求的解决方案，那需求的合理性是否已经确认了？如果目的是想做产品方案的技术澄清，那需求方案是否已经完整闭环，无较大漏洞？
③根据会议目的确定参会的人员、会议的流程。正如之前分析的会议的缺点，参会人员越多越杂，越容易产生信息噪音，也越容易造成时间的浪费。所以一定要确保会议的参会人员都是有必要的。比如：如果目的是需求澄清，那其实只需要叫上需求负责人和相关开发同事即可。如果目的是需求分析，那其实只需要叫上需求负责人和相关业务同事即可。
然后根据目的和需要确定会议的流程，并定义每个流程的预计时间。比如：需求澄清会的流程就是：需求背景讲解（10min）→产品方案讲解（30min）→开发反馈技术问题（10min）→确认会议是否达成效果，未达成的话下次的计划（5min）。
④保证会议按既定的流程进行。制定了会议的流程之后，那就需要保证会议的实际进行过程是尽可能按我们预期的来进行。这种情况一般需要一个有一定信服能力的人作为主持人，可以控制场面，把会议的发展方向保持在正规上。主持人要负责的工作主要是：控制会议每个流程的时间、控制会议内容与流程/目的尽可能一致，避免跑题。
总结出以上规律后，个人也在日常工作中尝试了一下。效果还不错，虽然不可避免地还是会有一些意外情况发生，但是整体来说是在掌控之中了。
