产品经理的日常会议,要怎么开才有效率?
相关评论
来源:
作者:
发布时间:2018-08-26 10:07

今天,和大家聊聊开会这件事,看似简单实则很难的一件事。

产品经理的日常会议,要怎么开才有效率?

作为一名产品经理,工作中会涉及各种各样的会议。和老板的会、和运营的会、和设计的会、和技术的会,还有产品内部的各种会。所以开会对于产品经理来讲,是一项很重要的技能。

说实话,我自己刚开始是个特别恐惧开会的人,尤其是自己主持的会议,怕hold不住全场,怕冷场。随着开会次数越来越多,不断碰壁踩坑,也算总结了一些经验。今天分享给大家,希望对大家有所帮助。

产品经理的日常会议包括哪些?

我们先来看看产品经理的日常会议有哪些,比如:需求沟通会、需求评审会、设计评审会、需求排期会、需求宣讲会、项目复盘会等等等(每个公司对于会议的称呼可能不同)。

接下来简单给大家介绍几个会议:

产品经理的日常会议,要怎么开才有效率?

  • 需求沟通会:主要是产品和老板、运营之间沟通需求的会议。经常沟通的内容包括产品版本需求、运营后台的需求、还有一些活动需求。这样的会议,在一个需求确定前,可能需要反反复复开几次。产品运营多多沟通,可以有效降低需求理解偏差。
  • 需求评审会(运营):当我们产品人员把需求转化为具体的功能界面后,便需要再和运营/老板/技术去开会,看看是否满足需求。这个会议,可以让我们从多方维度来思考这个功能的设计,让其更加完善。
  • 设计评审会:设计师主导的会议,召集大家评审设计图,确定定稿方案。这个会议可以有效降低设计图改改改的次数,让公司各部门对上线后的效果有预期。
  • 需求宣讲会:产品主导的会议,参会人员是技术人员。这个会议主要是为开发讲述接下来版本要做的功能,让大家对功能有心理预期,以便于接下来的工作量评估。会议内容包括需求背景介绍,功能流程讲解,数据的来龙去脉,一些特殊状态限制条件等。
  • 需求排期会:这个会议一般是和需求宣讲会在同一天完成,技术针对宣讲会上的需求,进行工作量评估,最终确定人员排期以及预计上线时间。版本上线时间确定了,一来可以让团队进度更可控,二来可以让公司各部门更好的安排工作计划。
  • 项目复盘会:这个会,相信不用我多说什么了。大家都知道复盘的重要性,通过复盘,我们可以发现每个版本过程中的问题,找到解决方案,让团队协作更高效。
  • 其实,上述大大小小的会议,均涵盖在2类会议中:一个是自己主持的会议,一个是自己参与的会议。在这2类会议中,自己所处角色不一样,所需具备的技能也不一样。

    怎么主持会议?

    主持会议,这真是我工作后的一大难关。

    作为会议主持人,全场的焦点聚集在你的身上,要负责把控整个会议的进度,调节会议气氛。听着好像不难,但在实际会议中,因参会人数较多,你一不留神就…跑题了,就要想办法把讨论内容重新拉回正轨,还会有冷场啊,会议时间无限拖延啊等情况。所以想要主持好一次会议,还是需要不断的练习和总结经验。

    接下来,我们先来看看那些低效会议是怎样的,存在哪些问题,以及自己的一些建议。

    低效会议1:缺乏背景介绍,直接开始讲细节

    我们先来看看这种开会场景,如下:

    产品经理的日常会议,要怎么开才有效率?

    事例中讲到的是一次技术需求宣讲会,产品经理在没有做任何功能背景介绍的前提下,一上来就说xx功能需求是怎样的,涉及的改动点有哪些。

    从技术需求的角度来看,开发人员确实最想了解的是下个版本增加修改了哪些功能,涉及哪些改动,自己的工作量如何等。但是如果这些细节的改动脱离了需求背景,便很可能导致会议只围绕细节功能点去讨论,而忽略用户真实使用场景和流程,最终很容易导致有些场景技术上考虑不全。

    (或许你会感觉上述场景似曾相识…)这是我刚开始参加工作的时候,时常犯的一个错误。结果就是,给大家讲的一脸蒙圈…还需要反反复复再沟通几次,大家才理解需求。

    因为参会人员没有参与之前的需求讨论,如在会议开始时,我们不做需求来源和整体性的介绍,便会导致大家对全局没有概念,缺乏对产品功能宏观层面的理解,容易钻进细节之中,导致遗漏。