15 | 如何组织有效的会议?
下载APP
关闭
渠道合作
推荐作者
15 | 如何组织有效的会议?
2018-05-24 曲晓音 来自北京
《硅谷产品实战36讲》
课程介绍
讲述:丁婵
时长11:41大小5.88M
产品需求讨论会对产品经理来说是家常便饭。
当产品经理对我们应该解决什么痛点、有哪些功能有了一个计划,接下来就需要组织产品需求讨论会了。我会和工程师、设计师等团队成员坐在一起讨论对这个功能的看法,跟他们讲讲这些功能一步一步的体验是什么样的:设计师是不是觉得这个设计是以人为本的;工程师会不会说我们的底层结构不支持,这个根本做不了。
简单地说, 产品需求讨论会目的是要明确我们的功能、量化成功的标准和时间表,团队成员达成一致意见后就开始撸起袖子努力干了。
首先,我跟你分享一个失败的产品需求讨论会,通过这个例子让你明白会议低效的几个常见原因,以及组织会议的几个误区。然后,针对这个案例的具体情况,我会告诉你怎么才能提高产品需求会的效率。最后,我会结合以前自己踩过的坑(说多了都是泪啊),跟你分享几个组织高效会议的独门秘诀。
案例:一个失败的产品需求讨论会
前段时间,隔壁组的产品经理组织了一个产品需求讨论会,讨论一个由他们主导的新功能,因为这个功能需要和我们合作才能实现,所以我们组也被邀请去开会。这个产品经理写了一本厚重的产品需求文档,组织大家每天一个小时讨论这个文档。
这个会议共有 21 人参加,包括:我们组的产品经理、工程经理、工程负责人和运营经理,他们组的产品经理、高级工程经理、工程经理、工程负责人、5 个工程师、2 个律师、设计师、设计师经理、数据科学家、用户体验调研师、运营经理、运营专员。
如此多的人员每天聚在一起一个小时,逐项地讨论这个需求文档,进展非常慢。在第五天的时候,他们的高级工程经理忍无可忍,当场问责:“每天在这里浪费时间,结果什么都没有讨论出来,这个模式根本不行”。这个产品经理瞬间不知道该怎么办了。
这次的产品需求讨论会,可以说是我在 Facebook 三年多以来开过的最杂乱无章的会。那么,我来给你分析一下这个产品需求讨论会失败的原因,其实这些原因都源于对产品需求会认知的误区。
以为开会要让全组的人都有参与感,所以邀请了所有人,导致参会者众多。这个新功能是针对众多媒体公司的,有点类似企业软件。它是一个复杂的工作流,涉及非常多的情况,每种情况对应的逻辑都不同,而且要符合对应的法律、政策等要求。
其实真正懂这个功能的也只有三四个人,但是团队其他成员都想参与进来,可以对产品功能做一些决定,而这个产品经理也希望可以讨好团队的每个成员。所以,会议的大部分时间都花在给这些不懂产品的人解答最基本的问题上,因此效率非常低。
以为多开几次会,多聊聊,效率会很高,但是大家都有很多会议要参加,因此每次开会都有不一样的人缺勤,导致会议效率低下。 每次开会都要跟上次缺席的人同步进度,往往会议开始的前十分钟甚至更长的时间,都浪费在这里了,这就导致了会议效率特别低下。
以为开会的目的是要从头开始逐项讨论,并得到大家一致的认同,所以细节讨论占据了会议大部分时间,反而来不及做重要的决定。 会议的模式决定了,如果一个成员有疑问,大家就都要停下来解决这个问题,一个小时很快就过去,于是未来得及做的重要决定又要第二天的会议来讨论。
那针对这样的情况,通过怎样的方式才可以避免呢?
一鼓作气 ,并设定一个需要作出决定的时间。
比如,这个复杂功能的需求讨论会可以把大家集中在一起 5 个小时,将 100% 的精力投入到整个会议中,一次搞定而不要分散成多次进行。如果这 5 个小时讨论不出结果,可以设定一个截止日期(比如周五之前),如果讨论不出来就加班继续讨论。
人类其实是一个很有意思的物种,没有截止日期的话,大家就会觉得有的是时间,拖来拖去;如果设置了截止日期,大家就会觉得工作压力大,最终争分夺秒赶在截止日期的时候完成。
所以,即使不知道这个会议需要多久才能开完,也一定要设置一个截止日期,哪怕到时候没能完成,往后推两天也比没有截止日期的效果来得好。
分工明确,减少参会人数。
可以先开一个项目启动会议。你可以邀请团队所有成员参加这个启动会,告诉他们这个产品开发的背景知识、调研结果、核心原则等战略和原则性的内容。比如,对于网红新的赚钱方式的讨论,你可以告诉大家一定不能允许网红自行植入软广,这样才能保证我们可以控制营销内容和普通内容的比例。
按照工作内容划分小组,并确定每个小组的成功标准、具体负责人,然后每个小组分别开会。这个小组划分的工作可以在项目启动会上完成。在这个案例里,你可以成立一个小组专门负责法律问题,小组成员包括律师、运营人员;再设置一个小组负责帮助网红适应和开启新的功能,小组成员包括用户体验分析师、负责增长的工程师、数据科学家等。
每周召集所有成员开一次会,有每个小组的负责人汇报工作进度,并解决他们遇到的问题。这样既可以满足其他成员了解整个项目进展的需求,增加他们的归属感,又可以减少每个决定需要的人员数量,提高会议效率。
组织成功产品需求会的秘诀
根据我自己的工作经验,以及所见所闻,我给你总结几个产品经理组织高效产品需求会议的秘诀。
精准管理开会的时间。在会议开始前,做好会议时间规划文档,精准到分钟,你可以采用上周数据更新(3 分钟,张娜)、产品测试结果(5 分钟,小王)这样的方式。
比如,第一部分由某工程师介绍功能开发计划,你给他规划的时间是 5 分钟。如果大家讨论无足轻重的细节问题或者快要到 5 分钟的时候,你可以礼貌地提醒大家注意时间。虽然这种方式打断了大家的讨论,但会议非常有效率,会后也没有人因为被打断觉得不被尊重。
以前我没有做会议时间规划时,不好意思打断别人,结果每次开会都有二十分钟甚至更长的时间在讨论无关紧要的问题,而且往往只有两个人针对这种问题争论不休,其他人都无所事事。但是,自从有了精确管理开会时间的文档,我可以非常礼貌地打断这种无关紧要的争论,并且他们会非常自觉地把这个问题留到会后单独讨论解决。
如果无法做出统一的决定,那就统一大家做决定的思考方式。这是一个可以让团队意见统一的迂回战术。
比如,开会的时候大家一直在争论到底是做 A 决定还是 B 决定,这样的情况我们可以先不讨论到底是选 A 还是 B。我们可以约定用更多的数据或者用户反馈来做决定,并统一做下一步决定的思考方式:如果数据达到 X% 我们就选择 A, 否则就选 B。
通过约定统一的思考方式,可以让僵持不下的两方取得统一意见,这种公允的决策方式可以取得两方人的信服。
我以前就遇到过这个问题,设计师、工程师虎视眈眈,公说公有理,婆说婆有理,谁都不肯让步,即使我更认同工程师的想法,也不能在这个时候直接怼设计师,否则这场争论不但不会停止,反而会扩大。但是,我采用“统一他们思考问题的方式”的迂回战术,那双方很快就点点头表示认可,问题随之解决了。
原因是什么呢?两个人的看法可以说都是对的,因为他们看重的情况不一样。但是,看完数据后,我和设计师说:“你的假设很有道理,但是通过数据我们发现,这种情况并不多见,所以综合考虑,我们决定做 XXX”。这时,设计师会点点头,表示认可。最终,和平就这么来了。
会议开始时先说明会议要达到的目的。
比如,在会议开始时,告诉大家未来的 30 分钟我们需要一起做出什么决定。那么当会议开始后,大家一般都会直奔主题,可以非常有效率的得到你想要的结果,会议成员也会觉得这三十分钟没有白白浪费掉。
我刚开始做产品经理时,就犯了一个错误。我组织了一个确定成功指标的会,但是没有和参会者说明会议目的,最终三十分钟的会议什么问题都没有解决。会后就有人跟我的老板反映,白白浪费了三十分钟,什么问题都没解决。被老板大骂一通后,我认识到了问题出在哪里,所以吃一堑长一智,在每次会议开始时先说明要达到的目的,这种问题就再也没有出现过了。
总结
接下来,我给你提炼一下本篇文章的要点。
我从一个失败的产品需求讨论会为切入点,跟你分析了造成会议低效的原因往往是:每次都邀请所有人参会,并让细节的讨论占据了太多的时间。因此,针对比较复杂的产品需求讨论会,你可以这样做:1. 一鼓作气,尽量通过一次会议解决,如果解决不了,就设置一个截止日期;2. 按照产品内容分成小组,然后各小组讨论,最后汇总。
我还跟你分享了我踩坑之后获得的独门秘诀:1. 精准管理开会事项,管理时间到分钟;2. 如果无法做出统一的决定,那就统一大家做决定的思考方式,尤其适用于两方僵持不下,各自都非常往心里去的紧张情况;3. 会议开始时先说明会议要到的目的,比如设定出产品路线图,或者确定产品成功指标,一定要明确这个目的。
思考题
回想一下,上一次你组织的或者参加的失败的产品需求会议,你认为会议效率低下的原因是什么?如果可以重新来一次,你会在哪些方面进行改进?欢迎你给我留言。
分享给需要的人,Ta购买本课程,你将得18元
生成海报并分享
赞 11
提建议
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
上一篇
14 | 如何用数据做出产品决定?
下一篇
16 | 如何和工程师有效沟通?
精选留言(17)
- 徐东鹏~种下一朵太阳...2018-06-01开发一个重要功能,我一般会召开三次会议。 1、思考产品定位及功能规划,与Boss确认(输出物为脑图、功能清单);2、完成流程图、原型 组织内部需求评审,参与者为相关部门的负责人;3、完成详细的需求说明文档, 开会前至少一天发给各成员查看,开会参与者是所有干系人员。大家带着问题来开会。开会时约定,我先讲解产品目标及重点功能和注意事项,讲解完之后统一回答问题,中间不能打断。讲解时间一般为30分钟以内。展开
作者回复: 你们组一般多少人开会
23 - 邹优杰2018-05-25把本节课的内容放到任何一个职能,场景都适合,是一节怎么开好会的通识课,+一点点沟通技巧。 希望能听到更具产品需求会特点的内容,比如怎么从臃肿的需求文档中提炼出会议大纲,以及要讨论的内容等等
作者回复: 好的 我们可以下面的内容多讲哈
10 - 酥2018-05-28这种方法我认为比较适合大家平级的情况,会议组织者具备一定的权利,像小公司,一开会开发是总监,确定产品的是副总,再来个运营总监,嘴都插不了一句,立马被怼的体无完肤
作者回复: 我觉得和公司文化也有关系,我们有的会上工程师也会和总监提反对意见,当然我理解这样的文化不一定适用于国内的国情
5 - Lynn2018-06-28我的理解: 会议邀请的元素: 人事地时物。 人: 只通知到相关人员,不相关的人员不必打扰。 事: 这次会议的主题 地: 大家都方便的地点 时: 大家都方便的时间 物: 必要的文档,相关人员先熟悉 会议开场: 讲清楚本次会议的主题,大概时长,更重要的是要产出什么内容(结论,文档,计划) 会议中: 注意时间把控,还要避免跑题 会议结束: 最好总结一下各任务的责任人接下来的action.展开3
- luna2018-07-27需求评审会在我们团队有这几个周期: 1、根据数据及需求池里的优先级先排出预估一周多一点的开发量的功能点出来作为下一版本的最初需求,这个决策一般由该app产品的主要产品经理与产品助理开会讨论出来的 2、产品经理拿着最初需求和老板做决策,二人最终确定主要需求点 3、产品经理分配好该版本任务,一周原型时间,一周后老板和负责原型的经理和助理开会讨论原型初稿,给出建议 4、初稿根据老板建议修改完毕后,与开发测试设计主要负责人过第一遍需求评审会,主要描述为什么要做这个功能以及我们的方案是什么,会中不讨论逻辑细节问题,会后留一周各部门需求分析时间 5、第二次需求评审会议由所有项目参与者参加,产品回答所有关于细节的问题以及其他问题。 一共五个会议,一般控制在两个小时内,平均时长一小时。展开共 1 条评论2
- 这个粗狂的土豆2018-05-24今天有人跟我说,产品召开评审会议的目的是: 产品先出一个框架,其他的让所有参会人员 一起想解决方法。请问你怎么看这个观点呢?
作者回复: 我觉得在一些产品上是个好的方法。我一般不会只开一个会。我会在项目初期开你说的这种会。之后我会进一步。最后快定稿了 大家一起审阅
1 - 肉丁2022-02-26总结下:会议效率低怎么办? 1. 如果需要讨论的问题特别复杂,可以集中一个时间花几个小时解决; 2. 如果参与人数过多,可以除了项目启动会以外,每次会议由各小组负责人参与即可;其他人会有邮件或者群同步会议纪要; 3. 开会前,需要有会议通知,告知大家会议讨论主题和讨论时间; 4. 开会过程中,需要有主持人,严格控制时间,有礼貌的提醒某些问题会后讨论; 5. 沟通的问题无法统一,可以达成一个统一的思考方法,通过数据分析后确定结论。 6. 会议后要有会议纪要,保证结论统一,还要有下次会议的大概时间和工作规划。展开
- PP2020-12-21当组织这种头脑风暴式的会议时,如果与会人不够积极(可能真的创意或者想法枯竭),作为组织人,要用什么方式去改变尴尬的局面再把开会效率提上去呢?
- 杉松壁2020-04-19很多开会感觉都只有12个人在参与。
- imoling2020-03-22会前邀请邮件中,将会议的相关需求材料提前发给与会人,并且注明会议沟通的主题,大纲,这样的话能够有效的提高会议效率。
- 老燕2020-03-20我认为比较重要的是我进行会前沟通,告诉与会者开会的主要议题,以及需要大家准备什么内容。这样开会当中各自的部分进展会比较顺利。
- 春风百里2020-02-13有收获
- Raymond吕2020-01-02大部分的会其实并需要那么多人参加,对于产品经理(任何会议组织者)来说,识别谁该参会是开会前要解决的第一件事儿,然后再细化会议目标,时间期限等。但是期望一次会议就能解决复杂问题多少有点困难。如果不需要面对面的方式,也可以通过微信群,虚拟会议等方式先把问题分解,抛出问题来给相关人,会前征集意见。能在会前达成一致的部分就可以在开会开始部分作为结论共享,剩下的部分作为讨论内容,这样也能提高会议效率。展开
- 不在加州的加州2019-06-12踩过的坑:1、一口气拉上了项目涉及的所有相关人员,结果因为很多人会议有冲突无法到场;2、会议开始前没有提前说明会议的内容和目的,导致会议的效率低下; 吸取的教训:1、拉会前提前和相关的人员协调时间;2、提前跟相关人员沟通项目的内容,让大家有一个初步的了解;3、会议开始先说明会议的目的和项目的内容,以及控制会议时间;
- 沙星宇2019-04-23新产品经理,明天就要组织第二次会议,谢谢曲老师~
- Geek_53d9742018-07-03精确管理开会时间这点,具体是怎么做的呢?在会议的文档里写上预估时间,并在现场,会议开始前重申一下吗?
- hehe2018-05-29不错呢,案例加结论
作者回复: 多谢多谢