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