之前写了一篇有关于需求分析中可能遇到的坑《你做“需求分析”，踩过这几个坑吗?》，but从理解的角度，应该先了解需求分析到底是一个怎么样的过程才对，so，我终于来“补坑”惹。

　　一般来说，一个具体需求的分析的整体流程为：

　　确认需求->具体分析->交付设计/开发->验收->上线

　　一、确认需求：[明确自己“有”了->决定是不是要生下]

　　1、确认需求的本意

　　为什么会提这点呢?因为需求的来源会比较多，可能有以下来源：

　　产品经理自己;

　　其他相关的产品经理;(老板、你的leader等)

　　其他相关的部门;(运营、销售、广告、编辑等)

　　直接的用户;

　　不同的来源，导致需求“被经手”的程度不同，从而容易导致理解的意思不同。

　　①这种情况，不太会存在需求理解偏差，除非你当时“精分”了。但是②③④就非常有可能理解错误、理解不到位、理解不深入。而造成②③④这种理解错误的原因，又有可能分成以下几种：

　　a. 对方在跟你表述需求的时候，直接表述了自己认为的解决方法，而跳过了表述真正的需求的阶段;

　　这种情况下，如果你不多问几个为什么，可能就被他给带走，按照对方的解决方案做了。但实际上，最终多问几个why的结果可能就是加一个字段的事情，而不多问的结果可能是新做一个功能;

　　b. 对方在跟你表述需求的时候，自己都没有清楚自己要干嘛;

　　这种情况下，还是多问几个为什么，帮助他整理自己想怎么样，为什么要这样，最终发现他的真正需求或者说最终不需要做需求;

　　2、确认该需求是否有必要

　　原因可能出现在以下几个地方：

　　①产品经理自己YY需求或者仅从某一类用户的角度考虑问题，具体在《你做“需求分析”，踩过这几个坑吗?》中提到过。这需要产品经理自己进行慢慢纠正。

　　②其他人YY需求;

　　a.和产品经理一样，其他人也可能容易站在自己也是其中一种类型的用户立场，或者自己对某个功能更专业的角度，去提绝大部分用户不会用或者“太高级”的功能。

　　b.也有可能出现在以数据为导向的工作方上。举个例子：同事A发现下载量特别差，可能就会认为是下载页的整体文案/页面风格太不吸引人，可能就会希望能够把下载页进行重新调整。但实际上，可能并不是文案太差，而是下载按钮并不明显。

　　针对其他人的YY需求，产品经理要会判别和求证。

　　3、确认该需求的优先级

　　这个确实会涉及到该需求和其他需求之间的整体关系，这里不多说，以后再单独写一个需求与需求之间的优先级管理。

　　但是举个例子好了：假设乃们的产品规划是先把主打的亮点部分给优化好，再去做基础性同类产品都有的功能。现在有个需求是基础性功能的优化，那么就可以先排在后面，不着急做。

　　二、具体分析：[既然决定生，那就乖乖十月怀胎]

　　在第一阶段中，已经把很多“不合格”的需求给排除掉了，到了第二阶段，就开始进入到需求的具体分析阶段，该阶段具体如下：

　　1、分析该需求的做法

　　①确认该需求影响到的范围。

　　例如：同家公司的两个产品可能共用某块后台功能，如果产品A因为需求而想要修改共用的那块部分，那么就需要考虑到是否会影响产品B的数据获取、信息展示等，之后的测试也都要带上产品B。

　　②确认该需求的做法。

　　a.确认方案，主要是无争议的相对最优方案

　　例如：现在每个app都有节日时的特殊局部UI功能，这个功能如何做才能不需要上新版本就阔以灵活变更UI，这是需要确认的。当然，你也可以说，我每需要更改局部UI的时候，我就上一个新版本。(简单的需求要复杂做，那我也只能摊手)

　　b.两种方案取优，这区别于上述a的情况，而是两种方案各有优劣，针对不同需求不同情况可能会得到不同的结果

　　例如：同样一个页面，可以做app原生页，也可以做内嵌web页，耗时、优劣各有不同，需要根据具体的需求去做具体的选择。

　　不同方法会导致需要不同的资源、人力和配合程度，需要在确认做法阶段想清楚，以尽可能避免浪费、返工的情况。

　　2、分析该需求的业务流程、逻辑判断

　　这个考验产品经理对业务的理解、逻辑思考的能力以及细心程度。(这个在《你做“需求分析”，踩过这几个坑吗?》中”具体的需求分析阶段“中进行过一部分的反向描述，啊哈)

　　①梳理业务流程：主要是用来确认涉及到的角色类型、角色的属性、角色的动作、角色之间的关系。

　　举个例子就好了：“发文章并展示”这个需求，至少存在几种不同的流程：(不做好坏评价)

　　a.用户发布文章后，都需要该网站编辑进行审核、格式整理，配上封面图再发布到主页内容流(所谓的精选)以及细分分类频道，例如人人都是产品经理;

　　b.用户发布文章后，可以直接显示在某个细分分类频道中，但是如果要发布到主页内容流(所谓的精选)，需要该网站编辑审核，但不会帮你进行格式整理，会进行封面配图，例如pmcaff;

　　c.用户发布文章后，需要投稿到某个频道(精选也是分类的一种)，还需要对应频道管理员审核，也不会帮你进行格式整理，也没有封面配图，通过后显示在该频道中，例如简书;

　　②确定流程中的逻辑判断

　　确定了业务流程之后，根据流程列出过程中的判断逻辑判断条件以及边界条件。延续上面的“发文章并展示”中b的情况：

　　a.审核通过的标准是什么：每个编辑大人自己定义?还是编辑团队有统一规则?还是依靠浏览量、点赞量、收藏量这种相对客观数据;是单一因素影响还是多因素综合影响，综合的话是否有分别的不同影响权重...

　　b.审核后是否会导致文章状态不同?

　　c.审核后如何展示：展示在哪里、如何排序;

　　…..

　　3、根据具体分析的结果画原型图

　　原型图主要是用来：

　　让猿猿们更直观了解需求;

　　设计师大人更加直观了解需求，同时了解页面需要表现的内容以及重要性程度;

　　让所有相关的人们都根准备预估工时;

　　那么根据原型图的作用，在制作原型图的时候，就要明确：

　　页面上展示的内容框架;

　　内容的优先级;

　　另外，强烈建议未确定前都画手稿，最终确定不改之后，再画电子稿，具体原因可查看《做“需求分析”，有木有踩过这几个坑?》中的“制作原型图阶段”

　　三、交付设计/开发：[既然带到了这个世界，一定要做个三观正的荡荡少年]

　　准备好需求分析的前提下，尽可能早的和设计大大沟通。准备好需求分析+原型图的前提下，阔以跟程序猿GG们沟通惹。

　　把需求分析和原型稿交付给设计师，并且明确以下内容：

　　设计大大了解细致的需求是啥;

　　设计大大了解页面上需要的内容以及重要性差别;

　　设计大大了解你想要的感觉是啥(一般来说，大大都有自己的想法);

　　把需求分析和原型稿交付给程序猿GG们，并且明确：

　　GG们了解细致的需求是啥;

　　GG们了解需求的业务流程、逻辑关系以及边界条件等;

　　GG们了解做这个需求需要哪些方面的支持(是否需要后端、是否需要第三合作方等等);

　　四、验收：[三观不正?你不好，快去掰回来]

　　承接第三点，分别进行以下的验收：

　　1、验收设计大大的设计稿

　　如果有不合适的地方，尽快进行修改，尽量在程序猿GG们没写页面之前修改完毕再交付给开发，避免开发不断的跟着设计稿改而改。

　　(我有罪!猿猿们请原谅我!)

　　程序猿GG们开发完需求之后，先由测试大人进行功能测试验收，然后修bug，再验收，再修二次bug等。如果这个版本的需求都开发完成，那么产品汪们就需要进行验收，尽可能早的进行第一次验收，这样出现业务相关的bug就比较容易被发现。

　　不要到最后时刻才做验收!不要到最后时刻才做验收!不要到最后时刻才做验收!

　　五、上线[ 既然该独立，就去放纵不羁爱自由吧]

　　需求上线后，理论上从本期的功能层面上来说就完成使命鸟～

　　but，如果有以下情况的话，产品狗你给我回来，不要跑：

　　1、该需求被拆分成了n次实现。

　　有些需求可能第一版本先上个简单的，之后再继续去做优化，那么这个就需要被跟进数据，再去决定要不要去做优化;

　　2、该需求是“测试性需求”。

　　有些需求，一开始就是为了测试用户反应，那么同样需要被跟进具体的数据情况，再去决定要不要取消这个需求或者要不要继续升级这个需求。