产品经理互联网产品思考@产品

产品新人感悟6-谈谈运营的需求

2017-09-10  本文已影响48人  雨露均沾林

本次的主题是“沟通”。

运营的一个活动需求到我这了,从开始到结束,用一个字概括,就是乱,而乱的原因就是各方面信息的不到位。

感悟4里谈到的是产品面对开发人员要做的流程,即产品要跟开发说这个需求是要做来干嘛的,怎么给用户感知到这个需求,然后开发实现这个需求,我们姑且称这种需求是“一手需求”。

而现在运营给产品的需求,相当于运营跟产品说这个需求要做来干嘛的,要达到什么目的,然后用户做这个大概是个什么样的流程,比如一个活动,则流程是用户怎么参与活动,参与活动后又能干嘛等等流程,越细越好。然后产品这边来让用户怎么感知到这个需求,再交由开发,我认为是比较合理的二手需求提出。

运营应该跟产品细致说明好这个需求的目标和用户流程。具体用户感知到这个需求,则是产品的事了,而不是仅仅说是只有目标,告诉产品我们要干嘛,这样必然会导致混乱,理解不到位。

以身作则,总结一下这个乱的流程和项目管理上的不足和提升:

1. 运营需求的评审不够充分。重现一下当时的场景,运营拿了一份文档说明他们要做什么,为什么要这么做,这么做后会产生说明数据表现。大概是这三个问题,而且这三个问题的答案他们都回答得非常好,把大家都说服了。加上公司的一些特性,这个需求其实你反对也还是要做的。所以大家基本也没什么意见,有些问题就提了一下就这样过了。而后,细思极恐,这个活动需求其实建立在一个不是那么完善的产品功能的基础上的,要完善这个功能就必须花时间,然而活动特性不可能花太多时间,处于快速上线的需求。所以,这其实在放大自己的缺陷,太扯了。

稍微吐槽一下,用一个不那么完善的功能来搞东西,出来后还说这个功能这么那样不行,其实评审时有提出这个问题,回答说不是那么care,到现在这个功能却成为一个被吐槽的点,真是奇葩。

说到底,运营给产品提需求跟产品给开发提需求有点类似,但不尽相同(后面再展开),开发再评审时会提出很多问题,那么产品在评审运营需求时就应该提出问题,让运营意识到他做的东西,产品功能本身可能还没跟上,是会有什么对策,这是要说明好的。

2. 运营提需求时其实可以更好。正如以上所说,除了要给大家说明的三大问题之外,还需要补加一个流程,即运营应该给出一个真实用户怎么参与到活动的需求流程,越细越好。运营是第一需求方,产品是二传手,所以产品未必完全了解运营的需求,这必然导致两者需要不断沟通,一来时间多,二来越沟通可能越多问题,然后再重复沟通,浪费时间,那倒不如运营先把流程铺开,产品这边先过一次,提出问题,总比空空地沟通好多了,然后再根据流程画交互,写需求,这样就节省了好多时间。

而本次由于少了这一步,沟通成本加大,到最后大家都懒了,互相反馈都严重滞后。

运营的需求需要明确目标,用户流程,数据监控。

3. 沟通不足。需求到了产品这边,产品需要摸清整个需求的来龙去脉,这时就要去找运营去问,因为产品要根据APP或web等等本身的一些交互去呈现这个需求。事实上,刚开始的沟通会比较积极的,但多了就懒了。产品接到需求后会与运营进行沟通,到了后面沟通就少了,沟通少的一个最大弊病就是导致信息不对称,最后做出来的需求不符合运营的期望,即验收不过,然后又要大改特改。这次运营的需求有跟其他事业群合作,运营与事业群同事开完会后,没有同步信息给产品,到最后这儿缺了,那缺了,这儿不对,那儿不对,然后上线时间紧,又要改,则就少了很多思考时间,其实这个需求可以更好。

沟通是很有必要的,但沟通多了未必是好事,尽量把需求,流程想清楚,信息同步到位。

以上的三个问题导致这次的项目,从头乱到脚,产品和运营的需求理解不同,产品没法get到运营的点,做出来的东西不符合需求,同时双方沟通不够,很多信息都缺了,改动时间多了,问题层出不穷。

总之,运营方要提出需求目标和完整的用户流程,用户流程手绘的都OK,说得清就行。同时产品要主动去沟通需求,双方的信息都得同步到位。

上一篇下一篇

猜你喜欢

热点阅读