项目实战笔记之一：高效会议的组织方法

　　关于开会大家应该都不陌生，而且应该有不少人被过度频繁的会议“伤过”，甚至”谈会色变“ 。当一个组织的人员较多，结构复杂时这个问题会更加突出。如果开发人员/测试人员参加会议过多，会导致工作打断严重，直接影响到团队工作效率。如果管理人员参加会议过多，会导致管理人员离开所负责的管辖范围时间较长，不能及时响应事情，从而导致团队整体管理效率变低，典型表现是很多事情没有及时处理、开始积压。

　　当然会议是需要的，主要是我们要总结出一套高效的方法。下面分享一些总结，有兴趣的同事可以一起探讨。

第一，确认会议类型及目的。我认为在我们公司的研发体系里以会议目的划分，会议大体可以分为以下6种：

1. 团队建设：激励团队，培养员工的团队意识，让每个参与人员了解共同的目标，树立全局观念，无形中能够帮助团队减少协调成本。 例如：版本项目周会

2. 报告绩效：向上级管理层汇告版本当前绩效情况，并且根据需要可以获得适当的资源支持，例如：RDM的项目分析会议

3. 平级沟通：针对问题通过会议讨论形成解决方法或是达成处理协议. 例如：开发和测试周会，跨部门合作会议

4. 信息传达：将信息传达出来，让相关人得到信息并理解信息，以方便进行下一阶段的工作。例如：新流程培训会议，经验分享会议

5. 创意开发：针对某一个问题的解决方案或是某个方向的创新主题进行讨

6. 评审会议：技术方案/需求文档评审，疑难问题讨论等

　　确定好会议类型及目标之后才能选定出需要讨论哪些内容，汇报哪些信息，以何种方式组织。这里举个示例：

　　示例：一个项目组对RDM做绩效汇报（项目分析会）。我们首先确定会议目标为：

a. 向RDM提供版本总体计划情况，当前进展，当前存在风险及计划应对措施，趋势预测等

b. 申请关键资源支持，因为RDM听过完整汇报时，对版本有了比较系统的判断，此时如果确实需要资源协助，比较容易得到批准

　　确定目标后，我们可以发现开发和测试在这里是被作为一个团队看待的，因此在这个会议过程中开发和测试的意见应该是一致的，并且汇报的内容不能重复，但可以各有侧重。因此会议前开发和测试应该进行明确的汇报分工，各自总结完后，内部讨论得出一致结论。基于这样定位而组织的项目分析会，会非常高效，并且能够在短时间内将版本整体情况展现出来，同时也促进了开发和测试内部一次完整性总结。而如果没有这些前期工作，项目分析会过程中，开发和测试意见可能非常不符，甚至进行争吵，更严重的是发生互相责怪，推卸责任的情况。

第二，开有准备的会议。有准备的会议需具备以下三个特点:

1. 有清晰的会议历程及会议预期

　　例如：大多数开发和测试的例行沟通会议，是以明确问题及达成协议为主，而不是解决具体的某个问题，如果过于深入会导致时间浪费，更严重的是随意决策。

2. 选择合适的人参与

　　会议召开前需确定好哪些人要必须要出席，哪些人得到讨论结果告知即可。将会议控制在必要范围里的好处在于，避免会议浪费其他人员时间，同时保证会议的发言质量。

3. 选择合适的时机

　　合适的时机是指要评估与会人员的时间繁忙程度、解决问题的条件是否成熟，这个时间开会的效果如何？例如：项目进度非常紧张的情况下，项目组每周举行耗时很长的个人知识及读书经验分享是不合事宜的。

第三，议而有决，决而有行，行而有果。

　　从结果导向来看，会议都是基于某种目标而召开的，因此达成预定目标是非常重要的，会议过程中，组织者要进行有效的时间控制，出现跑题情况时要及时引导纠正，防止参会人员天马星空或过于深入细节，浪费大量时间。这个过程可以简称为议而有决。决而有行是指，会议讨论出的决策要形成任务分解，并落实责任人。行而有果是指，已经分解的任务要进行跟踪，产出效果。第三点总结起来比较简单，但是往往是我们难以落实的地方，所以经常会出现诸如“这个问题，我们好像上次讨论过”的这类情况。

其他一些小技巧罗列如下：

1. 大会之前通常要有小会，从而达成高效

2. 会议开始前先讲解会议历程及预期

3. 会议上以明确问题、达成协议为主，不深入问题讨论

4. 会议上的决策直接指派落实责任人

5. 会议记录要在24小时内发出，晚48小时之内

6. 对于例行会议，可以收集参会人员的会议质量反馈，进行持续改进