运营提需求，说加上支付宝支付吧，好像看起来很简单，但其实却没那么简单。这也是我写这篇文章的缘由，下面就来详细说一下。

一、问题描述

我们项目里有付费产品，目前只接入了微信支付，突然有一天，运营提了一个需求，要增加支付宝支付，对，就是这么一句话需求，然后就推给了产品部门。

产品经理正好很忙，我就帮着想这个需求，然后我就发现几个问题：

• 为什么要加这个需求？
• 支付的场景是什么？
• 需求量很大吗？
• 加了之后会导致流程变化吗？

跟需求方沟通之后发现，我了解了以上问题：

• 首先加这个需求是因为有的人不用微信支付，或者说微信里没钱；
• 支付的场景是在微信群内发一个折扣商品链接，用户访问链接就可以进行购买；
• 需求量不大，目前只有三个；
• 增加支付宝之后之后，整个登陆的流程要变。

所以，增加一个支付宝支付，远不是一句话的问题，背后涉及到的变动还是很大的，由于开发的排期很紧张，而且这个需求量很小，所以暂时不进行开发，如果遇到个别这样的支付问题，运营人员线下收款，然后技术协助修改订单状态。

二、整理需求

由于上面的问题，我想到了产品整理需求时的流程和注意事项。

• 了解需求提出的原因
• 了解需求的场景
• 统计需求量
• 评估需求变动对其他部分的影响

下面我就以上面那个支付的问题为例，一点一点进行阐述。

首先是需求提出的原因，就是有的人不用微信支付，或者微信里没钱，其实这个很容易跟第三点联系到一起，这个年代了，有几个人微信没钱呢？

其次是需求的场景，上面也说到，支付的场景是在微信群内，微信群里面你打得开支付宝支付吗？所以这个问题不止是增加支付宝支付那么简单，还要引导用户在微信外浏览器打开页面，这也涉及到第四点，登陆的流程会有变化。

需求量刚才也谈到了，就三个人，占整体支付订单的比例很小，基本可以忽略。

最后就是该需求对其他部分的影响，首先就是要引导用户在微信外浏览器打开购买链接，然后还需要修改登录的流程，之前可能是微信授权登陆，在微信外只能使用手机号登陆了。

经过层层分析，就会发现，要做一个需求，不是一句话就能说清楚的，要考虑使用场景，要考虑值不值得做，还要考虑开发成本，等等。一句话的需求，往往都没那么简单。

还有，我们要挖掘表象之下的真实需求，就好像没有造出飞机的时候，人们只想到要汽车的速度更快，但造出飞机才能解决速度问题。

三、需求评审

需求整理之后，产品还要进行需求评审，主要有以下几种评审：

• 业务评审
• 功能评审
• 设计评审
• 技术评审

业务评审是产品整理好需求之后，跟需求方核对整个业务的流程是否符合需求方的预期。

功能评审是在产品出了原型之后，跟需求方确认原型里的功能是否符合需求方的要求。

设计评审是设计部门将核心页面设计完成之后，与产品部门进行核对，看是否符合准确还原了产品原型。

技术评审的时候，产品要多从技术的角度去解释，方便技术理解，有机会再详细写下我自己在技术评审中的感悟，说白了就是产品应该怎么讲需求。另外，也推荐大家听一下极客时间里邱岳的专栏「邱岳的产品手记」。

以上就是我对产品需求的一些看法，可能考虑的并不全面，但是确实是在真实项目里的感受，欢迎沟通交流产品心得。

欢迎访问的个人博客：掘墓人的小铲子