本文介绍了4类重要的会议类型、阐述了开会的作用以及在小产如何开会的方法。

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

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

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

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

但是,我并不排斥开会。

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

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

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

一、4类重要的会议类型

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

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

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

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

1. 项目立项的会议

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

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

我们只是“听众”而已。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、开会的2个重要作用

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

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

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

那这样的会议,又有什么意义呢?

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

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

那么,开会到底有什么作用呢?

我认为,开会有2个重要的作用:

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

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

A向B提出要求。B把要求告知C。C向B询问某些细节。B发觉自己也不清楚,因为A没说到这个。所以B又重新去问A。A回复后,B将A的回复告知C。C说B理解错了,不是这个意思。于是B再重新去问A……

这种可怕的“传声游戏”,想必大家在工作中都碰到过。

相对于这种“单独私下”的讨论,将相关的各方拉在一起讨论,效率的提高是巨大的。而且,多方一起碰头讨论,还能极大地避免错误。

我曾经碰到过这样的情况:

A误以为当前系统没有某个功能,所以在和B的讨论中,确定了无需使用该功能的次优方案。

作为执行方的C,他接到B传达的需求后,就感到疑惑。因为当前系统已经有该功能了,完全可以采取最优方案。

然后C向B询问。

B明确说了,A在最优方案和次优方案中,选择了次优方案(虽然不知道理由),这是已经决定好了的事情。

C想,那可能是有其他的限制吧,没办法,那就按次优方案来搞吧。

像这样的误解,越到后面就越说不清。而如果,一开始大家一起碰头开会,那么错误从一开始就能避免。

2. 确保向各干系人传达项目需求

比如上面说的,面向技术团队的需求说明会议。其核心作用,某种意义上讲,其实在于:确保有效地通知到技术部门各团队的各成员:“我们现在要做这个项目了。”

你可能会疑惑,我们发个工作邮件不就可以了吗?

其实不然。

我举个工作以外的例子。

大学时,体育课要上什么,是自己选的。同一个行政班的同学,可能有的人上篮球课,有的人上足球课。我当时上的是排球课,是这个课的体委。这个课有不同专业不同行政班的同学一起在上。每个行政班内有他们自己的体委,管理他们自己班的同学。

有一次,我需要通知大家,下一节课要在室内上理论课。

所以,我通知了各专业各行政班的体委,让他们自行通知自己班里的同学。作为一个理科生,我看不出这个“信息传递”模型有什么问题。但是,最终来上课的人,不到3成。

理由有很多。有的是忘了通知,有的是通知漏了,有的是以为非强制参加……

信息如何准确及时传达,其实是一件比预想中要复杂得多、困难得多的事情。我们“浪费”几个小时,把相关人员都聚集起来,告知他们接下来我们要做的工作。大家来了,意味着“知晓”了;然后走了,意味着“同意”了。

后续我们推进项目时,让相关业务部门配合,让技术部门各团队配合,阻力就会比较小。

我之所以说,有时候该开的会不开了,我反而会不安。这是因为,在普通小厂,团队组织往往是比较混乱的。

如果没有“确实”地完成告知工作,那么项目推进过程中,很可能会突然发现,部分团队因为各种你想不到的原因,居然不知道这个事情,工作现在还完全没有开展。

这就非常可怕了。

三、普通小厂会议怎么开

普通小厂的会议,一般比较随意。

一些关于开会的方法建议,在这里很难发挥作用。

会前分发的资料文件,一般不会有人看。

会议流程基本不存在,有时候开会就像是在开下午茶会。

会议记录这种东西,基本也是没有的。

但这些都没关系。我们不需要开一个“规范”的会议,只要能达到目的就可以了。

产品经理需要经常参与各种会议,有时候还需要负责组织、主持。除了一些常见的注意事项外,这里我根据我的经验,分享2个比较重要的点。

1. 尽可能让所有干系人参与会议

如上面说的,有时候,会议内容本身不重要,“参与会议”这个行为本身才是开会的目的。所以,当我们在组织会议时,需要尽可能让所有干系人都参与。

如果项目涉及多部门,就必须让所有涉及部门都派人参加。哪怕不参与,也得确保该部门负责人知道这个项目。不然,后续各部门间的配合就会出问题。

如果项目比较复杂,或者技术上有难度,就必须在早期的会议上就让技术部门参与。让技术负责人提供可行性建议。

如果有些部门平时不太配合,就需要尽早让其参与到会议中,让这个项目变成“我们”的项目。

如果这个项目领导很在意,就需要在组织会议的时候,询问领导是否参加。我们需要尽量让领导来参加。不然,有可能我们讨论了半天,结果偏离了领导的预期。然后领导一句话,所有工作就都白费了。

2. 必须要得到明确的、可执行的结论

普通小厂的会议,没有严格的“会议流程”。

有时候,上一句还在讨论这个问题,下一句突然就开始说那个问题了;有时候,对于一个问题,有人说了这个方案,有人说了那个方案,然后大家没有进行表态,就开始下一个话题了。

我们初级产品经理,是负责具体执行的人。所以,我们需要对“结论”非常敏感。

具体要怎么执行,如果没有说清楚,一定要打断大家,提出疑问,让与会人员给一个明确的结论。

“所以,具体我们是要……,对吧?”

“现在我们说了3种情况,第1种情况是要……,第2种情况是要……,那第3种要怎么处理,现在还没确定吧?”

具体怎么执行,结论我们一定要确认清楚。

四、小结

开会,本质上是一种信息传递的手段。

在组织比较混乱的普通小厂,我认为,很多时候,开会是一种不可替代的沟通手段。

看似低效,其实有大作用。

虽然开会烦人,但是该开的,还是得开好。

作者:简明产品论,微信公众号:简明产品论(ID:JianMingPM)

本文由 @简明产品论 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。




互联网人如何进行知识管理?

互联网人如何进行知识管理?

信息爆炸时候,我们每天都吸引了大量知识信息,而庞杂混乱的信息难以为我们提高有效的帮助,我们需要做的就是进行知识管理,通过方法窍门高效利用起来,提升自我。 01 ...

2020-06-19
产品总监晋升之道,游戏思维的团队管理艺术

产品总监晋升之道,游戏思维的团队管理艺术

作为一个产品总监,在面临年轻的团队,如果你的管理方式有问题,对团队乃至整个公司都是一件特别大的灾难。所以,今天我们来聊聊产品总监的团队管理问题与游戏化的团队...

2020-06-19
一个公式,从作品集小白修炼到初级交互设计师

一个公式,从作品集小白修炼到初级交互设计师

本文作者从自己个人经历和想法出发,从三个转变的角度谈谈如何从作品集过渡到行业项目,希望对所有刚刚踏入产品或交互行业的新手们有所帮助。 一、前言 在经历了半年多...

2020-06-18
2020年应聘反思,我总结了这些点

2020年应聘反思,我总结了这些点

在职场生涯中,我们可能会在好几家公司工作,重新应聘必然会遇到很多的问题。本文作者基于自身经历,从五个角度总结了自己的应聘经历,分享给对求职迷茫的童鞋。 先简...

2020-06-18
掌握砍价中的六大用户心理,轻松搞定甲方需求

掌握砍价中的六大用户心理,轻松搞定甲方需求

本文总结了砍价哲学中的六大用户心理,并结合案例对每个用户心理展开了分析说明。沟通的最大技巧是真诚,而谈判的目标是共赢。希望掌握好这六大用户心理,能帮助你更好...

2020-06-17
进大厂,还是进小厂?

进大厂,还是进小厂?

选择大厂还是小厂,对于很多人来说,是难以抉择的。大厂和小厂都有各自的优势、缺点,本文作者结合自己的个人视角,谈谈在大、小厂的经历和感悟。 职场也像个围城,在...

2020-06-09
网易严选交互团队的管理方式进化史

网易严选交互团队的管理方式进化史

管理团队是一个艰巨的任务,不仅需要管理者的智慧,也需要具备相关的管理知识。本文作者从具体的工作分工、文档管理分发和人员培养这三个方面出发,分享了网易严选交互...

2020-06-08
如何通过一张表,提高20%的工作效率?

如何通过一张表,提高20%的工作效率?

在日常工作中,每周的工作都充实而有所沉淀吗?是否觉得自己在假忙碌?如何有序推进工作进展,有序记录自己的工作?本文作者结合自身实践,讲述了在方法论上对自己工作...

2020-06-08
2020年,转行数据分析师需要注意哪些问题?

2020年,转行数据分析师需要注意哪些问题?

随着大数据在各个领域的应用越来越广,数据驱动产品和精细化运营已经成为企业经营的制胜法宝,相应地,数据分析师这个岗位也越来越受到关注。2020年,还能转行数据分析...

2020-06-05
京东群面题|如何用0.01元买到一瓶可乐?

京东群面题|如何用0.01元买到一瓶可乐?

这是一道京东的群面题,作者给出了一个简单的回答思路。 任何交易都遵循等价交换原则,如果一瓶可乐价格为0.01元(正常售价约为2.5元),那么必然需要其它形式的价值填...

2020-06-05
“空降型”产品经理快速入场指南

“空降型”产品经理快速入场指南

无论是内部调岗,还是职场跳槽,许多产品经理都必须面对融入的问题。就如一个空降兵,面对历史遗留问题,和现实的剧震,依旧需要义无反顾地发起冲锋。除了需要勇气,更...

2020-06-04
腾讯产品能力框架之通用能力篇:执行力

腾讯产品能力框架之通用能力篇:执行力

执行力就是以目标为导向,以结果为准绳。本文讲解腾讯产品能力框架中的通用能力——执行力,从五个层级分解学习能力,助力职场人走得更远。 本文是产品能力框架的第三篇...

2020-06-04
如何正确构建和使用产品知识库?

如何正确构建和使用产品知识库?

产品知识库的价值不在于文章数量的多少,所以不要刻意追求更新频率和更新数量。能够运用知识库去解决实际工作中遇到的问题,这才是其真正的价值。 1. 什么是产品知识库...

2020-06-04
解决80%以上职场冲突的认知方法——事实最大

解决80%以上职场冲突的认知方法——事实最大

事实最大。你掌握的事实越透彻,也就越强大。 日常人和人的沟通中,80%以上的冲突和挫败,来自与“事实”有关的两个问题: 问题1:没有基于事实来沟通。 假如,你是一位产...

2020-06-04
面试最烦的一种人——刷面经、背题型、找套路

面试最烦的一种人——刷面经、背题型、找套路

正如上次写群面的文章说的,群面的目的是做一名合格的「Horsekeeper」,而不是去想着争风头、当leader、抢reporter这些花里胡哨的。同样单面也不是刷面经、背题型这么简...

2020-06-04
我的14年设计路:从新人到设计总监

我的14年设计路:从新人到设计总监

从初入职场的野蛮生长到独当一面的设计总监,作者在职场摸爬滚打了十四年,分享自己的经历和总结,希望对你有所帮助。 最近,我从蘑菇街辞职了,我在这家公司一共呆了9...

2020-06-03
转岗交互前,我做了哪些准备(下)

转岗交互前,我做了哪些准备(下)

从UI设计到交互设计,作者回顾了自己的转岗之路,对过程中的经验与思考进行了总结,希望能对你有所帮助。 上篇文章我分享了交互设计师的产出物和我是如何学习交互设计...

2020-06-02
从职场菜鸟到独当一面,这三点建议要牢记

从职场菜鸟到独当一面,这三点建议要牢记

刚步入职场的新人最希望的就是能够以较快的速度成长起来,具体应该怎么做呢?本文给出了三点有用的建议。 现在外部大环境不是太好,就业压力巨大,岗位的竞争尤为激烈...

2020-06-02
我花了两年,成功把自己「毁」掉了

我花了两年,成功把自己「毁」掉了

初入职场的年轻人总是特别害怕和迷茫,不知道该怎么在职场中生存。本文作者将用自己两年的职场经验,告诉你什么路该走,什么路不该走。 毕业后的时光过得很快,今天是...

2020-06-01
锅背得冤不冤?产品经理的丛林生存法则

锅背得冤不冤?产品经理的丛林生存法则

甩锅体质:趋利避害是人的本性,甚至是动物的本性。产品经理作为被重点甩锅的对象,可以有108种背锅方式。究竟产品经理的黑锅,背得冤不冤? 一、锅都有哪些? 1. 进度...

2020-06-01