开会虽烦人，但该开的，还是得开好

工作中，估计没有人喜欢开会，但是无人能从中幸免。

我也很不喜欢开会。开会是非常消耗精力的，全程都要集中精神。就算不是主持会议，只是普通地参与会议，我都觉得非常累人。

每次开完会，回到自己的工位上，总感觉身体被掏空，脑子已经转不动了，好一阵子什么活都干不了。

但是，我并不排斥开会。

在项目推进过程中，有各种会议需要产品经理参与。有些还需要产品经理来组织、主持。那些必须要参与、必须要开的会议，没什么好说的。一些可开可不可的会议，我一般是倾向于，如果条件允许，还是得尽量组织各方过来开一开。

有时候因为各种原因，该开的会不开了，我反而会有一丝不安。

这是因为，“开会”虽然烦人，但是真的有用。

一、4类重要的会议类型

“会议”有很多种类型。这里我们只关注与“需求”、“项目”相关的会议。

普通小厂，一般不像大厂那么规范。每个项目，推进流程可能会很不一样，并没有一套被严格执行的规范。

哪些会要开，哪些不用，会议要怎么开，都是具体情况具体安排，比较灵活，或者也可以说，比较混乱。

概况来说：项目推进过程中，大概有以下4类会议，比较常见，也比较重要。

1. 项目立项的会议

顾名思义，就是评估需求是否有价值，确定是否立项执行。需求的发起人向各干系人阐述自己的想法，然后让大家评估其价值，商定执行方案。

与会人员根据自身立场，以及自己掌握的其他信息，提出意见建议，补充完善需求内容。这里面，一般没有我们初级产品经理什么事。我们参加会议，往往只是因为我们需要了解这个项目的各种信息，以便后续设计推进。

我们只是“听众”而已。

因此，有时候初级产品经理也可以不参加。等大佬们商定之后，由经办人把会议结果告知我们就可以了。

2. 明确需求范围与内容的会议

立项之后，这个项目还是一个粗糙的想法。这时候，产品经理需要制作PRD初稿，将这个粗糙的想法，变成一个范围明确、效果可预期、内容可执行的方案。

一般来说，这个PRD，10%是立项会议讨论确定的，20%是产品经理私下找干系人咨询讨论确定的，还有70%是产品经理自己脑补的。因为大佬们是不管实现细节的。

因此，当产品经理完成PRD初稿后，需要重新召开会议。这一般需要产品经理来组织、主持。会议的主要内容是介绍PRD内容，并讨论其中有争议的部分。

因为开始涉及到执行细节，所以这类会议耗时往往会比较长。一两个小时以上，都是很常见的。

根据项目情况的不同，这样的会议可能需要召开好几轮。讨论、修改PRD、重新讨论、再修改PRD……

经过多轮会议，最终确定需求范围以及各内容细节，确定PRD终稿。

3. 面向技术团队的需求说明会议

虽然在前面的会议中，技术团队有时候也会参与。但那时主要是负责把控项目的技术可行性。

当需求完成策划设计，进入开发阶段时，有时候产品经理需要组织相关技术同事一起开个会，介绍需求的整体情况。

这时候的重点就不再是讨论需求内容，而是明确传达产品经理的项目要求，并讨论各处的技术实现方案。有时候还需要在会议上完成任务分配，确定开发计划。

4. 围绕某个具体开发问题的小会议

开发过程中，出现问题，一般我们会在各种工作群中协商讨论。如果问题比较复杂，无法在工作群中说明白，这个时候就需要让各方碰头开个小会。这类会议，是临时性的、突发的。

如果是比较复杂的项目，这类小会议会比较频繁。与会的一般是产品经理和相关的技术同事，有时候也需要业务部门参与。

二、开会的2个重要作用

我们不喜欢开会，一个很重要的原因就是，认为开会没有用。开会要占用我们的工作时间，影响我们的工作进度。但是同时，却好像没起到什么作用，完全是形式主义，为了开会而开会。

比如上面说的，面向技术团队的需求说明会议。

有时候，产品经理讲了一两个小时，讲得口干舌燥，结果下面的技术同事很多都没有在听。很多会上强调的细节，之后还是照样会出错。

那这样的会议，又有什么意义呢？

其实，我们认为开会“没用”，是因为我们对会议“作用”的预期不对。

还是上面这个例子。其实，阅读和思考，始终都是一个人的事情。产品经理在会上最多也只能说个大概。技术团队最多也只能听个大概。会后，还是需要自己一个人，去一字一句阅读PRD，去思考每个细节的具体实现方案。

那么，开会到底有什么作用呢？

我认为，开会有2个重要的作用：

1. 实现多方同时在线的高效讨论

“多方同时在线”，相对应的，就是“单独私下”的讨论。