需求管理方法（教你如何分解需求）

需求管理方法（教你如何分解需求）商品假如现在不管哪个地方（备忘录，纸上，某道，某象） 我记录了如下东西，或者我的客户突然告诉我，他们想做如下东西：理清需求就是把我们想做的事情，或者说我们认为用户可能会需要的功能有条不紊的罗列出来，用文字OK，不过我更建议使用脑图，不管是手绘也好，Xmind也好，MindManager也好，工具只是形式。（很多人一上来就问Xmind和MindManager哪个好用？其实这个真的无所谓，只要能达到目的，用啥都一样，如果真的还停留在纠结哪个好用这个问题上，那么我只能说，你还没到考虑这个问题的时候，真正需要考虑这个问题的时候，你已经知道哪个更适合自己了。）用脑图做什么呢，举个例子：

【起点学院】产品经理实战训练营，北京、上海、广州、深圳、成都、杭州同时开课啦！

对于产品新人来说，如果没有好师傅带，单枪匹马很难形成好的产品思路。有时候和研发沟通，双方都无法理解对方的想法，或者自己在写需求的时候，不是东丢点就是西漏点，老是被开发追着走。今天我就简单说一下个人的需求分解经验，希望能够帮助到一些经验不够丰富或者还没有形成自己产品思路的产品经理。

第一步：理清需求（use case）

我相信每个产品经理都是上帝创造的奇葩，能想敢想，希望影响世界，甚至改变世界。作为一个产品狗，我深深滴体会到脑洞之大给自己带来的困扰：必须要无时无刻携带手机，没有手机的时候手边没有纸和笔直接让我抓狂！！

好了不说废话，继续正题。产品经理时时刻刻都有可能想出一些零零散散的点子，然而在没有理清思路之前，很少有人知道我们想干嘛，所以第一步，我们需要理清需求。

理清需求就是把我们想做的事情，或者说我们认为用户可能会需要的功能有条不紊的罗列出来，用文字OK，不过我更建议使用脑图，不管是手绘也好，Xmind也好，MindManager也好，工具只是形式。

（很多人一上来就问Xmind和MindManager哪个好用？其实这个真的无所谓，只要能达到目的，用啥都一样，如果真的还停留在纠结哪个好用这个问题上，那么我只能说，你还没到考虑这个问题的时候，真正需要考虑这个问题的时候，你已经知道哪个更适合自己了。）

用脑图做什么呢，举个例子：

假如现在不管哪个地方（备忘录，纸上，某道，某象） 我记录了如下东西，或者我的客户突然告诉我，他们想做如下东西：

商品

（千万不要直接拿去和研发谈，不然我不敢保证你不会被打死）

现在需要做的，就是理清需求！！把场景罗列出来，像酱紫：

商品是用来做什么的呢？系统发布商品，用户购买商品咯！

所以场景展开就应该是酱紫：

现在拿这个去和程序猿谈，他们基本知道了这东西是干嘛的，但是他们还是会对这个东西的可行性保持高度怀疑，因为这样说了之后，他们还是不知道应该做什么，这个时候，我们就需要进入下一步： 整理故事

第二步：整理故事（user story）

讲故事需要有一个核心主题（主线），现在我们的主线就是商品。

讲故事怎么讲？举个栗子：

那天我打开手机，进入了“我的产品”APP，进入了商品列表，我看到了许多商品，我把商品添加至购物车，并选择了进入购物车结算，我看到了每个商品的结算价和总价值，感觉这些东西值得购买，于是我点击了确认下单，系统给我生成了订单，把我带到了订单确认页，我点击确认支付，系统又把我带到了支付页面，我输入了正确的支付信息后，系统提示我我的订单已经完成了支付，并且我还看到了一条已经支付的订单记录。

简而言之，如下：

到这里，购买商品的这个故事就讲完了，这个故事完整吗？完整。这是一个清楚的故事吗？不是。

讲好故事就能做好产品，一个完整的故事包含时间地点人物，一个清楚的故事，在于细节。所以如果我们将上面这个故事加入更多的描述，这就会变成一个清楚的故事：

那天我打开手机，进入了“我的产品”APP，我看了首页长什么样，哪里有按钮，我点击了进入了商品列表，页看到了许多商品，这些商品都是什么样的，怎么展示的，我把商品添加至购物车，并选择了进入购物车，我看到购物车里的商品长什么样，我看到这些商品的总金额之后，觉得这个价格还不错，于是点击了确认下单，系统过了没多久就把我带到了订单确认页，于是我点击了确认支付，系统又把我带到了支付页面，我输入了正确的支付信息后，系统告诉我我的订单已经完成了支付，并且我还在订单列表里面看到了一条已经支付的订单记录，我一眼就能看到我买了什么东西，每个东西是多少钱，最后我总共付了是多少钱。

于是我们的表格变成了这样：

至于怎么样讲一个好故事？绘声绘色地讲是一种方式（视觉效果），切入人心地讲是一种方式（用户心理），抓着重点讲（核心流程），当然还有很多其他的方式，如果讲故事的人能够灵活地把多种方式柔和在一起，又能够将他们发挥得恰到好处，那讲出来的故事一定会是一个好故事。

第三步：分解故事（functional requirement）

对于一部分产品经理来说，第三步其实不是必须的，因为经验丰富的产品经理知道，在第二步中，需求已经表达得够清楚了。对于另一部分产品经理来说，可能由于公司制度的规定或者与研发、项目管理人员工作范围没有划分得特别清楚，就不得不做功能需求描述，总之如果产品经理本身入行不深或者对产品的架构不是特别清楚，我很建议接着往下看。

在第二步中，我们已经清楚地讲完了一个故事，分解之后我们发现里面涉及到的关键物其实就只有几个：APP前端（首页、商品列表、订单列表）、支付等等。所以在产品架构上，为了保证这些东西都得以实现，必须要保证有一个APP前端系统，这个系统由首页，商品列表，订单列表组成，除此之外，还需要有一个系统支持支付，为了方便管理，后台还需要将用户的订单记录保存或者展示。于是功能需求可能就是这样：

然后故事分解完了，功能需求列表也搞完了。

以上是个人在从业期间内学习并总结出的一套比较完整的产品思路，希望能够帮助到各位还没形成自己的产品思路又很苦恼迷茫的同仁！