如何应对五种类型的会议

如果邮件不管用，那可能是到了要开会的时候。开会可能会痛苦，也可能会高效 甚至快乐（是的，你能让开会变得快乐）。让开会变得快乐的最佳途径是理解每种会 议的结构、目的和效果。下面有五种你需要掌握的会议类型，排名不分先后。

1. 团队会议

这类会议用来了解近况以及利用团队合力来深入讨论和解决特定问题。虽然团队 会议中解决的大多数问题理论上通过邮件也能解决，但只是理论上而已，所以你还是 需要这种会议来承担这些工作。

2. 站会

站会是一种超级简短的会议，它只用来交流近况，促使团队内部信息透明、责任 到位。在会议中每个人都站着，这样可以帮助保持会议的简短。

3. 1 对 1

1 对 1 会议是指只有你和另外一个人之间的会议。这类会议或许是最值得开的，

因为在会议中你们能坦率地交谈。而且会议也给了你们专门时间来完成需要互相协作 的任务。

4. 产品 / 工程 / 用户体验评审

这是一种大规模会议，通常会有一些大老板参加。这个会议既要向高管通报产品 进展，又要收集组织内最富有经验的人们的反馈建议。团队需要仔细准备这类会议，

如果搞砸了，项目势必被要求重来，所以从这个角度来说这类会议是相当昂贵的。

5. 头脑风暴会

这是所有会议中最有趣的，它形式自由，能激发想法，还能让团队主动参与到问 题的解决中去。

10.2.1  团队会议

团队会议每周开一次，每次30~60 分钟，你和你的工程团队需要参加，一般由你 主持。如果团队中有技术主管或高级工程师乐意主持会议，当然可以，交给他吧！这 类会议的目的是促使团队坚守使命并就当前一些悬而未决的问题达成共识。议事日程 需要提前发布。等到开发快要结束时，促使坚守使命和达成广泛共识通常就没那么重 要了，你可以考虑取消这类会议并改成开站会，取消的最佳时机是你开始跟踪Bug 燃 尽图的时候。

当你开始团队会议的时候，一个不错的开场方法是先回顾你的数据指标。你需要 知道产品或开发有什么进展。它们有任何中断或显著变化吗？例如，鲍勃是不是花了 整整一个礼拜的时间在家陪他的猫？或者萨里是不是发现了一些不得不尽快解决的隐 私问题？除此之外，你的时间表上的事情完成得怎么样了？通常这个时候大家需要打 开笔记本，更新项目跟进表中的各个相关字段。

如果第一次在会上发现有人在走查电子表格并一边编辑它一边大声说出来，你 可能会想：“太疯狂了，我们应该提前把这个事情做完。”你是对的，这是最理想的做

法，但不现实。鉴于工程师完全有能力做任何事，如代码评审、编写测试或浏览 xkcd.com，所以他宁愿去做这些事情，而不是更新团队电子表格。在团队会议中，这 个工程师就像笼中鸟，干不了别的了，于是他就有闲情更新表格了。除此之外，在讨 论细节时，工程师可能会解释为什么一些任务花费的时间比预期更长或更短。这些解 释很有用，因为其他团队成员可能不知道你搭建的系统是这么扯淡还大小写敏感，这 只是一个例子。要知道在现实生活中越不想其发生的事情越可能发生。

你还可以利用团队会议来达到更高层次的目的。在季度开始，我会重新审视团 队季度目标，并调整目标直到所有人都认同。在季度中间，团队会议可以确保你不会 在方向盘上睡觉以至于团队状态“哗”地从绿到红，或许至少可以让团队状态先从绿 到黄，再从黄到红。在季度结束，我们会在团队会议上评估我们相对于目标的进展情 况。如果你遵循了这个过程，你的团队将能始终把控未来，坚守项目目标，专注做正 确的事。

当项目计划表更新完毕，即会议的信息更新部分结束后，你或许需要聊下所有需 要团队成员知晓的最新进展，这些重要进展包括行业变化、业务近况和其他与使命相 关的事项。切记，确保团队坚守使命是你的工作。

会议的最后部分专用于讨论并解决那些悬而未决的问题。在会议开始时收集需 要团队讨论的问题清单，再在信息更新部分结束后逐一讨论清楚。做好记录，指派任 务，然后处理下一个问题。处理完这些问题后，问下团队是否还有其他的东西需要讨 论。等7 秒看下是否有人回应。7 秒的安静时间似乎很长，让人感觉颇不自在，但它 却足以让你团队中最内向的人也可以无保留地发表意见。总而言之，开团队会议比不 开好，哪怕这个团队会议超级简短。它使得团队有机会以一种不同的方式聚集在一 起，它还提供了喘息的时间。因此即便我认为没有什么东西需要讨论，我也会召集一 个简短的会议来和团队碰一下。我发现在那安静的7 秒钟去凝视团队的不同成员，会 经常挖掘出令我吃惊的东西。

10.2.2  站会

Scrum 和敏捷开发的拥护者都信赖每日站会。最有成效的站会的确要求每个人都 站着。之所以存在这样一个真实的站立着的会议，是因为它可以使人们离开他们的电 脑并站起来，这样他们就没那么舒服，会议也就不得不尽快开完。我喜欢每天开一次站

会，因为这能促使团队内部责任到位、信息透明。每个人在站会中应该汇报下列信息：

的特点也使得它很适合用来完成需要合作的工作。当你在1 对 1 会议上和对方一致同 意发一封邮件时，你可以轻松花2 分钟时间把邮件发出去，而不需要记下来并等到会 后再去执行。这种做法能让你不用会后再花时间回想当时做决定时的背景，还能减少这 项任务未完成的几率。同样，你和你的市场主管也能在30 分钟的 1 对 1 会议上花 15 分 钟来共同修订博客文章的第一段。在会议过程中完成工作是1 对 1 会议的精髓之一。

请安排每周或每两周与所有主管开一轮1 对 1 的会议，即便你觉得没有必要。1 对1 会议时间的长短取决于你需要处理什么事情。30 分钟是一个不错的起步时间，50 分钟也不是不可能。你可能会议中间发现一些你并不知道但也需要讨论的事情。如果 几周过后会议不再富有成效，你可以取消它，或者改为每月一次。

10.2.4  产品、用户体验和工程设计评审会

任何种类的“评审会”通常都是有大老板参加的大规模会议。其中产品评审会 的首要目标是让老板们认可你的产品方向，提供给你反馈，或让他们知道你的最新进 展。后面“如何做好演示”一节中的所有建议也适用于评审会。你要先想清楚你要传 递的确切信息是什么，然后尽可能清晰、简洁地传递出去。由于这些会议的参与者通 常都很忙，最好将会议时间控制在30 分钟以内。

用户体验评审会则只需要准备产品原型图就可以了。最好让设计师演示他们自己 制作的原型。在设计师演示之前，你应花一小段时间为演示做一下铺垫，讲一下为什 么你在这儿，你的用户是谁，你的业务目标又是什么。你也可以亲自来演示，但前提 是你的设计师是一个极其内敛的人，且过往经验表示你更擅长这种面向更高层次的走 查演示。

工程评审会的目标是：赋予开发主管权力，收集周围经验最丰富的工程师的专业 反馈，以及尽量少花时间在演示上。请提前审读材料，以免开发团队提出一些使命之 外或与策略相悖的东西。如果将使命和策略成功传达给了团队，你就不会有任何问 题。如果你不是负责演示的工程主管，则需要在评审过程时应对高官们踢过来的弧线 球：“等等，为什么我们要构建X 特性呢？”通常这些问题最好让工程主管来回答，因 为回答这些问题能让他感觉自己被赋予了权力，而这正是你的目标之一。但这些问题 常常会令你的工程主管措手不及，这时候你要赶紧补位。你肯定不想让他们认为你的 团队对未来一无所知吧。

10.2.5  头脑风暴会

暴出所有答案背后可能的原因，如此一而再，再而三，直到他们得出所有问题的根本