一句话的需求往往会让需求对接的人员一脸懵逼，不知道从何入手。对于这样的问题作者分享了自己的一些解决思路，希望你也能够受用。

对于许多刚刚踏进产品经理岗位的人，可能都会对这个岗位有点陌生，不知道具体应该从何做起。我刚开始的时候也是一样，也以为产品经理就是个画原型的，所以根据需求大致归纳了一份需求说明书之后就开始画原型，搭界面了。

但是做到后面会慢慢发现，很多页面由于自己开始考虑的不周全而在实际开发中会出现许多问题，比如页面跳转的逻辑问题，页面展示的内容缺少了一些内容等等许多问题。那么，究竟应该怎么去做呢？

说实话，我也不是很清楚，毕竟产品经理这个岗位并没有形成一类系统性的科学方法论，很多人都只是按照自己的习惯或者公司之前项目养成的习惯在做着这份工作。我想你去问别人，估计也会问出几千个哈姆雷特，说穿了，适合你们团队的就是好的方法论。

那么我今天来抛砖引玉，说一说自己团队的一个流程方法。具体内容由于涉及一些东西，不太好说，但是我会举个例子方便大家理解。那么，我就说说大家最最熟悉的购物吧。

从一句话需求开始

很多人刚开始做需求分析的时候，面对的基本都是上面的一句话，“XXX，我们的APP中需要加一个购物功能，就是直销功能，就和XXX一样，你按照我们APP的特点调整修改一下，很简单吧。”我想听见这句话的你一定是一脸懵逼，不知道说什么。

那么，面对这样的问题，我们应该怎么处理呢？我个人的建议是从业务流程出发，将其逐步拆分，完善成一个具体到可以落地的内容。而拆分的过程就是先总结整个APP业务流程，然后将业务流程降低维度，拆分成多个功能模块，每个功能流程再降维，拆分到页面逻辑，落实到每个页面中。

我想上面这个流程肯定很多人也看到过了，那么具体我们应该如何完成这个过程，并且在这个过程中要注意些什么呢，别急，往下看。

如何整理产品的业务流程

九层高台起于垒土，合抱之木生于毫末。首先我们要完成业务流程，我个人喜欢用的就是业务3W法则来描述业务事件，即“who+what+who”，首先我们需要确定的是整个业务的操作主体，也就是我们所说的角色，第一个who。角色在前期我们要尽量考虑周全，避免之后出现问题，在这个例子中，由于是直销，可能的存在的角色就是平台，用户，不存在商家的概念了。

另外，我们还需要确定行为目标物，也就是第二个who，这边可能存在的行为目标物就是钱和货物。what则是两者之间的联系行为（行为本身可能会包含目标物），是什么行为将两者串联在一起的，给大家30秒钟时间考虑一下，自己罗列业务事件。

好的，那我来总结一下：

1. 平台上架商品
2. 买家挑选商品
3. 买家购买商品
4. 平台收到货款
5. 平台发送商品
6. 买家收到商品
7. 买家确认商品
8. 平台结束订单

好的，我们将这些业务事件串起来看一下，看看能不能形成一条完整的业务流程，如果可以，OK，接着往下，如果不行，继续完善。在业务流程这边不建议大家先开始思考各种分支情况或者异常情况。例如，要是买家收到货，不确认商品，要退货怎么办？那么后面平台也就收不到钱了。

这其实是买家收到商品后的一个行为，有确认，拒收，退货，这都是买家行为，是下面功能流程中的分支。那么如何判断你的业务事件中是否混入的一些异物呢？有个比较简单的方法，就是你把业务流程想成瀑布或者楼梯，每个事件都是有层序关系的，不存在并列关系，如果这边存在并列关系了，那么你的业务流程可能就出现问题了。

那么有了一个大概的业务流程之后，如何来降低业务流程维度，将其转化为功能流程呢？

功能流程的前奏-功能结构图

有了业务流程之后，我们如何梳理出功能流程呢，相信许多小伙伴依然一脸懵逼，不知该如何继续往下。这时候，上面的第一个who就起作用了，作为发起者，我们可以将属于它的流程都整理出来，那让我们举买家这个发起者为例，给大家演示一下。

首先我们整理所有发起者为买家的业务流程。

买家挑选商品->买家购买商品->买家收到商品->买家确认商品

我们可以把他理解为只包含一个角色的部分业务流程图。

然后是将买家这个主体去掉，变成：

挑选商品->购买商品->收到商品->确认商品

这样我们得到了4个功能模块，但是这些功能模块是由多个功能点组成，所以我们需要继续拆分。我们这边就以购买商品这个功能模块为例，举个例子。

首先我们需要确定购买商品是用户已经完成了挑选商品这个步骤，到了付款的阶段了。

那么接下来我们需要怎么做呢？接下来就是需要用到哲学终极三大问题了：“我是谁，我从哪里来，要到哪里去”，是不是听着很玄，不知道我在说什么。请听我慢慢解释。

首先我们需要确定这块功能涉及到的主体和客体。购买的主要客体其实就是钱和货物。我们将两个客体带入上面三个问题，首先将货物代入其中。

• 我是谁：需要的就是认清自己，即货物包含的具体内容是哪些？即货物的型号，颜色，也就是我们说的SKU描述，以及数量。然后我们根据需求去筛选需要的信息。大部分APP展现的就是商品的部分信息以及数量。
• 我从哪里来：货物是从平台那边来。这边由于主体是平台，所以我从哪里来不用考虑。打个×。
• 要到哪里去：要到买家那里去。这边主体是买家，所以保留，打个√。然后开始思考这个问题，衍生出了一系列的问题
• 买家在哪里，我要怎么去。这就是大部分APP订单界面的用户地址和邮寄方式这两块内容。

然后把钱代入这三个问题:

• 我是谁：也就是一共多少钱。也就是订单页面的总价格。
• 我从哪里来：钱是从买家那边来。所以需要用户填写支付方式。
• 要到哪里去：要到平台那里去。打个×。

是不是感觉差不多了，来我们整理一下。购买商品是一个功能模块。

其中还有一些子功能点，即订单货物详情确认，订单货物价格确认，订单邮寄方式选择，填写收货地址，选择支付方式。

也就是说购买商品这个功能模块中包含了以下几个功能点。

看到这边，有小伙伴可能会问了，你说的我都懂，但是这是啥？其实这就是一个功能模块的功能结构图。然后有人就会问，那说好的功能流程图？

其实，你如果把上面4个功能模块全部分解成功能结构图，嘿，角色是买家的功能流程图好像出来了。然后另外两个角色的功能流程图也采用一样的方法，你会发现，嘿，整个功能流程图都出来。

由于篇幅问题，今天就先谈到如何做功能结构图，下次再仔细聊一下如何做功能流程以及下一步的页面流程。

相关阅读

如何去完善一句话需求？（下）

本文由 @Chris 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议