最近在做产品,主要是BI方向上产品,从技术转到产品岗位。参与一个整理评论的需求,大概说一下需求。
主要点:
1.使用者可以对某一个产品进行写评论
2.产品管理者可以对用户评论进行统一管理,形成产品问题分析,有助于产品的改进
3.最终目标是,可以实现产品评论的智能化采集,分析,优化
这里涉及2个目标用户,一个是产品的使用者,一个是后台产品管理者,再和业务方沟通了一次以及和上级讨论之后就开始着手产品原型设计。不同使用者对应他们的业务需求不一样,所以在页面设计上也是分了2个反向,对于写评论者他们只是对产品进行评论,这个就是一个简单的写评论的页面。后台产品管理,需求看用户的评论,此外对评论进行管理,管理方式有几种情况,第一情况,如果用户写的评论描述合理,直接是将评论描述归到具体问题分类下。第二种情况,用户描述不规范或者不合理,这个里需要管理合理,规范的组织语言写评论。第三,管理者需要对问题分类进行管理,可以对问题进行增删改操作。这些是主要的逻辑。
原型根据需求画好了之后。就和业务方,上级,开发讨论了一波。确定之后,开始执行。直到第一版出来之后,发给业务方看。结果是开发出来的版本他们并不是很满意,需要迭代修改,第一版本还没有正式上线就开始修改,迭代第二版。。。
总结一下:1.由于这个需求是中间插入进来的,并不是开始就可业务方沟通,所有的业务逻辑是在上一级沟通之后,根据上级的思维逻辑去做,其中也有一些自己的想法,但基本上都是按上面的要求做的。
2. 产品真的和业务方沟通非常重要,非常重要,一定要很清楚业务场景,业务逻辑,我就是因为刚接触,不是很熟悉,所以出现这种情况。导致明明原型画好之后,业务方也看过了,没有问题,但是开发出来的,却不是他们想要的。这个就比较尴尬了,所以在进入开发阶段之前,一定要和他们沟通清楚,可能当时我们的沟通也是存在问题,双方都没有沟通清楚。
3.产品和开发沟通也是非常重要的,也许我们是清楚业务的逻辑,但是技术上是否可行,最终还是需要开发来看,所有我们也需要听听开发的想法,但是一定要有自己的坚持,我在这一点确实做得不够好,因为是技术出身,所以看问题会偏向于技术,不能够很好的从业务出发。
4.思维方式的转变,之前的思维都是比较直接的看待问题,遇到什么问题,直接上技术给解决了,但是现在做产品就不一样,很多细节的点,逻辑的判断都要自己想清楚,不然就很容易出现问题,比如开发问这个做完之后,跳转到哪里,这个地方是否需要判断等等,这个其实应该产品想清楚,而不是开发来告诉我。这个是非常不好的。
做产品和做技术确实存在很大的不同,两者思维方式不太一样的,技术可能遇到问题,我只要想到解决方法就可以,至于其他我可以不用过多的考虑。而产品考虑的问题是周全,需要从不同的角度解读需求,比如:实际业务,用户角色,场景,还要考虑到一些用户习惯,等等。规划好产品之后是否能够真正的解决他们的问题或者是痛点, 这个是非常重要的。此外还要考虑实际过程中遇到的一些突发情况,开发延期,自己心理状态调整等等。其实产品也是一个技术活。
希望之后会越来越好! 有问题的可以一起沟通讨论。