成也会议，败也会议

成也会议，败也会议_20070918

项目进入编码阶段。本来时间是很紧的，大家都急着忙自己那摊子事儿。临近中午，leader通知：下午开会，讲解编码阶段需要注意的问题和共通部分的用法，时间是一点到五点。

会议的效果如何？当我下午五点四十提着瘪肚子从会议室出来时，我只能说，这四个半小时（一点十分会议才开始，所以是四个半小时）大概只有一半对我是有意义的。

本来，这样的会议应该是必要的，尤其对于我们这样一个成员能力参差不齐、新员工比例较大的团队。问题是，我们的会议总是存在一个不良倾向——喜欢跑题。当然，并不是说大家在工作时间闲扯怎么打CS，而是讨论的主题虽与项目相关但却总是偏离会议的预先设定。印象最深刻的是，某技术骨干本来是为大家讲解自定义标签的用法，但当有成员提出问题后（这应该是很正常的），对已定案的讲解变成了对未定案的探讨，这样的探讨又吸引了项目组中不同角色、有着不同思维、懂的或半懂的另外一大堆人。而对于我们这些只负责具体某模块，对其讨论问题不甚了解的成员，这段时间基本处于“鸭子听打雷”的状态，更不用提那些技术尚显稚嫩的新人了。

这样的会议有效吗？只能说对于充分参与到上面提到的讨论和其他形形色色的“跑题”中的成员是有效的，对于其他人，只是在浪费时间而已。

我的工作经验也并不长，一直也是在做member一级的工作，参加会议当然是听的多于说的，更不用提主持会议了。就我的主观想象，一个理想的会议应该是这个样子的：会前起码得告知与会人员会议主题，有个简要说明，告知需要准备哪些东西——这个我们还是做到了；会议一旦开始，主持者必须有足够的控制力，有跑题的迹象就要马上给拉回来——这大概是我们会议的问题。既然会议的主题是“讲解”，那就不要把“探讨”拿过来，那个东西可以在“方案讨论会”上进行，该什么时候干什么事，该是什么会就应该说什么话；再有，一个会议，应该只让相关人员参加，假设这就是个某标签做法的方案讨论会，那就只让参与设计和实施的成员参加，至多也就是让能听懂的人参加，凭什么让与此无关的人在那浪费时间浪费生命！当然，最后还有其他诸如会议记录等等，这里重在讨论“跑题”，就略去不提了。

文章题目的后半段叫“败也会议”，倒还不至于因为一个会议跑题就导致项目失败，不过这种情况多了呢？有其他因素存在呢？谁敢保证它不是压垮骆驼的最后一根稻草？