好的会前准备，是效率的第一步

为什麽没有效率的会议是我的痛点之一呢？曾经有段时间公司的会议次数太多、时间冗长、常常讨论不完或是会议大纲跟实际上讨论的重点有所冲突。久而久之，团队的情绪会对会议感到焦虑，会议永远开不完，想讨论的事情多到没有结束的一天。

团队持续改善会议的效率，从中观察到身为会议的参与者，也可以让会议顺畅，而不是让主持人或是某些人才能做控场，接下来会以会议的流程分别从会前、会议中以及会议结束後去做说明可以改善的方式。首先来聊聊会议前的准备有哪些可以做的：

会通

会议的发起人想召开近十人的会议，通常会尽可能把要讨论的项目都塞在这个时间里面，避免後续还要花其他人的时间。这是人之常情，但如果有这样的念头，会演变成什麽都想要讨论，可是时间不够。或是某些议题要讨论的时间需要花的更多，而失焦原本要讨论的重要事项。

如果你是发起会议人，可以先想想这种会议的目的、会议的流程以及这场会议结束後，想要得到什麽产出。把这些厘清清楚後，可以在会通内容说明会议的进行方式，此外也可以做为开会时的待办事项，确保这场会议结束之後，可以预期达成的目标。

举下方例子说明，最後期望的是前後端确认规格无误後，接下来可以进行开发：

会议邀请主旨：[主题] 讨论需求 A 规格
讨论时间：08/31(二) 10:00 ~ 10:30
讨论内容：
- 请後端工程师说明文件规格
- 前後端对於回传栏位建议事项
文件规格连结：https://xxx.xxx.xxx/spec.doc

了解会议要讨论的项目，以及期望会议结束之後的结论是什麽。所以当参与会议时发现有人开始失焦讨论需求 B 或 C 时，可以适时地提出提醒与会者们，让会议能够顺畅的进行。

参与者

如果少了谁，这场会议就无法顺立进行？如果是这样的人物，当然要加入与会名单当中。但很多会议是不确定要不要出席，为避免可以漏掉很多资讯，所以还是参加为上。举例来说，在讨论改善会员 onBoarding 流程，而这场会议只是跟大家说明为什麽要做，预期改善会带来什麽效果。身为一个工程师，通常前期讨论跟最後要实做的方向会变动很大，所以不参加其实也不会影响太多，只是会少了了解需求过程的演变。

还有一种可以决定事情的关键人物不在这场会议当中，代表可以决定事情的人不在这个空间，就会让整个会议的讨论的每个事项都需要事後再一一确认。举例来说，老板可能会说你代表参加会议，他觉得可以不参加，然後跟你同步讯息。如果你了解这场会议会需要他的决定才能顺利进行下去，那还是请你说服老板参加吧。要不然会演变成，讨论中的决定全部都需要在事後讨论，而老板若不满意，是不是又需要花更多的时间做讨论呢？

预习

有些时候在发想阶段的会议，很难有事前准备好的文件可以做参考。但大多时候讨论都会基於目前已知的资讯进行讨论。假设大家都是参与会议的当下再进行了解开发规格，会让会议开头变成给大家阅读的准备时间，试想这些准备若不是放在这边，而是大家先行了解的话，其实大家马上可以针对开发规格有什麽想法跟建议进行讨论。

再来先行阅读可以带着问题进去会议当中，你的问题，也许都是大家的问题。而你的提问说不定可以衍生出更多的碰撞，能让产品或是开发体验可以越来越好。而当每个参与会议的人都这麽做的时候，会议上会发散的情形会逐渐降低，渐渐地，若有人不先做功课，先提出问题时，大家也会有默契了解谁在浪费彼此的时间。

在我的经验当中，在会通状况比较多，参与者跟发起人彼此对这场会议的想像完全不同。所以在讨论的内容容易走歪，而且歪到不知道走到哪个角落去了。这时候都需要靠参与者去拉回主题，或是来回对焦彼此想要产出是什麽。所以列出会议要讨论的项目很重要，就可以当做 Check List 勾选哪些已经讨论过的项目。如果大家也有跟我相同的困扰的话，不妨试试。或是有更好的做法也欢迎分享，让大家彼此交流。