会议是职场中常见的沟通方法。凡是方法都有其应用场景，常见的会议应用场景包括各层级组织的例会、评审会、讨论会、奖惩会、复盘等。

其中，例会根据各层级不同会议内容略有差异，但大体以参会人员汇总同步各项事务进度、需协作事项、以及明确下阶段工作目标为主。

评审会则一般用来对某种对象进行评审，可能是需求、设计稿或建设方案等，最终需形成对评审对象的评审意见。

讨论会一般会围绕某项主题进行头脑风暴，以汇集众智为核心。

奖惩会通常宣读奖惩依据及说明，不过奖励可对当事人进行公开表扬赞誉以激励与会者、惩戒一般采用模糊化公示以警示为主。

复盘会议一般围绕项目或事项进行评估，从成本与收获、优劣分析、过程资产沉淀、经验教训总结等角度展开。

不管哪种应用场景下的会议，均需要经历会前、会中、会后三个阶段，对应的活动也依次会议准备、通知、记录、跟踪，会议属性也必然包括会议主题、时间、参会人员、会议形式。

理论难免枯燥，用起来才是硬道理。以下需求评审会议为例分别阐述会前、会中、会后的落地方法。

（1）会前阶段：

作为会议组织者的项目：

1：准备需求材料，可以是需求文档、原型，甚至是思维导图与流程图等；

2：明确参会人员，此时需准确识别干系人，包括需求发起方、项目经理团队等；

3：根据参会人员情况协调会议时间与形式，预估耗时最好也传达在内，以便干系人合理安排时间。会议形式不管线上还是线下，均需要明确在线会议编号或参会地点。

4：拟定会议通知，确保参会人员均有效接收。

（2）会中阶段：

需求评审过程中易出现：理解不透彻、设计不符合要求、方案存在争议、技术实现困难、时间或资源冲突等问题，届时作为发起人和主持的产品经理就需要做好会议引导、避免失控。每个人对需求、设计的理解都有差异，如何通过统一团队目标是需求评审会召开的目的。出现问题也并不可怕，兵来将挡水来土掩，都是有解决方法的。

针对需求理解不透彻和设计不符合要求这两类问题，可让需求发起方再次阐述。产品经理需做好记录，临场也可提出其他方案供需求发起方选择。

针对方案存在争议的问题，可以让争议方阐述自身观点，产品经理识别问题症结，解释或做好记录，会后再处理。

针对技术实现困难的问题，可以让开发团队评估是否采用第三方技术插件、更换实现方式、咨询专家意见等。

针对时间或资源冲突问题，可以让需求发起方确定各项需求优先级、项目经理协调各项资源或者分多次迭代实现等方式处理。

雁过留痕，风过留声。会议必须做好记录。会议纪要是当前阶段的主要产物，目的是记录会议过程、以及在过程中产生的各项争议、注意事项、变更内容等，是会后阶段跟踪处理的依据。

（3）会后阶段：

会后阶段的主要活动是跟踪。会议结束后，产品经理需将会议纪要发送至每位参会人员，并根据会议纪要完善需求文档、设计，项目经理也可调整项目计划、协调资源等。

无论哪类应用场景，会议作为一种沟通方法，组织者如何清晰有效的将信息在准确时间通过恰当方式传达给合适对象并获得有效反馈与跟踪才算是形成闭环，才能称之为“高效会议”。

• 上一条： 带 “ 好 ” 团队，做 “ 实 ”工作：九不怕
• 下一条： 如何提高团队的战略执行力