“大家好，我是阿境，人称产品界的吴彦祖，一个沉稳又不沉闷的男人”
“吴彦祖，下午三点开会”
“收到”
阿境相信所有产品经理在日常工作中都会有大大小小的会议，项目周会，需求评审会，需求讨论会，交互评审会，项目总结会等等，用“贯穿工作全程”六个字来形容毫无违和感。
实不相瞒，“白天开会，晚上干活”的事情不论在大公司or小公司均是屡见不鲜。
不瞒你说，即使是作为厦门吴彦祖的阿境也深受困扰！
但事实是会议真的多如牛毛占据一整天的时间吗？
是否有合理利用好每一场会议的节奏？
如果你苦于会议太多，时间太长，不妨看看阿境总结的会议宝典。
提升效率，拒绝无效会议。
白天开会，白天工作，晚上好好回去炖个汤撸会猫它不香吗？
另：
①附上本文导图框架，节约时间。若您感兴趣，可继续深入阅读；若不感兴趣，感谢光临。
②老规矩，文末有本文知识体系地图，需要自行保存即可。
一、为什么需要高效的会议？
1、会议的目的
要了解会议的目的，先了解什么是会议？
会议指的是有组织、有领导、有目的的议事活动，它是在限定的时间和地点，按照一定的程序进行的。
划重点，“组织”、“领导”、“目的”、“程序”是会议的几大要素。
而“限定的时间跟地点”也是重要的一个限制因素。
可以这么说，会议的目的在于沟通并解决问题。
解决问题是重点，会议是更有效率解决问题的一个方式。
2、失败的会议结果
1）开会开成流水账
开会不带着目的来开，造成会议过程仅仅是阐述问题，没有明确会议目的，容易偏离会议主题，
开着开着变成记录日常事项的会议。
会议内容看似丰满，但内容毫无营养，“讨论半天，不知所云”。
2）开会开成菜市场
在会议的过程当中，若会议没有合理的规划及管控，容易出现“你一言我一语”的情况，这正是因为偏离会议主题的原因以及会议主持人没有把控好会议节奏导致的情况。
浪费了会议时间不说，同样透支了参会人员的耐心。
“辩论半晌，毫无收获”是这类会议结束之后的感悟。
二、产品经理会经历的会议
回顾一下产品的生命历程：“业务需求→市场调研→产品架构→功能需求池→功能流程图→页面原型→功能逻辑→产品需求文档→产品评审→测试用例→数据分析→产品迭代”
由此，可以引申出，产品经理会涉及的会议有：项目周会/月会、项目启动会、需求讨论会、需求评审会、交互评审会、需求排期会、项目复盘会。
简单提一下几个会议的内容。
项目周会：主要包括项目日会、项目周会、项目月会。用于与项目组人员对齐项目进度，把控项目风险及项目变更。
项目启动会：用于项目的启动，包括项目的立项，前期准备，所需资源的规划、成本的估算等，等同于项目立项会。
需求讨论会：包括与领导、运营、产品、交互间的需求讨论会，不同角色侧重点各有不同。主要针对需求的合理性、必要性及可行性从不同角度出发进行探讨。
需求评审会：主要针对需求文档，与团队成员（运营、开发、测试、交互）进行需求的评审及修改，便于后续推进需求的落地。
交互评审会：通过产品经理的调研、分析等，交互产出交互稿后，与产品经理进行交互稿件的评审及修改。
需求排期会：通过确定后的需求文档，开发进行整体项目的排期，包括设计稿、客户端、服务端、前端、测试等各个节点的deadline制定，其中包括项目的把控、风险预估等。
项目复盘会：项目上线后，通过一定时间的运转，分析项目成果。并罗列整个项目进程中所发生的项目事项，复盘项目过程，对优项进行总结，抽象成SOP便于后续学习，对劣项进行优化，避免再次发生。
三、每个会议的通用法则
乍一看，好家伙！这做一个产品经理咋这么多会议？
敢情这白天都不用干活光开会了？
但作为一名产品经理，最主要的能力不就是解决问题的能力吗？
会议多？时间长？人员乱？
别急，阿境抽象总结了会议的通用法则，不论是哪种会议，都能够用得上。
（别夸我！实在要夸的话，就夸我是厦门吴彦祖就好）
1、会议的五要素
会议五要素包括人物、时间、场景、事物、主题。
【人物】
参会的干系人，包括主讲人及参会者
【时间】
指会议的开启时间及结束时间。
我们在开会的时候，往往记得通知会议的开始时间而忽略了会议的结束时间，也就是会议持续时间。
当没有设定结束的时刻，那么当人在手头没有紧急要事的时候，就会在潜意识当中认为会议时间很长，从而无限拉长会议时间，造成会议效率低下。
试想一下，你领导给你布置一个任务，但是没有deadline，那么你会当天就解决掉吗？
答：“会的！”
好了，别欺骗自己了，大概率是不会的！
注意要点：
会议时间记得提前邀约，每个人手头都是有任务安排的，尊重他人的时间及安排。
若涉及的时间有冲突，根据重要性程度去协调对应方的时间。（例如老大A与下属B的时间冲突了，在会议无法延期的情况下，协调下属B的时间）
【场景】
指会议的开会地点，包括有投影仪、白板等设施，便于会议地有效进行。
【主题】
会议的内容及事件，包括会议的背景，最终解决的问题
2、会议通用流程
关于会议的通用流程，简单来说，阿境总结了一句话“一约二讲三总结”
一约包括约会议人员的时间、会议室的时间；
二讲包括讲述会议背景，阐述会议内容；
三总结包括总结会议内容，执行会议结果；
若将整体流程剖析开，则可分为【会议前】、【会议中】、【会议后】三部分
【会议前】
①以类邮件形式发布会议邀请，附上会议文档（如需求文档等），并提前周知参会者阅读
②若有需讨论内容，周知参会者提前准备，提升会议效率
③若会议上涉及方案讨论，提前准备多种方案
④若涉及方案评审，则所有问题在会前提前解决
⑤提前预定好会议室、投影仪等，并在会前提前到达准备
⑥若有白板，可在会议前提前写上会议目的及背景等（节省会议效率）
⑦确认好会议记录者，便于会议纪要的撰写
【会议中】
①会议第一件事介绍会议背景、目的（该点虽小，但无比重要！）
②清晰阐述会议结构，突出重点，区分会议时间的划分主次
③主讲人需掌控会议的主导性及方向性
④时刻明确会议主旨，讨论过细或者远离此次会议讨论范围时一定要及时拉回来，提高会议效率
⑤会议中争议较大的点，采取“5分钟原则”，若限定时间内未得出结果则延后讨论
⑥会议整体时长不宜过长，若时间的确过长，则可一一拆分
⑦可借助工具（白板、电脑等）通过可视化给到项目组人员更直观的表现
【会议后】
①整理会议纪要，越快越好（保证内容的不失真，以及项目人员能够及时回顾会议内容）
②会议内容以邮件形式周知参会人员，需要执行的，明确指出具体责任人
③会议遗留问题在短时间内进行解决
四、高效会议的宝典
1、项目周会/月会
①主讲人提前做好项目进度的阐述
②项目各角色阐述项目进度，项目问题，项目解决方案及所需配合资源
③把控项目当前风险，若出现风险则寻求解决方案
④项目若有需求变动，在会上一并提出并记录
2、项目启动会
①准备好项目调研报告、项目数据情况等材料
②主讲人需要提前准备项目概述及启动陈词
3、需求讨论会
①准备好各角色的产品需求(包括运营需求、产品需求、老板需求、商务需求等)
②提前标注好需求背景、需求价值、用户价值、预期解决方案等
③与需求方沟通清楚需求的来龙去脉，确定需求是否要推进
④会后标记需求状态
4、需求评审会
①针对于每个需求点，产品经理需做好数据调研、市场调研、用户心理分析，需求背景，用户价值等的准备，应对项目组人员对需求产生的疑问
②提前将需求与各开发单独核对，方案上有问题提前解决
③产品经理核对需求当中的错误点（避免简单的逻辑错误等）
④切勿将需求评审会开成技术研讨会，及时“制止”评审会的技术过多的讨论
⑤在陷入某个问题过久时，若无合适方案，记录下来且会后再议
⑥切记，需求评审会并非讨论会，而是方案确认会，过长的会上讨论容易引起疲惫
5、交互评审会
①提前与交互人员确认好交互方案
②进行组内评审，如果是新人，尽量与导师or其他交互人员沟通
③在出交互方案钱，若时间充足，尽量罗列不同的交互方案，便于会上沟通
6、需求排期会
①针对于于每个需求的时长进行提前评估并预判
②在排期过程中若有疑问及时提出并修改
③排期会一般不会太长，仅是针对于排期，对齐项目组人员的工作任务
7、项目复盘会
①产品侧人员收集各项目角色在项目当中的感受体验
②产品侧/运营侧总结产品数据表现，并给项目人员展示
③会议上根据各角色总结的问题，逐一发言并且寻求解决方式
④总结项目复盘内容，形成文档并在下一次项目中改进
五、会议注意要点
1、重视会议前的准备，提前了解会议主题及内容
会议前的准备不仅仅是主讲人，包括参会者。
主讲人需要准备会议内容这点无需多言，参会者也需要了解会议的内容并提前准备相应的材料及内容。
当然，有些想法及灵感是在会议当中思想碰撞才产生的，这也是在有提前准备的前提下。
2、明确会议目的，并把控全程节奏
在会议过程中，我们在讨论过程中往往会讲着讲着就开始偏题，从A讲到了B，而后在B讨论了半天 ，发现时间已经流逝，回过头来，B既不是会议要解决的问题，A也没得到有效地方案，造成了会议时间的浪费，且参会人员会有挫败感。
这就是没有明确会议目的，“强行偏题”的结果。
在会议刚开始时，通过与参会人员明确会议目的，达到会议“有意义”。
建议：通过白板书写目的及流程
3、精准管理会议时长，把控“注意力优先法则”、“5分钟原则”
会议时长不宜过程，所以需要设定会议deadline。
但在进展过程中，由于会议讨论，不可抗因素等，往往容易造成会议拖堂。
根据科学研究“注意力优先法则”，“人的精力在百分百的状态下只能维持30分钟，超过则效率会呈指数降低”。
过长的会议会使得整体参会人员往低效率的方向前行，同时会引起人的心情烦躁，从而可能在会议中导致错误的决策及讨论。
由此，会议主讲人需精确管理会议时长，减少会议拖堂。一旦在时长有可能因为某些因素拉长时，尽力加快部分内容的讲解。
若在会议过程中，某个问题点争议较大，则根据“5分钟原则”，若5分钟内未解决，记录下来会后单独解决。
建议：设定会议闹钟
4、记录好会议纪要
往往在对于产品新人，在一场会议之后，总会被叫去记录会议纪要。
也常常听到有产品朋友抱怨“领导总让我做会议纪要这种杂事，我该怎么办？”
记录的目的在于会议核心内容的记录同步及后续的复盘，并非记录本身。
在阿境看来，这并非杂事，相反，能够锻炼对于会议内容的提炼能力，以及产品经理所必备的书面表达能力。
同时，把时间线拉长点来看 ，会议如此之多，事情如此之繁杂，会议纪要对于项目人员来说，起到复盘的作用。
可以说，写好会议纪要，才能使得会议不白开。
5、控制好开会人员
与其说控制好开会人员，不如说是控制好开会人数。
人数多≠信息传达全。
往往我们会有个误区，开会需要将所有牵扯到的干系人都拉过来，但人数多容易造成了会议效率低下的情况。参会者若不清楚逻辑，则在会议中提出的问题打乱了会议的进度及秩序，从而浪费了真正会议的时间。
仅与会议有直接关系的人参与即可，较为边缘的人员可等到会议中途再参与或者是后续查看会议纪要。
6、提前规划好会议
“会议太乱了”、“会议开完不知所云”、“仿佛是花了两个小时听了一场辩论会”等感受都是由于没有提前规划好会议造成的。
规划会议包括会议的时间分布、会议内容主题阐述，会议总结等，主要由会议主讲人来进行规划会议。
时间分布主要指时间的划分，比如会议总共为ABC三部分内容，A占会议时长的50%，B占会议时长的30%，C占会议时长的20%。当其中一部分超出了时长，为了会议的效率，在保证内容的前提下，缩短其余部分的占比，保证会议简约。
会议内容主题阐述主要指主讲人逻辑清晰，阐述分明，减少不必要的语言。
会议总结指的是在会议结束后，通过总结陈词，明确会议结果，及各部分人员在会后所需要的做的工作内容。
7、把控好“发散思维”及“收敛思维”
“发散思维”及“收敛思维”是我们平时运用得较多的思维方式。
但在不同的会议上，需要运用好这两种思维，例如“需求讨论会”更多的是“先发散再收敛”，而在“需求评审会”更多的是运用“收敛思维”。
合理地运用好两种思维方式，也能够使得不同会议达到最优的效果。
还有一类思维称为“涌现思维”，是介于两种思维的中间，通过在早期分歧阶段涌现的灵感来刺激新想法的产生，更多出现在“头脑风暴”之类的会议上。
六、写在最后
在产品经理的实际工作当中，会议会有，不可避免，那么，若出现了效率不高的情况，就去优化它。
与此同时，阿境也采访了身处大/小公司的几位朋友（几位真的很多了，最近忙成dog），不论公司体量大小，都有“会议多，效率低”的困扰。
也尽己所能总结部分会议SOP，以及注意要点，虽不全，但精辟。
总的来说，“提前准备，把控节奏，做好纪要”是一场有效率会议的必要条件。
共勉。
阿境，产品界的吴彦祖，一个沉稳又不沉闷的男人。
野蛮生长，产品汪一枚，做过电商、医疗、教育、游戏行业项目，4399产品经理。
坚信"产品源于生活"，欢迎交流。
公众号：梦想家阿境
