对会议效率的一些思考

可能不少人都听说过著名的"Team Meeting Driven Development",也就是会议驱动开发模式。而很有可能有更多的人都亲身经历过持续数小时,甚至数天的“无尽模式”的会议。大家在痛恨之余,不知道有没有想过怎么才能避免陷入天天实践TMD模式的囧境。对于大型项目来说,沟通效率基本决定了一切。而这一点也是研发的本质复杂度所在,并不能随着开发语言和工具环境的改进而提升。这几年做项目对这个也有很多思考,今天写写一些想法吧。

估计大家都经历过这样的阶段:开会效率低,大家就去找各种如何高效会议的手册什么的,比如这本大名鼎鼎的《罗伯特议事规则》,正好以前还做过一点读书笔记,附在后面,没有看过的同学可以快速的了解一下这本书的主要内容:

  • 基本思想
  • 平衡:保护各种人和人群的权利,包括意见占多数的人,甚至是每一个人,即使那些没有出息会议的人,从而最终做到保护所有这些人组成的整体的权利
  • 对领袖权利的约束:集体的全体成员按自己的意愿选出领袖,并将一部分权利交给领袖,但是同时,集体必须保留一部分权利,使得自己能够直接控制自己的事务,避免领袖权利过大
  • 多数原则:多数人的意志将成为集体的意志
  • 辩论原则:所有决定都必须是经过了充分的自由辩论协商之后才能做出的,每个人都有权利通过辩论说服其他人接受自己的意志,甚至一直到这个意志变成总体的意志
  • 集体的意志自由:在最大程度上保护集体自身,在最大程度上保护和平衡集体成员的权利

    具体的会议规则如下:

    最小构成

  • 会议开始之前必须确定使得会议结果有效的法定人数
  • 保证会议结果代表了多数人的意见
  • 避免出现一言堂

    基本组成

  • 主席:主持会议,秉持规则。主持人不得发表意见也不能总结别人的发言
  • 秘书:形成会议的书面记录

    基本礼节

  • 任何成员只能对主席发言,即使要对另外一名成员发言,也只能通过主席
  • 成员在发言前要避开直接引用另外一名成员的姓名
  • 成员必须取得发言权才能发言,发言必须在时限之内
  • 不得进行人身攻击,只能就事论事
  • 主席对自己也只能用第三人称,不能直呼成员姓名

    动议

  • 由成员提出动议,动议必须是具体的,明确的,可操作的行动建议
  • 从文件或者报告中产生动议
  • 遗留问题中产生动议
  • 动议是会议的基本元素

    会议的过程

  • 提出动议
  • 另外一名成员附议
  • 附议不等于同意,即便不同意一个动议,也可以采取附议的方式让动议进入讨论,尽快用讨论来否决
  • 附议的作用是帮助主席确定动议是否值得讨论
  • 主席陈述议题
  • 主席通过陈述议题将其正式提交会议考虑
  • 主席需要准确的陈述动议的文字,并表示辩论可以开始了
  • 辩论
  • 发言前要取得发言权,并得到主持人的允许后才可以发言,发言要起立,别人发言的时候不能打断
  • 辩论过程中,每个成员的发言次数是有限的
  • 发言是有时限的
  • 发言必须以主席为发言对象,不能和其他成员直接对话,绝对不允许攻击其他成员的道德动机
  • 主席不能参与辩论
  • 只要还没有用尽辩论权的成员,主席就不能结束辩论
  • 主席有权打断违规发言的人,被打断的人应该终止发言
  • 发言人应该首先表明赞成或反对,然后说明理由
  • 主席应该尽可能让意见相反的双方轮流得到发言机会
  • 讨论问题不能跑题,主席应该打断跑题发言
  • 提请表决
  • 主席应该再一次陈述议题,保证全体都准确的了解当前要表决的问题是什么
  • 主席应该先请赞成方举手,再请反对方举手,但不要请弃权方举手
  • 无论正反表决结果多么接近一致同意,主席必须请反方表决
  • 宣布表决结果
  • 主席在提请表决之后,在反方表决之后,应该立刻起立宣布表决结果
  • 赞成方多于反对方,动议通过,平局等于没有通过
  • 主席必要时需要对不明朗的结果进行验证

    这本书本身还是非常好的,对于处理大型团队决策问题,定义非常详细的技术细节。比较类似的还有这个Hold a 22 minute metting.但是经过各种实践和思考之后,我觉得这些技术细节并不能解决会议效率低下的根本问题。首先,我们需要把会议分为两种大类型

  • 一种是在对一个事情还没有明确的组织开展思路的时候的核心决策会议
  • 一种是已经有明确的开展思路的时候向下面执行层面的人员传达的会议

    对于第一种类型的会议,显然要比第二种难很多。一般的讲会议方法的书籍都会强调会议前详细的准备,会后的会议纪要之类的技术细节,但是忽视了一个很重要的问题,就是会议如果讨论的是没有成型的东西,那么要求会议的参与人都必须对这个主题有比较多的背景理解,否则,会议讨论往往会陷入无关紧要的细节,无法达成共识,浪费大量的时间,这就是第一种会议面临的“本质复杂度”(essential complexity)。会议前准备之类的,能够降低“非本质复杂度”(accidental complexity)。但是无法解决会议参与人由于能力和对主题认识的问题,无法很深入讨论获得结论的能力。在讨论的时候,很容易分不清主次,陷入到和主题无关的细节中去,到最后大家精力都耗光了,主题反而没有结论。所以,我觉得对于第一种类型的会议比较可行的是:

  • 限定会议的时间,不能开马拉松会议,毕竟大家的时间都很宝贵,还有这么多事情要做
  • 在黑板上不断细化要讨论的主题,对于跑题的讨论,记录下来,留到以后的会议讨论
  • 如果限定时间不能获得结论,那么确定下次会议的主题和时间后,结束会议,但是在下次会议开始前,大家都要积极的思考主题,争取下次会议能得出结论,或者获得更深入的见解
  • 好好利用文档形式进行异步沟通,对于比较复杂的议题,可以提前以文字的方式,描述自己的想法,会后继续跟进的议题也可以是邮件和文档的形式进行,直到有需要面对面会议需求的时候再进行后续的会议
  • 提高个人能力,必须意识到会议讨论效率低最难解决的就是参与者能力不足

    研发的核心是沟通,而高效的进行各种讨论会议是沟通的核心,也是各行各业做大型工程必然面对的相同问题。所以其实可以从多种途径去了解,比如看历史,当年共产党是如何组织会议的?这里记录的只是目前阶段的理解,也许以后还会有新的想法,到时候再分享。

  • Tags: , ,

    1 comment

    1. [...] 游戏开发本质上是一个跨学科的大型协作项目,不同知识背景和思维方式的人在一起完成一个复杂项目想着就觉得很有挑战性, 最大的困难恐怕就来自沟通了,不少公司基本都会陷入会海之中不能自拔(当然之前公司也遇到过以马拉松会议为乐趣和权利象征的制作人,这就是另外的问题了)。但是依靠强大的体能(比如每天工作18小时,一周七天)。也能杀出一条血路来,不过这实在太不健康了。之前也写过相关的博客,这次再整理一下。 [...]

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>