D71575ed995fcf49247c6bf0118600df
产品经理踩坑后的吐血总结

在项目中不止技术人员会踩到许多的坑,对产品经理来说也会踩到不少的坑。
就在这里总结工作多年来所踩到的坑,给刚刚进入产品的新人一些经验,可以少踩一些坑或者在踩中时如何去应对。

一、各种评审会议,该如何优化缩减会议时间?

当今互联网都提倡着敏捷开发,减少过多的会议或开发流程,降低成本加快版本更新迭代,但很多时候一些必要的会议和流程我们还是要去走的,这样才能在项目的各个阶段更加清晰有据可依。
而我们都知道产品经理在项目之初到项目结束都需要开各种的会议,需求收集、产品内部评审、与UI和开发评审,到最后的产品上线宣导和项目复盘。我们的工作很多时候都是在会议上度过的。所以如果在允许范围内,我们可以与上级讨论优化开发的流程,减少会议的次数,这样就能减少占用运营、UI和开发的工作时间。如果他们的工作时间被占据了,那他们只能通过加班来完成手头上的工作。所以在需求设计的时候要把问题想清楚,减少在会议上有较大的改动,避免修改后需要重新召开会议。
有时候可以把几个会议合并成一个,但这一个适合一些小的功能或项目中,大家一起过一遍需求和功能。这时候就需要产品经理的一个控场能力,毕竟人越多问题也会越多,这时候会把会议的时间无限延长,所以最好在召开会议时制定好流程,控制好每个环节的时间,提前把会议安排发到每个参加会议的人手上,让他们了解清楚,也可以把已经整理好的需求和设计原型先发出去给他们看,让他们把问题记录下来。在会议最后统一把问题抛出来一起商量讨论。有的时候会议上可能会讨论到技术实现的问题,这时候产品需要控制好,把问题记录下来,在会后再详细讨论,毕竟在会议上不止有技术人员,其他人会听得糊里糊涂,所以原则就是不耽误大家的时间,大家达成一致共识。

二、项目为什么会延期,延期了怎么办?

众所周知,在开发一开始就有各种未知的因素影响着整个开发过程,对于一个项目来说很难百分百预估不同阶段的时间。而当我们的项目出现了延期,那该怎么办呢?
1、开发前评估时间没有细化,需求理解错误
需求应该提前发出,给相关人员在技术评审前大致查看接下来需要完成的功能,或者需要准备的技术。也可以前期与技术负责人进行沟通,分配了哪些人员参加到该项目中,提前与他们沟通了解实现的可能性。
那在会议前就能进行有效的分工,每个人着重查看自己负责的部分,及时发现问题,提出难点,与产品经理进行沟通。会后,产品经理也可以找到对应的技术同学仔细讲解需求,让技术同学尽量理解透彻。这样就能合理评估时间,不会只是一个粗略的时间。同时可以把一个大功能细化成一个个小的功能点,这样可以让我们很好的跟进进度,不只是一个大功能点的完成时间。
2、需求的改动
技术大大们敲代码的时候都喜欢沉浸式,中间被打断不仅影响心情影响更会影响效率。因此临时提出的需求应该统一提到产品经理这里,然后统一安排。不是重大问题、线上bug、节日营销等,都另行排期版本。插入该版本的需求也得开会评审,做好记录。根据优先级是否安排在这一次版本上。如果是设计方案产品经理没有考虑清楚或功能的改动,这时候就要及时更新文档并且与技术说明情况,自认错误,让技术按照新的方案进行开发。

top Created with Sketch.