关于开会大家应该都不陌生,而且应该有不少人被过度频繁的会议“伤过”,甚至”谈会色变“ 。当一个组织的人员较多,结构复杂时这个问题会更加突出。如果开发人员/测试人员参加会议过多,会导致工作打断严重,直接影响到团队工作效率。如果管理人员参加会议过多,就会导致管理人员离开所负责的管辖范围时间较长,不能及时响应事情,从而导致团队整体管理效率变低,典型表现是很多事情没有及时处理、开始积压。
当然会议是需要的,主要是我们要总结出一套高效的方法。下面分享一些总结,有兴趣的同事可以一起探讨。
第一,确认会议类型及目的。我认为在我们公司的研发体系里以会议目的划分,会议大体可以分为以下6种:
1. 团队建设:激励团队,培养员工的团队意识,让每个参与人员了解共同的目标,树立全局观念,无形中能够帮助团队减少协调成本。 例如:版本项目周会
2. 报告绩效:向上级管理层汇告版本当前绩效情况,并且根据需要可以获得适当的资源支持,例如:RDM的项目分析会
3. 平级沟通:针对问题通过会议讨论形成解决方法或是达成处理协议. 例如:开发和测试周会,跨部门合作会议
4. 信息传达:将信息传达出来,让相关人得到信息并理解信息,以方便进行下一阶段的工作。例如:新流程培训会议,经验分享会议
5. 创意开发:针对某一个问题的解决方案或是某个方向的创新主题进行讨论
6. 评审会议:技术方案/需求文档评审,疑难问题讨论等
确定好会议类型及目标之后才能选定出需要讨论哪些内容,汇报哪些信息,以何种方式组织。这里举两个示例:
示例一:一个项目组对RDM做绩效汇报(项目分析会)。我们首先确定会议目标为:
a. 向RDM提供版本总体计划情况,当前进展,当前存在风险及计划应对措施,趋势预测等
b. 申请关键资源支持,因为RDM听过完整汇报时,对版本有了比较系统的判断,此时如果确实需要资源协助,比较容易得到批准
确定目标后,我们就可以发现开发和测试在这里是被作为一个团队看待的,因此在这个会议过程中开发和测试的意见应该是一致的,并且汇报的内容不能重复,但可以各有侧重。因此会议前开发和测试应该进行明确的汇报分工,各自总结完后,内部讨论得出一致结论。基于这样定位而组织的项目分析会,就会非常高效,并且能够在短时间内将版本整体情况展现出来,同时也促进了开发和测试内部一次完整性总结。而如果没有这些前期工作,项目分析会过程中,开发和测试意见就可能非常不符,甚至进行争吵,更严重的是发生互相责怪,推卸责任的情况。
第二,开有准备的会议。有准备的会议需具备以下三个特点:
1. 有清晰的会议历程及会议预期
例如:大多数开发和测试的例行沟通会议,是以明确问题及达成协议为主,而不是解决具体的某个问题,如果过于深入会导致时间浪费,更严重的是随意决策。
2. 选择合适的人参与
会议召开前需确定好哪些人要必须要出席,哪些人得到讨论结果告知即可。将会议控制在必要范围里的好处在于,避免会议浪费其他人员时间,同时保证会议的发言质量。
3. 选择合适的时机
合适的时机是指要评估与会人员的时间繁忙程度、解决问题的条件是否成熟,这个时间开会的效果如何?例如:项目进度非常紧张的情况下,项目组每周举行耗时很长的个人知识及读书经验分享是不合事宜的。
第三,议而有决,决而有行,行而有果。从结果导向来看,会议都是基于某种目标而召开的,因此达成预定目标是非常重要的,会议过程中,组织者要进行有效的时间控制,出现跑题情况时要及时引导纠正,防止参会人员天马星空或过于深入细节,浪费大量时间。这个过程可以简称为议而有决。决而有行是指,会议讨论出的决策要形成任务分解,并落实责任人。行而有果是指,已经分解的任务要进行跟踪,产出效果。第三点总结起来比较简单,但是往往是我们最难以落实的地方,所以经常会出现诸如“这个问题,我们好像上次讨论过”的这类情况。
其他一些小技巧罗列如下:
1. 大会之前通常要有小会,从而达成高效
2. 会议开始前先讲解会议历程及预期
3. 会议上以明确问题、达成协议为主,不深入问题讨论
4. 会议上的决策直接指派落实责任人
5. 会议记录要在24小时内发出,最晚48小时之内
6. 对于例行会议,可以收集参会人员的会议质量反馈,进行持续改进