作为产品经理,你真的知道怎么开会么?

懂后台的产品经理更值钱!3周线上课程,带你掌握电商后台12个子系统模块设计要诀。了解一下>

管理大师德鲁克曾说,“若经理人将25%的时间用在开会上,那么这个组织就可能出了问题。”产品经理亦是如此。

前段时间人人都是产品经理社区发布了《2017产品经理白皮书》,其中有调查到产品经理日常三件事为:内部沟通(32%)、开会(21.3%)、写文档(13.2)。开会、与技术沟(si)通(bi)、和老板沟通是产品经理最头疼又糟心的事情。产品经理作为产品迭代的发起人和执行推动人,是绝对无法避免开会的,但我们可以让会议更有效率。

总结下我的产品经理工作日常中需要开的会及频次:

  • 上下级沟通会,不定期
  • 产品组会议,一周一次
  • 项目部会议,二周一次
  • 产品预研讨论会,随版本周期随时
  • 版本评审会,随版本周期随时
  • 功能讨论会,随时
  • 头脑风暴会,随时
  • 需求实现细节讨论会,随时

归纳下上述会议的性质,其实可以分为两类:

  • 一类是过程导向的会议,事先规划、主题明确,例如上述的上下级沟通会、产品组会议、项目部会议、预研讨论会、评审会这些;
  • 一类是任务导向会议,随时召开、产生决策,例如功能讨论会、头脑风暴这些;

不同类型的会议虽然目的和形式不一,但总的来说最关键的一点都是会议发起人,因为这个人是会议的组织者、引导者、推进者以及后续的跟进者,鉴于产品经理的工作性质及内容,一般这个角色都是产品经理担任,那么作为产品经理的我们如何才能更熟稔地召开会议,并提高开会效率呢?

开会前

明确会议主题

解决什么问题、制定什么决策、达成什么目的。

过程导向型会议一般主题固定且明确,任务导向型会议由于解决问题大多属于突发性质,因此最好事先和相关人等明确会议希望达成的决策和目的,方便大家知道问题的解决进度——需开会确定。

参会人员及会议时间

明确和会议相关的所有人等,并确定各自的空闲时间。

这个过程看似简单却相当繁杂,尽量以核心相关人员的时间为准,其他人需尽量配合,而且会议时间最好在问题提出的两天内,越早越好,避免产生连锁反应,导致其他开发进度的延期。

对于具体的开会时间点,若是过程导向型的大会,笔者一般习惯定在上午10点半,或者下午4点左右,一方面在这两个开始时间点,大家都进入了工作状态,开会效率较高,另一方面也预留了充足的后续讨论时间(午饭前和下班前)。若是任务导向型的小会,笔者一般习惯是即刻解决,可以在会议室或工位处。

预约会议室

根据参会人员的时间安排,预约都能参加的时间段会议室。

当然是要提前预约啦,特别是需要视听设备的会议。若是一些任务导向型会议,例如需求实现细节的讨论会,在涉及人员不多的时候,甚至不需要会议室,直接在工位或某个休息区就及时讨论敲定了。

会议召集

通知参会人员会议时间、会议主题。

若是需要提前准备材料的会议,则需提醒相关人等提前准备并拷贝。当然,也要提醒大家要准时到会。

会议准备

开会前10分钟左右前往会议室调试视听器材,若会议时间较久,还需准备饮用水;若是脑暴、分享之类的会议,也可准备一些零食,营造轻松氛围,方便大家轻松自如地进行讨论。

开会中

维持会议纪律

首要便是要求参会人员准时到达,避免浪费大家时间。其次,若会议中有人交头接耳讨论与会议无关的话题,则需当即打断并给与警告。再者,若会议讨论出现胶着或意见相左无法达成一致时,会议主持者需及时中断论战,引导以避免扰乱会议氛围。

引导会议流程

低效率的会议一定是开会目的不明确,而依然滔滔不绝讨论的。因此,会议主持人在开会中,一定要根据事先明确的会议主题,引导会议流程按照预期进行。若大家讨论的问题已偏出主题,则需及时制止,引导解决议题问题。若出现无法达成一致的问题或另外新的未能确定的问题,则需及时中断,可放在会后另行组织相关人等继续讨论。

此外,会议主持人需调动大家的讨论热情,特别是针对一些开放性的问题,需要以身作则地抛出一些观点带动自由讨论。

明确决策及排期

在提案讨论过程中,会议主持人需注意观察与会人员的反应,确保大家听懂了提案内容,或在决策后确保大家持同意态度,或是大家是否已觉得无聊需尽快结束会议。

对于会议产生的决策,会议主持人一定要确保相关人等都持赞同意见,在意见得到统一后即需趁热打铁,协调相关人等的排期,明确问题得到彻底解决的预估时间。

会议记录

好记性不如烂笔头。对于有很多讨论结果或建议的会议,例如需求评审会,大家对需求原型、交互细节、实现方式等可能会有各种各样的建议,因此产品经理需及时记录下来,方便会后整理并调整。另外,记录这种行为本身也反映了你会重视这些意见,是一种对意见提出者的尊重。

开会后

会议整理和通知

会议结束后,需尽快将会议中做出的决策——相关事项谁处理、怎么处理、处理排期等进行整理,越详细越好,方便问题追踪和会议备忘。

整理后则需尽快发送给相关人等,一般是会议当天就可周知到所有人,方便大家及时处理相关问题,可以很好地督促他们去解决,也方便会后有文档备案及通知备案,避免后续扯皮。

一般来说,过程导向型会议只能处理80%的事情或问题,剩下的20%还需要靠任务导向型会议来解决,因为前者主要是知识技能与信息交流,而后者就是为了解决某些特定问题。在产品经理的工作日常中,像组内会议项目组会议需求评审会这些相对大型、参与人数众多的过程导向型会议,主要解决较为宏观的问题,以确定方向,频次上一般不会太多,而像功能或需求实现方式讨论会这些则是相对小型、参数人数较少的任务导向型会议,主要解决的便是细枝末节的执行问题,正是这类问题,才是产品经理与程序猿们撕逼的主战场,这时候更考验产品经理的应对能力及处理效率。

管理大师德鲁克曾说,

“若经理人将25%的时间用在开会上,那么这个组织就可能出了问题。”

同样,如果产品经理将超过25%的时间用在应急的任务导向型会议上,那么他的工作效率也可能出了效率,因为在进行过程导向型会议时,产品经理并没有考虑到所有问题,因此就造成细节问题不得不通过任务型会议去解决。希望所有的产品同仁们,都能熟练开会套路,提高会议效率,更快更好地推进产品迭代。

#专栏作家#

陆庄羽,微信公众号:看风景的人,人人都是产品经理专栏作家。擅长用户分析和原型设计,目前关注内容、社交、算法推荐、人工智能等方向,爱好骑行户外的伪文青一枚。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pixabay,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
6人打赏
评论
欢迎留言讨论~!
  1. 我想问下,开需求评审会的时候,应该怎样讲解需求?要细化到每一个元素,每一个交互,每一个业务规则吗?

    回复
    1. 要是需求评审会前,相关功能没有和开发沟通过,那么会上最好细化地讲一下,并寻求开发意见,让他们确认实现细节;若之前就有和开发沟通过,那可以简略地过一遍。评审会上,有些开发会仔细听并给出意见,有些开发会不认真只在意最终给到他的需求文档,为保证后续少些细节上的扯皮,最好评审会上一次性全部过完,尽量细致,避免再因此开小会

      回复
    2. 谢谢,明白了。我也注意到讲很细节的时候,很多开发人员并没有听,再加上这样整个会议就拉的很长,感觉效果并不好,所以就很疑惑讲解的粒度应该细到什么程度。

      回复
    3. 嗯,这个度的确很难把握,对于你认为有难度较复杂,或者你自己也不确定是好是坏的细节一定要在评审会时提出来,然后提醒开发说这里这样做有没问题,进行确认,对于一些常规的细节那就文档注明即可

      回复
    4. 嗯嗯 我明白了 谢谢~~

      回复
    5. https://wen.woshipm.com/question/detail/h1n1ar.html
      能不能帮我看一下这个问题呢?
      不知道应该怎么去思考才对 :lol:

      回复