# 3l 会议、独白和交流

一些组织开会开到上瘾，以至于把工作放到了第二位。他们组织会议没啥目的性，也没明确定义什么是会议结束。一些组织则会走另一个极端，害怕会议浪费时间，以至于他们谈“会”色变，这当然也不对。对待会议不偏不倚才是合理的。

### 神经硬化

随着一个组织的老化，会议时间逐渐增多，到组织弥留阶段，就只剩下开会了。至少现实看起来就是这样。这自然是事出有因，出发点往往也是好的，但效果却适得其反，甚至有机会让竞争对手在远处悄悄偷笑呢。当任何行动的参与方人数增加时，会议就会变得越来越流行。会议可以带来更多的信息透明，这对任何想在层级森严的大公司升职的人来说都是非常重要的因素。别人对你的关注不在于你听得多仔细，所以，为了信息透明来参会的人更多会寻求发言机会：最糟糕的会议就像是一堆空谈者的集会，没有人听别人说什么，每个人都只顾着表达自己的意见或者等着表达。因为有这么多人需要发言，会议时间自然被拖长到不受控制了。

当每个人都痛惜这样的会议占去太多时间时，很多管理者却借口这类事情是不可避免的：不可避免是因为组织正在尝试完成复杂度巨大的事情。复杂度巨大这个提法当然是让每个人都感觉能够接受，因而，一旦这成了会议的正当理由，就没有人会去思考另外一种可能：竞争性的空谈。

### “科技手段增强”的会议

现在进入了科技时代。先辈们面对这些糟糕会议时常常无处可逃，我们却有了自己的手提电脑。当会议变得无聊时我们可以打开电脑……唉，这可能还不够明智——更好的是在开始会议时就打开电脑，这样至少不是在哈利站起来讲话时，让他知道我们都走神了。

所以，那些无聊的会议时间就是处理收件箱里无数邮件，或者偷看几页 Facebook 网页，或者给同在会议室里坐对面那个可怜家伙发条短信的好机会。说不定还能完成点真正的工作……

现在，我们已经了解到科技增强能够给你的好处，随之而来的一个问题是：它给会议本身带来了什么呢？让会议更好，对吗？更有效、更快捷？得了吧，我们要严肃点！当然可能有这么一个时刻，一个管理者说：“你们开着电脑的人，上网去查查我们（至少是他提到的）的市场今年有多大，未来的趋势预测如何。”这可能发生，但不会很额繁 j 对应这一次对会议相关信息的查询，可能有上千次是与会议完全无关的。

这就是冲突之所在：在会议上广泛使用的科技对召开会议一点用处没有；这些科技仅仅是为参会的人们逃离毫无意义的会议提供了便利。科技增强带来了会议的沉闷可怕，我们现在的会议比前辈们的还要糟糕，因为前辈们不需要忍受这样的会议——他们可能早就站起来抗议了。

现在能够接受的行为，放到过去可能会让你被解雇。

### 站立会议

比较新的方式是站立会议，一般是在一个空地方（没有桌子椅子）让所有人都站着。理论依据是站着会让大家都不太舒服，所以不太可能空谈。我们觉得有道理，但带着批判的眼光，我们觉得最大的收益还是在站会上没有地方放电脑，所以大家都没法玩电脑。不管出于什么原因，这样的会议会精短一些，因而大有裨益。

即便是这样的站立会议，如果没有目标和主题也会拖组织效率的后腿。那么，会议的目标和主题应该是什么呢？这就取决于会议的种类了。

### 基本的健康会议

为完成一件事情而专门组织的会议可以称为工作会议。（我们假设其他会议为非工作会议，下节再细讲。）举办一次典型的工作会议就是为了要达成一个决议。需要谁参会呢？很简单，那些对决议点头的人。其他人就不需要了。为了保证大家都不会茫然，工作会议都需要一个相关的日程安排，有明确的目标并且能够执行。这样可以保证即使不参会的人也能知道会议安排，不在日程上的话题是不会被讨论的。没人需要带着防御心理去参会。

工作会议有一个吸引人的特质，你们知道会议何时完成。一旦达成决定，就不需要继续开会了；当决定没有达成时，会议就还没完。

反之也是一样：如果你们能够确定结束会议的条件，那么这就是一个工作会议；否则就不是。

要是你将上述理论运用到你的下一个会议上，你基本可以断定它不是一次工作会议。不是的原因是没有集体的互动来结束会议：结束会议是因为时间。现在 10 点了，会议该结束了。

### 仪式

迫于时间而结束的会议是一种仪式。这种会议的目的不是达成某个特定的决议，都是 FYI（for your information，仅供参考）。这种 FYI 通常都是在特定礼仪下开展的：老板进行快速介绍和宣布，然后就是老板和下属的一系列一对一交流。在任何时刻，就只有两个人在交流，其他人名义上都基本在听，当然是名义上的。如果他们有手提电脑开着，那他们的关注点都在其他地方。

仪式是一系列的对话，对话本身是件好事。不好的是那些并没有真正倾听的人被关在了对话发生的屋子里。那些相信这样的会议应该被对话取代的人，很容易观察到这样的一对一可以在其他地方发生，从而放开其他人让他们去做真正的工作。

工作环境中不时会有真正需要这样仪式的时候。仪式可能是庆祝某次成功、给大家讲解战略方向的改变，或者评估一个即将结束的项目。这些正当的仪式都有些不同寻常之处，这些不同寻常之处也是为什么正当的原因。常见仪式的一个例子是每周（每天！）的项目状态会。会上，十几二十个人被锁在一间屋子里轮流向老板汇报工作。

### 太多参与者

工作会议的参与者仅局限于利益相关的人，人数越少越好。仪式会议的参与者就没有限制了，只要负责人认为有价值参加的人都可以来，人数多一点更好。会议发起者的重要性直接决定了参与者的数量，当然谁都希望搞大一点。

“开放式组织”的幻想让情况更糟糕：

我的一个新客户，表面看来是一家充满生机的新兴技术创业公司，也许会成为下一代的苹果。可是内在却大相径庭。我被邀请参加他们的会议，每一个管理者都出席了。我一开始还以为他们的出席是因为我的到来，还感到有点受宠若惊。但接下来几天的会议都一样：所有管理者都参加了。在这些会议上（不管名义上的主题是什么），总会发生的一件事就是讨论将人员从一个项目调整到另一个项目。没有管理者敢缺席会议，害怕自己的人被拿走。他们为自己开大会找的借口是他们是开放式组织。真正的原因其实是大家都是防御性的被动参与者。 -TDM

下面是一个简单的数学计算，但值得一说：会议的成本直接取决于参会人员的多少。我们有一个客户是苹果的一名管理者，每次在开会前都会让一个人离场。她允许那个离场员工在离开前进行简短的陈词。她清楚地告诉大家选择的标准并不是这个员工相应的能力，而是他用会议时间可以完成工作的重要性。真正从释放一名员工身上得到的收益并不大，但这种行为传递的信号却不可或缺。

### 开放空间社交

如果你曾经参加过专业的会议或演讲会，你很可能得出和其他人一样的结论：会议和演讲都是烦琐的事物，真正的价值体验在那些间隙时间，一段演讲开始或结束等待的公共区、茶歇休息、午餐排队、与其他参会者一起饮茶或聚餐的时间。基于这些事实，一些有思想的人开始形成“开放空间”的想法。一次开放空间的会议完全就是茶歇和午餐。当然事实会比这要复杂一些，但你知道我们想要表达的。那些会议上没有正式的演讲，完全只是在社交。

同样的想法可以用在会议计划上。作为一名新人职员工，你在组织里的开放空间会议上的体验大致是这样的：你接到老板通知，员工会议在周五早晨 9 点钟召开。你 8 点半就出现了，泡了一杯咖啡，然后坐到一个新人旁边，开始聊你们昨天未完的话题。有人加入到你们的对话中，互相做了介绍。她了解到你被分配的领域，然后告诉你她在那个领域的经验。

这时，老板进屋了，你晃到他面前报道。他给你介绍了一位和你被分配项目使用相同硬件的员工。你俩交换了邮件地址，约定当天中午一起吃工作餐细聊。你偶然听到旁边在聊一个让你一直很着迷的话题，你凑过去想听仔细，又担心在你这个陌生人加入后大家不聊了。大家并没有这样，而是欢迎你加入，给你介绍他们之前在聊的事情。

现在，9 点过了好一会儿，怛会议还是没有正式开始？你去自助餐桌那里又泡了一杯咖啡，遇到一位来自支撑团队的人，和他聊了聊。最后，9 点 20 分，老板拍掌引起大家注意，然后说：“今天很不错，谢谢大家来参加。下周同一时间这里见啦。”然后他离开了……

这就是你第一次参加开放空间会议的经历。没有真正的会议，只是一个长时间的间隙。

### 治愈会议上瘾组织的处方

你改变不了你的上级，但你可以改变你的地盘，还有那些和你一起工作的同事和下属。这种改变总是知易行难。你的目标是消灭大多数仪式性的会议，而将时间花在一对一的交流上，通过运用“会议怎样才算结束？”的测试来限制每次参与工作会议的人数。要是需要什么仪式，则鼓励大家用开放空间社交来创造非结构化的自发互动。最重要的是，削减你自己需要用仪式会议来做确认的需求。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.shiker.tech/ren-jian/di-wu-bu-fen-wo-tu/3l-hui-yi-du-bai-he-jiao-liu.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
