会议管理心得记录
(注： 由于markdown效果太不满意，故另外写了一份非markdown版本的，内容都一样，只是添加了些排版，对排版比较敏感的，欢迎看非markdown版本。以后的更新应该也主要针对非markdown版本，链接请点：会议管理心得记录（非markdown版）)
前提
本文说的会议特指有开发团队成员参与的会议， 包括但不限于开发、设计、测试、运维、管理岗位的成员。 因为不同工种和行业都有其特殊性，我是一名程序员，并不太了解其他工种和行业的具体情况，不敢妄言。
术语定义
会议： 本文中的“会议”指的是当团队有问题需要解决时，并且希望通过会议的形式，让若干个团队内或外的人员参与进来，通过开会讨论的方式找到解决方案。这种会议包括项目总结会、头脑风暴、周会等。不需要进行讨论、不是为了给问题找出解决方案的会议不在本文讨论范围之内，如信息宣布的会议（如宣布领导的决策）、表彰大会、毕业典礼（任何一人说众人听的都不算）、大部分公司年会。
公司成本： 指公司为了聘用一名员工需要投入的成本，该成本高于员工月薪，因为一般还要包含社保、公积金、办公用品、办公场地等成本。
为什么要进行会议管理
较多人认可的一个事实是：会议是一种工作中成本比较高的集体活动，其中较明显的成本包括：参会人员会议时间成本，会议室的场地成本。
举例说明，某开发团队遇到一个问题需要讨论解决， 一名高级工程师创建了一个时间为2小时的会议，需要自己和另外四名中级工程师参与。
我们来大概计算一下这个会议的成本。
要计算这个会议的大概成本，只要计算出全部参会人员的公司成本即可， 因为公司成本包含了场地成本，所以不必另外计算会议室成本。
假设高级工程师的月薪是HighSalary，中级工程师月薪MiddleSalary。
再假设:
HighSalary = 2W;
MiddleSalary = 1W;
假设公司花在员工身上的成本为员工月薪的1.5倍（实际上往往不止）。
一个月一般有21-22个工作日, 这里我们按21.5个工作日算。 每个工作日算8小时。 那么最终会议成本cost就等于：
cost = ((( HighSalary + 4 * MiddleSalary ) * 1.5) / 21.5 / 8 ) * 2;
==>
cost = 1046.5元； // 约等于
这个2小时5人参与的会议，成本1000元多一点点，好像还不是很贵。
当然我上述的月薪都是假设的，可能比市场价要低，大家可以根据自己公司的情况换算一下， 看是否超出了你们的预料。
当然这是对公司的成本，开发人员可能不太敏感。 那么开发人员有什么成本呢？
在有项目计划或进度压力的情况下，如果开了一个效果不理想的会，为了完成原定的工作目标，往往开多长的会，就代表你要加多久的班。（很多团队制定开发计划时是没有把会议的时间算到计划中的）
前面说了，这是会议的明显成本，其实还有一些不明显的成本。例如：
- 会议前，组织者需要为会议花时间准备
- 会议前，参与人员需要进行一定的学习和准备
- 参会人员工作被打断带来的成本。（由于程序员工作的特殊性，有些文章提出，程序员工作被打断后要大约1个小时才能重新进入状态）
这些成本有不确定性和偶发性， 大家可以根据自己的经验和情况大概算一下。
除了考虑单个会议的成本外，还需要考虑会议成功与否，因为如果会议失败，就意味着这个会议的成本投入全部或部分白费了，可能还要另外再开一个会。
一般会议有几种结果：
- 按时结束，并能完成既定目标，那么这个会议是非常成功的；
- 能完成既定目标，但是比计划占用了更多时间，也算勉强成功；
- 按时结束，但未完成既定目标，那算是一般的、可接受的失败；
- 即超出了原定时间很多，又没有完成既定目标，那么这个会议就比较失败了。
由于会议的成本不低，公司想降低成本，员工想少加班，所以我们要进行会议管理。
会议的目标是通过讨论来解决问题，所以会议管理的目标其实是降低解决问题的成本。我们通过以下两点来实现这个目标：
- 缩短单个会议时间，提高会议效率
- 提高单个会议成功率
在说如何具体如何做之前，我想先说说我认为比较常见的几种失败会议。
（PS:为什么我要花那么多篇幅在这一节呢？ 因为我觉得，很多问题，要解决起来并不太难，难的是要意识到那是一个问题。）
失败会议
场景一
在我第一家公司时，我们开发团队在深圳上班，经理在香港上班。
经理每周会过来找我们开会，了解我们的情况。有时也讨论几个问题。由于一般每周都有，暂时称其为周会吧。
周会上，讨论问题时经常跑题和闲聊，等问题讨论完也不舍得结束会议。
讨论完问题，经理会和我们说下公司的美好前景和接下来的宏大计划，还有心灵鸡汤等等。
经常一开就是一整天的会。
刚开始，每次开完这种会，都感觉精神抖擞，像打了鸡血一样，工作更有干劲了。
但是时间久了，每次开完会，该做的工作还是要做，反而因为开这种会，要加更多的班了。
场景二
在一个解决方案的研讨会议上，一群开发人员唇枪舌战，讨论得面红耳赤。 在经过数小时的辩论后，终于一致认可了某个解决方案。然后散会。
散会后没有写会议纪要，也没有让参会人员审核会议结论，散会后就各忙各的了。
一个月过去了，当时的参会人员已经执行了当时的解决方案一段时间，但是慢慢发现一些问题，大家就又开了一个会。
在这个会上，大家都说依然认可一个月前定下的解决方案，但是不同的人对该解决方案的解释却不一致。
有些是因为时间久了，记忆出现偏差， 有些是当初的理解就和别人不同。
然后又辩论一遍，而且会后依然没有记录和审核。
场景三
某开发团队就一个目的，定了会议议程并组织一个会议。 该会议要讨论并解决3个问题，为期1小时。
开会时第一个问题就讨论了1个小时，而且还没解决。
然后大家坚持把3个问题都讨论完，已经花了3个多小时。
讨论完后，某为成员又想到一个问题并提了出来，大家马上就这个新问题进行讨论。
在筋疲力竭的情况下再坚持1个多小时把新问题也讨论完了。
终于散会了。
以上是我个人工作中遇到比较多的情况。当然失败会议的情况各种各样，无法一一列举。
如何进行会议管理
这里说的会议管理，主要是讨论会议组织者需要做什么以及怎么做。
但是会议要开的好，光组织者做得好是不够的，也会议参与人员的配合才能得到好的效果。 所以下面也会偶尔提及一些需要参与人员配合的情况。
我认为要开好一个会议， 不光是开会的时候要有各种技巧和注意事项，开会前准备和开会后的工作也同样重要。
1. 会议前
之前提过的我个人评价会议成功与否的标准，主要看是否实现了会议的目标，是否解决了会议打算解决的问题。
所以首先，我们要有一个需要解决的问题。
然后，我们要问自己，是否真的需要开会来解决这个问题？ 有时可能只需要两三个人私底下讨论一下就能解决问题，未必都需要开会。
如果确实需要开会，有了要解决的问题，我们的会议就有了目标。
有了目标后，我们需要考虑为了实现这个目标，需要哪些人参与讨论，即参会人员。
由于会议成本主要是人力成本，所以我们应该严格控制参与会议的人数。我认为以解决问题为目的的会议不需要旁听人员，即参会人员都是会参与讨论且意见都可能被采纳的。不参与讨论或意见不会被采纳的人员就别邀请进会议了，那只是浪费大家时间。最忌讳的就是有事没事拉一大帮人进会议室。
会议的目标会是解决某个或某几个问题。然后我们需要根据问题的大小和复杂度，设定一个打算用来解决这个问题的时间限制。
大部分会议不会只讨论一个问题，当需要讨论多个问题的时候，可以根据要讨论的问题之间的关系、每个问题的复杂度等，定出问题讨论的顺序。
此外，要解决的问题可能会有些相关的资料，需要整理这些会议资料，以附件的形式添加在会议邀请中。会议资料可能包含目标的信息、解决方案的线索等等。有些会议资料是需要参会人员在开会之前先学习了解的，对于这些资料，最好在会议邀请中注明。
以上几点完成后，就可以做会议前准备的最后一步了，就是会议邀请。 一般我是以邮件的方式来邀请会议，当然用其他形式也可以。
会议邀请中需要包含上述准备好的信息，以邮件为例：
- 会议主题 - 本次会议要解决什么问题
- 会议时间
- 会议地点
- 会议议程 - 即上述说的会议目标、讨论顺序以及讨论每个问题的时间限制
- 参会人员
- 会议资料 - 若需要参会人员提前学习的，需要注明。
对于会议组织者来说，以上是我能想到的会议前准备的各个点。当然这并不能涵盖所有会议，不同的会议根据其特殊性，可能要准备得多一点或者少一点， 我们根据实际情况处理就好。
作为参与者，如果有需要会议前学习的资料， 为了会议效果更好，也需要尽量配合组织者，进行必要的学习和准备， 因为其实这也是在节约自己的时间和提高自己的时间效率。
2. 会议中
会议中的注意事项其实不多，但是却是比较难实际操作的。会议进行中，会议组织者需要做的事情主要有三点：
- 尽量按照会议议程进行会议
- 尽量让参会人员围绕会议当前议程进行讨论
- 记录每个议题的结论，若没有结论，应记录
关键信息（在后面再细说）以供下次会议继续讨论
会议中，我们会按照议程一个个议题进行讨论，每个议题都是一个问题。一般我们讨论一个问题，需要先分析问题的各种特点和信息，尽量拆分问题以便将一个大而难的问题拆分成多个小而容易解决的问题。
讨论问题时，一般很少一下得到最终答案，而多数情况是跟我们中学时做数学题类似，要一步步推导直至得到结论。 讨论问题时，我们会得出多个中间结论，我们会一致认可这些中间结论，再一起基于中间结论继续向下推导。每个中间结论都给我们提供更多关于问题的信息，这些信息都能帮助我们得出最后结论。
关键信息: 即上面提到的问题的各种特点和重要信息，以及最后一个大家都认可的中间结论。这样下次会议大家可以接着讨论。
上面第一点提到了“尽量”按照议程，因为实际情况总是多变的，如果某议题已经到时间，但是讨论明显已经进入尾声，马上就能得到结论，那么我们不应该打断该议题的讨论， 而应该让其顺利得到结论，再进入下一个议程。
但如果某议题看起来离得到结论还有不短的距离，除非这个议题没结果后续议题就无法讨论，或该议题比后续议题重要很多， 那么建议将当前议题的中间结论和关键信息记录下来， 然后转入下一个议题。
关于第二点，其实可以用简短的话进行概括， 就是： 避免会议失控。
开会很常见的情况就是会议失控，大家原本为了讨论一个问题，由于各种原因，可能出现以下情况：
- 跑题 - 聊着聊着说到其他事情上而且短时间内回不来了，也没有人负责组织会议，来把话题拉回来。跑题有时是变成与工作无关的闲聊，有的是跳到聊另一个问题去了。
- 无意义的争论 - 对一些次要的对解决问题不起太大作用的细节进行无休止的争论，各人不愿退让，甚至到后来只是为了争论而争论，不仅阻碍议程的完成，经常出现无意义争论还可能影响团队和谐。
跑题跑到其他问题上的情况是比较常见的，例如讨论问题A的过程中，发现了另一个有一点关联的问题B，但是问题B对解决问题A不起什么作用。这时，我们不应该想到问题B就马上切换到问题B的讨论上，如果问题B是个重要的需要解决的问题，我们可以记录下来，另起一次会议来解决问题B。 这能避免会议时间和议程的失控。
会出现这些问题，一般是由于会议缺少一个“主持人”，即会议组织者。会议组织者需要在有人明显跑题、进行无意义争论时进行干预，让会议回归原本的议题。 在议题明显超时时，要果断的组织进入下一个议题。
会议组织者的任务就是让会议尽量按时结束， 会议过程让时间尽量都花在解决问题上。这么做是为了达到之前提到的会议管理目的：
- 缩短单个会议时间，提高会议效率
- 提高单个会议成功率
刚开始这么做时，很容易出现时间到了议题还没讨论出结果的情况，但这是必经的过程，因为团队还习惯于没有时间限制的会议，他们可以海阔天空的畅所欲言，不必担心时间不够用，也不会担心浪费了大家的时间。 但是当团队慢慢习惯于有时间限制的会议后，就像习惯于有开发计划的项目一样，大家会逐渐遵从有时间限制进行会议，会有意识的避免闲聊、跑题、废话、无意义争论等浪费大家时间的行为。
当你手机只剩20%的电时，你肯定会把这20%的电只用在最重要的事情上。
当然，对于会议组织者，每个议题的时间制定也是需要慢慢总结经验并调整的，如果你发现制定一个小时来讨论一个中等复杂度的议题，总是讨论不完，而且会议中你觉得自己已经组织得足够好了，那么你应该调整你制定的时间限制，在下次组织会议时，可以适当增加类似复杂度的议题的讨论时间。
议题的讨论时间限制过短，就跟项目开发计划时间过短一样，因为原本就不可能完成，这个限制会变得没有意义。
但是对于已经制定好的会议议程，建议还是严格遵守。
3. 会议后
如果会议前、会议中，都已经做得很好了，是不是工作就结束了呢？
当然不是！
会议的产出是各议题的结论或解决方案，这是经过讨论并能得到大家认可的，是参会人员这会议期间的劳动产出。
但由于不同人的理解很可能不同，人也会随着时间流逝而忘记一些细节甚至完全记错， 所以，我们需要会后整理会议纪要。会议纪要可能会包含这些内容：
1.对于有结论的议题，要清楚写明结论的详情，详情可能包括：如何解决问题、如何执行、谁负责执行、何时应该完成等。
2.对于还没结论的议题，需要记录问题的关键信息，该问题已解决的部分和未解决的部分分别有哪些。
3.新发现的问题，是否需要再开一个会解决，大概何时开会、谁需要参加等等。
会议纪要的作用不单是记录，更重要的作用的避免歧义。 所以会议纪要写好之后，需要让所有参会人员进行审核，若发现理解存在歧义，需要进行讨论和修正。 以实现大家对会议结论的理解基本一致。
在审核过后， 有会议纪要的存在，也能促进会议结论的执行。
根据会议性质不同，会议纪要的内容可能大相径庭，但是会议纪要还是很有必要的。 会议纪要需要记录会议中的重要结论，我认为如果会议的结论不写进会议纪要，跟没开过会没什么分别。
就我个人而言，我不是一个记性好的人，而且工作中每天要思考和处理各种问题，我不可能牢记每个问题的前因后果，也记不住每次会议的过程和结论， 所以我需要将这些结论写下来可供我日后查看。 我不需要占用大脑的容量来记录这些，给大脑腾出点空间来思考。 我把我的大脑想象成固态硬盘，而各种文档是我外接的机械硬盘。
结尾
这篇文章断断续续写了很久，能想到的基本都写下来了，主要为了供自己记忆和日后回顾。 写的不太顺畅、也不够简洁，功力还很欠缺。博客园的markdown效果也很不满意。日后再慢慢补充完善。
注： 由于markdown效果太不满意，故另外写了一份非markdown版本的，内容都一样，只是添加了些排版，以后的更新也主要针对非markdown版本，链接请点：会议管理心得记录（非markdown版）
谢谢观看，
2016.10.31
