运营提需求,说加上支付宝支付吧,好像看起来很简单,但其实却没那么简单。这也是我写这篇文章的缘由,下面就来详细说一下。
一、问题描述
我们项目里有付费产品,目前只接入了微信支付,突然有一天,运营提了一个需求,要增加支付宝支付,对,就是这么一句话需求,然后就推给了产品部门。
产品经理正好很忙,我就帮着想这个需求,然后我就发现几个问题:
- 为什么要加这个需求?
- 支付的场景是什么?
- 需求量很大吗?
- 加了之后会导致流程变化吗?
跟需求方沟通之后发现,我了解了以上问题:
- 首先加这个需求是因为有的人不用微信支付,或者说微信里没钱;
- 支付的场景是在微信群内发一个折扣商品链接,用户访问链接就可以进行购买;
- 需求量不大,目前只有三个;
- 增加支付宝之后之后,整个登陆的流程要变。
所以,增加一个支付宝支付,远不是一句话的问题,背后涉及到的变动还是很大的,由于开发的排期很紧张,而且这个需求量很小,所以暂时不进行开发,如果遇到个别这样的支付问题,运营人员线下收款,然后技术协助修改订单状态。
二、整理需求
由于上面的问题,我想到了产品整理需求时的流程和注意事项。
- 了解需求提出的原因
- 了解需求的场景
- 统计需求量
- 评估需求变动对其他部分的影响
下面我就以上面那个支付的问题为例,一点一点进行阐述。
首先是需求提出的原因,就是有的人不用微信支付,或者微信里没钱,其实这个很容易跟第三点联系到一起,这个年代了,有几个人微信没钱呢?
其次是需求的场景,上面也说到,支付的场景是在微信群内,微信群里面你打得开支付宝支付吗?所以这个问题不止是增加支付宝支付那么简单,还要引导用户在微信外浏览器打开页面,这也涉及到第四点,登陆的流程会有变化。
需求量刚才也谈到了,就三个人,占整体支付订单的比例很小,基本可以忽略。
最后就是该需求对其他部分的影响,首先就是要引导用户在微信外浏览器打开购买链接,然后还需要修改登录的流程,之前可能是微信授权登陆,在微信外只能使用手机号登陆了。
经过层层分析,就会发现,要做一个需求,不是一句话就能说清楚的,要考虑使用场景,要考虑值不值得做,还要考虑开发成本,等等。一句话的需求,往往都没那么简单。
还有,我们要挖掘表象之下的真实需求,就好像没有造出飞机的时候,人们只想到要汽车的速度更快,但造出飞机才能解决速度问题。
三、需求评审
需求整理之后,产品还要进行需求评审,主要有以下几种评审:
- 业务评审
- 功能评审
- 设计评审
- 技术评审
业务评审是产品整理好需求之后,跟需求方核对整个业务的流程是否符合需求方的预期。
功能评审是在产品出了原型之后,跟需求方确认原型里的功能是否符合需求方的要求。
设计评审是设计部门将核心页面设计完成之后,与产品部门进行核对,看是否符合准确还原了产品原型。
技术评审的时候,产品要多从技术的角度去解释,方便技术理解,有机会再详细写下我自己在技术评审中的感悟,说白了就是产品应该怎么讲需求。另外,也推荐大家听一下极客时间里邱岳的专栏「邱岳的产品手记」。
以上就是我对产品需求的一些看法,可能考虑的并不全面,但是确实是在真实项目里的感受,欢迎沟通交流产品心得。
本文由 掘墓人 创作,采用 CC BY-NC-ND 4.0 DEED
,转载或翻译请注明出处。
最后编辑时间为: 2019年08月14日