把需求拿到手，经过前面说的分析之后，上线似乎一蹴而就，但事实并非如此，特别是对刚入门的产品人来说，这当中有许多的坑还需要一步一步踩。今天结合我自己的工作经验和之前学过的课程，给大家介绍一下需求在原型阶段要做什么。

需求从小中大主要分为三种：功能点（单个页面）、完整功能（模块）和复杂流程（多个模块、完整产品、功能多端），区分主要依据包括涉及的流程页面、开发上线难度和测试时出现bug的概率（大功能bug就比较多一些）三个维度来判断。所以我们这篇也从把每一步拆分成“小、中、大”三种需求类型去介绍，在介绍之前要重点解释两点：一、每一个步骤都基本会用到，但可以仅停留在思考层面，大家在工作中需要根据情况随机应变，切忌死记硬背；二、部分步骤没有区分三种需求类型的，就是三种都需要用到的，下面就不一一解释了。（这两点就是需求文档里的全局变量。）

一、需求

我们在完成一个需求时分为以下几个步骤：

1、明确背景和目的。在之前的文章中说过，我们拿到需求的时候，都需要首先考虑的第一点就是要先明确这个需求的背景和目的，因为需求背景和目的是整个需求的指南针，导向标，也就是明确需求来源方和涉及场景，明确需求的形态，千万别后期自行脑补，不然很有可能要返厂，浪费人力物力。在工作过程中，特别是相对较大的需求时，经常会出现“因为走了太久，而忘了为什么出发”的情况，这时候再回头看一下背景和目的，很多纠结的地方往往会会引刃而解。一般到手的需求可以分为“小、中、大”三个方向去思考用户与需求的关系：

（1）若是已有部分小功能优化。

1) 进行用户分类，看哪些用户出了什么问题；

2) 找到出现这些问题的原因是什么，这里要求需求负责人对该功能的业务流程熟悉。如，产品路径深、入口设置不明显、文案提示错误等；

3) 数据区分各类型用户受影响分布情况。找到核心用户和问题之后，要找到数据支撑去让你说服你同事和你一起做优化

（2）完整功能调整。看这个功能能够给哪一层面的对象提供帮助，包括三个层面：

1) 用户。用户类的专注于提升体验，这里要看对哪类用户有好处、受影响的用户有哪些。包括以下几种：增加内容，提升数据准确性（添加用户标签）；减少操作，提升用户便利性（增加部分页面入口）；补充功能，提升用户体验（滴滴上增加开发票功能）。

2) 平台。平台类的我们专注于提升效率，这里主要看是否有提升操作人效率。包括以下几种：增加渠道，引入新用户（新增微信登录功能）；减少重复性操作，缩短转化路径；数据分层，提升用户数据化维度（千人千面大数据分析）。

3) 商业。商业类的我们专注于转化，这里主要看是否有提高收入，是否有提高转化率。分别有：拉动付费转化率（折扣、分享免单）；新增收入点（新增会员收费模式）。

（3）复杂流程。复杂流程说的就是大于一个版本迭代的工作量，这个主要从产品当前所处的时期和希望让用户解决什么样的核心需求出发所决定，和版本规划、产品调性以及产品目标有关。由于情况多种多样，不同产品也不同，在这里就不做详细分析了。具体方法和第二点类似。

2、明确需求的基本逻辑。这是做需求的基础，如果业务都不熟悉，那连修改功能点的资格都没有。要求产品人要熟悉用户的操作过程和数据流向。操作过程好理解，那为什么一定要关注数据呢？因为数据流向能够指引我们快速找到需求的核心页，而核心页是解决用户问题的根本。

3、产品调研。如果功能比较大，并且对于的竞争对手已有该功能，有必要做产品调研，产品调研可是判断产品人评估该产品是否要做和它优先级排序的重要指标，具体方法之前讲过，有兴趣的可以找回之前的文章看一下。

4、制定方案。在明确需求的背景、目的和基本逻辑之后，就可以制定方案了，制定方案的时候还要考虑上线后如何评估功能效果，是用户访谈的方式还是埋点收集数据。给个建议给新人，在做方案的时候别只做一套，要多做几套，做老大的都喜欢选择题不喜欢判断+简答题。当然，也别什么方案都拿出来，根据开发难度、效果、用户场景以及需求目的，从一堆方案中挑选出2个以上的方案让老大去选（之前似乎有说过，啰嗦了啰嗦了hhh）。方案不用太复杂，一般用手绘和思维导图的方式即可，主要是为了方向上不要出错，然后根据优先级去选出几个切合实际的方案。

5、流程图。工作中基本能满足的两种流程图——业务流程图和页面流程图：

（1）业务流程图。之前在产品论坛看过，有很多刚入职的产品人有在吐槽上一任产品的问题，主要原因是由于缺少资料，无法理解产品这么做的初衷，只能推倒重来。其实这个问题的根本就是缺少业务流程图，无法深入理解产品设计的初衷和过程。所以作为一名合格的产品经理，即使离开公司，也要让下一任同行能够清晰地理解你之前的项目，这虽然不是硬性要求，但是职业素养的问题（就跟玩狼人杀天黑就闭眼是一样的道理）。同时，业务流程图有利于帮助我们梳理逻辑和设置考核指标。这里不讲该怎么画流程图，大家直接百度一下就能找到很多可的方法，我在这里就介绍一下画业务流程时需要思考什么。

从需求大小上来说，包括已有功能优化、独立功能、复杂需求（包括独立产品、涉及多端的功能和大版本迭代）。

功能优化主要找到核心页面，在核心页面上，不一定需要业务流程图；

独立功能要考虑用户和信息流向的关系，一般使用单通道流程图；

复杂需求同样要考虑用户和信息流向的关系，一般使用泳道图，泳道图要关注以下几点：

分析功能逻辑。考虑什么人参与到功能中（用户）、这些人分别扮演什么角色（不同用户的使用场景）、要完成什么任务，顺序是怎么样的（信息流向）。例如，美团外卖下单投诉整个流程——用户下单之后，商家要怎么操作接受订单，外卖小哥怎么样获取订单并送给用户，用户在用餐之后投诉商家，客服要怎么处理。我们的要考虑用户除了点外卖的用户之外，还有商家、外卖小哥和客服；用户下单、商家接单、外卖小哥送餐、客服接收投诉就是不同用户的使用场景，而他们根据不同的场景，在平台上的操作顺序就是信息流向。

明确用户与任务。这里我们还是用外卖平台举例。首先要明确用户与系统的关系，怎么操作，怎么进入app的；然后梳理参与者之间的关系，即商家怎么发布菜单信息，用户是怎么评估哪家店是我要点的；最后明确参与者的最终目标，即商家要尽可能的吸引用户来店里点外卖，而用户要找到适合自己的店和菜并下单。这步和“a”步的着力点不同，“a”主要是功能逻辑上，是为了区分泳道，而这一步是为了填充泳道里面的内容，并且保证各泳道之间的关联性。

要尽可能保证只有一个开始和结束。起点和终点明确，制作人流程不容易出错，也方便看的人理解。

最后优化调整。就是把异常流程加进去，从头梳理一遍，相当于考试结束之后的检查。

其实总的来说核心关注点就四个：用户、解决需求的场景、数据流向和异常流程。只要考虑到了这四个，再百度一下画的方法，就可以画好业务流程图。

​​

（2）页面流程图。我们画完业务流程图之后，还需要画页面流程图，页面流程图可以更直观地表达出这个需求在各个页面上的跳转流程，也能更好地帮助程序员去理解需求。页面流程图是从业务流程图中剥离出来的，如下图（把大象关进冰箱）的页面流程图，仅供参考，不懂再自行百度 。最后啰嗦一句，参考为辅，练习为主。

​​

6、原型交互设计。这一节是基本功，是考察一个人工作能力和工作态度的重要因素，也是豆奶当年刚入门时最自信，但也最容易犯错的部分。

很多新人在求职时，简历上写“能够熟练使用Axure、墨刀等原型绘图工具”并且把这一点作为基本功能专门上课去学。

豆奶认为，工具只是工具，你会用Axure画原型就等于你会用筷子吃饭是一样的道理，你会用筷子还是勺子甚至是手什么的根本不重要，重要的是你得会吃饭。豆奶公司之前有个测试转产品，不会用Axure，但是老大又直接甩给她一个需求让她一周内做完，她照着我们之前在需求池里的文档，硬是用ppt画出了整个需求，完成了工作。所以呀，真正的牛人是不会纠结于工具怎么样的，工具只是术，而理解用户场景需求才是产品人应该关注的部分。

所以我建议初版需求先别上工具，直接手绘。手绘可以节省很多时间成本，而且也很容易修改，初版的目的就是为了用最快的方法去解释清楚需求，不论是跟老大还是跟研发去确认需求，都比较快。我一般是所有场景都考虑清楚了，老大点头同意了，研发没有其他问题了，也就是所谓的需求封闭了，再上Axure等工具，把具体流程落到图上。

有几个工作习惯的问题需要注意下：

不管什么时候的修改，都要记录日期和修改内容。方便以后的工作交接和日后回头看需求时，有理有据（锅要分清楚该给谁背，吃哑巴亏的事，咱不能干）；

原型要分版本保存。原型千万千万不能修改后就直接覆盖，否则如果突然某一天说还是之前的某一般比较好，要做那一版，可你又找不到时，只能重做了；

需求文档要考虑极端情况。特别是数据上，有些地方数据最多的时候，是怎么呈现的，没有数据时，页面又是怎么呈现的，这些情况要讲清楚；

写原型时产品逻辑要解释。比如O2O平台显示所有商家时，排列顺序是根据评分从高到低排列还是下单量从高到低。这些逻辑要说清楚，不能遗漏；

异常情况别忘了。很多时候异常情况没有考虑到，导致开发时出现bug，或者缺少部分页面，工作效率降低了，这个锅，又是你头上的了。

7、需求考核指标。是后续产品迭代的重要指向标，要注意以下几点：

首先是埋点。埋点怎么埋？从业务流程中而来，给大家分享一个常用的方法：业务流程中有判断的地方就需要埋点。但一般的公司都会有自己的数据团队，有数据团队就只需要把需要的数据整理出来告诉他们要的时间点即可，如果没有数据团队的小公司，可能就稍微比较麻烦一点，建议去找个第三方的数据公司，还可能需要跟研发一起合作，把需要的数据整理出来再手动筛选，豆奶刚入行的那家公司，甚至要求我们要学习代码自己手动去数据库爬数据。

定期回收数据。根据产品的不同，要的数据也有区别，但总的来说关注活跃度、转化率、各个页面的流失率。还需要关注产品潜在bug的发生比例。

分析+总结+需求管理=产品迭代的方向。

通报各部人员产品上线情况。

二、评审会

在历经千辛万苦画完了原型，写完了文档，产品内部评审顺利通过之后，就来到闻者伤心，见者流泪，人见人怕，鬼见鬼愁，让无数产品人都闻风丧胆的大（xian）型（chang）需（da）求（lian）评审会了。你或许会问，豆奶哥，不对啊！在写文档之前我已经跟老大、研发、UI都通过气了，为什么还会遇到千人怼的情况呢？别急，且听我细细道来。

评审会的目的是什么呢？就是为了在产品进入开发阶段之前，给团队中涉及这个需求的工作人员一个同步信息的机会，同时也为了避免在开发阶段出现某些问题，需要重做，从而浪费人力物力。毕竟三个臭皮匠，顶过诸葛亮，大家在同一频道，同一场景下思考的广度和深度都可能远超你一个人想的情况，而且我们一直思考一个需求，很可能陷入思考瓶颈，有些很低级的问题完全没有想到。

我见过一些新人，在评审会上被怼之后需要调整一段时间才能恢复，我觉得是没有必要的。既然是出于为产品好的初衷，我们即使评审会上被怼了，也没关系，大家都是为了更好的工作嘛。再说了，还没进入开发阶段，这样的问题是完全可以原谅的。千万别有太大负面的压力。

再说回来，在需求评审时，很多人一上来就直接讲需求是怎么怎么做的，它包含哪些页面哪些端。这样很多研发在不明白需求的情况下，听得云里雾里，不怼你怼谁。在需求之前，我们首先要把需求文档公布给参与评审会的人，让他们先了解基本需求。在评审会时要遵循以下几步：

首先讲需求的背景和目的，让听评审会的人了解需求；

用用户故事来讲用户、需求、场景以及没有使用我们产品之前的解决方案；

用用户数据去解释这个需求存在的必要性；

要简述需求的决策过程和解决方案，让参加评审会的人获取的信息和我们是一致的。

描述需求功能列表。这里最好用信息构架图，即每个页面需要新增哪些内容，让团队内的人直观地了解产品所包含的内容，再从用户流向、内容流向和信息交叉这三个层面去解释核心页面。

版本规划。功能优化的不需要这一步，其实小功能优化可能连评审会都不需要开，直接内部一致同意之后就可以投入开发了。大需求就需要版本规划了，主要简述根据数据可能出现情况去预估版本可能的迭代周期，而获得数据则需要把时间反馈节点和所需要的数据内容提前告知研发或数据团队。

三、需求池

最后，豆奶再讲一下需求池。每一个产品都有自己的需求池，产品迭代的过程就是把需求从需求池里释放出来的过程。由于产品的版本规划不同，需求的优先级也不一样，所以研发要结合自己的时间成本去迭代产品，需求相对滞后的产品则存在需求池里，这就是需求池存在的意义。那要如何管理需求池呢？步骤如下：

我们前面有讲过，获取需求之后首先要找到需求来源方还原受影响的用户场景，然后按照上面讲的内容进行原型和文档的撰写、需求评审，最后把需求放进需求池里；

把需求放进需求池之后要进行需求整理。在需求整理时首先要区分改进和bug，然后是评估优先级，我们可以根据重要紧急四象限来评估。bug的优先级是最重要最紧急，特别是影响产品正常使用的bug，要立刻让研发去修复；

​​

需求反馈。在释放需求，功能上线后，需要跟需求来源方说需求已经上线了、并且自定义时间（XX日后）获得反馈数据等情况。