注：本篇主要描述一个需求的成长史，不是一群需求们的血泪史，也就是说需求们的管理不在具体讨论中。
之前写了一篇有关于需求分析中可能遇到的坑《你做“需求分析”，踩过这几个坑吗？》，but从理解的角度，应该先了解需求分析到底是一个怎么样的过程才对，so，我终于来“补坑”惹。
一、确认需求：［明确自己“有”了－>决定是不是要生下］
1、确认需求的本意
为什么会提这点呢？因为需求的来源会比较多，可能有以下来源：
产品经理自己；
其他相关的产品经理；（老板、你的leader等）
其他相关的部门；（运营、销售、广告、编辑等）
直接的用户；
不同的来源，导致需求“被经手”的程度不同，从而容易导致理解的意思不同。
①这种情况，不太会存在需求理解偏差，除非你当时“精分”了。但是②③④就非常有可能理解错误、理解不到位、理解不深入。而造成②③④这种理解错误的原因，又有可能分成以下几种：
a.对方在跟你表述需求的时候，直接表述了自己认为的解决方法，而跳过了表述真正的需求的阶段；
这种情况下，如果你不多问几个为什么，可能就被他给带走，按照对方的解决方案做了。但实际上，最终多问几个why的结果可能就是加一个字段的事情，而不多问的结果可能是新做一个功能；
b.对方在跟你表述需求的时候，自己都没有清楚自己要干嘛；
这种情况下，还是多问几个为什么，帮助他整理自己想怎么样，为什么要这样，最终发现他的真正需求或者说最终不需要做需求；
2、确认该需求是否有必要
原因可能出现在以下几个地方：
①产品经理自己YY需求或者仅从某一类用户的角度考虑问题，具体在《你做“需求分析”，踩过这几个坑吗？》中提到过。这需要产品经理自己进行慢慢纠正。
②其他人YY需求；
a.和产品经理一样，其他人也可能容易站在自己也是其中一种类型的用户立场，或者自己对某个功能更专业的角度，去提绝大部分用户不会用或者“太高级”的功能。
b.也有可能出现在以数据为导向的工作方上。举个例子：同事A发现下载量特别差，可能就会认为是下载页的整体文案/页面风格太不吸引人，可能就会希望能够把下载页进行重新调整。但实际上，可能并不是文案太差，而是下载按钮并不明显。
针对其他人的YY需求，产品经理要会判别和求证。
3、确认该需求的优先级
这个确实会涉及到该需求和其他需求之间的整体关系，这里不多说，以后再单独写一个需求与需求之间的优先级管理。
但是举个例子好了：假设乃们的产品规划是先把主打的亮点部分给优化好，再去做基础性同类产品都有的功能。现在有个需求是基础性功能的优化，那么就可以先排在后面，不着急做。
二、具体分析：［既然决定生，那就乖乖十月怀胎］
在第一阶段中，已经把很多“不合格”的需求给排除掉了，到了第二阶段，就开始进入到需求的具体分析阶段，该阶段具体如下：
①确认该需求影响到的范围。
例如：同家公司的两个产品可能共用某块后台功能，如果产品A因为需求而想要修改共用的那块部分，那么就需要考虑到是否会影响产品B的数据获取、信息展示等，之后的测试也都要带上产品B。
②确认该需求的做法。
a.确认方案，主要是无争议的相对最优方案
例如：现在每个app都有节日时的特殊局部UI功能，这个功能如何做才能不需要上新版本就阔以灵活变更UI，这是需要确认的。当然，你也可以说，我每需要更改局部UI的时候，我就上一个新版本。（简单的需求要复杂做，那我也只能摊手）
b.两种方案取优，这区别于上述a的情况，而是两种方案各有优劣，针对不同需求不同情况可能会得到不同的结果
例如：同样一个页面，可以做app原生页，也可以做内嵌web页，耗时、优劣各有不同，需要根据具体的需求去做具体的选择。
不同方法会导致需要不同的资源、人力和配合程度，需要在确认做法阶段想清楚，以尽可能避免浪费、返工的情况。
这个考验产品经理对业务的理解、逻辑思考的能力以及细心程度。这个在《你做“需求分析”，踩过这几个坑吗？》中”具体的需求分析阶段“中进行过一部分的反向描述，啊哈。
①梳理业务流程：主要是用来确认涉及到的角色类型、角色的属性、角色的动作、角色之间的关系。
举个例子就好了：“发文章并展示”这个需求，至少存在几种不同的流程：（不做好坏评价）
a.用户发布文章后，都需要该网站编辑进行审核、格式整理，配上封面图再发布到主页内容流（所谓的精选）以及细分分类频道，例如人人都是产品经理；
b.用户发布文章后，可以直接显示在某个细分分类频道中，但是如果要发布到主页内容流（所谓的精选），需要该网站编辑审核，但不会帮你进行格式整理，会进行封面配图，例如pmcaff；
c.用户发布文章后，需要投稿到某个频道（精选也是分类的一种），还需要对应频道管理员审核，也不会帮你进行格式整理，也没有封面配图，通过后显示在该频道中，例如简书；
②确定流程中的逻辑判断
确定了业务流程之后，根据流程列出过程中的判断逻辑判断条件以及边界条件。延续上面的“发文章并展示”中b的情况：
a.审核通过的标准是什么：每个编辑大人自己定义？还是编辑团队有统一规则？还是依靠浏览量、点赞量、收藏量这种相对客观数据；是单一因素影响还是多因素综合影响，综合的话是否有分别的不同影响权重…
b.审核后是否会导致文章状态不同？
c.审核后如何展示：展示在哪里、如何排序；
…..
3、根据具体分析的结果画原型图
原型图主要是用来：
让猿猿们更直观了解需求；
设计师大人更加直观了解需求，同时了解页面需要表现的内容以及重要性程度；
让所有相关的人们都根准备预估工时；
那么根据原型图的作用，在制作原型图的时候，就要明确：
页面上展示的内容框架；
内容的优先级；
另外，强烈建议未确定前都画手稿，最终确定不改之后，再画电子稿，具体原因可查看《做“需求分析”，有木有踩过这几个坑？》中的“制作原型图阶段”
三、交付设计／开发：［既然带到了这个世界，一定要做个三观正的荡荡少年］
准备好需求分析的前提下，尽可能早的和设计大大沟通。准备好需求分析＋原型图的前提下，阔以跟程序猿GG们沟通惹。
设计大大了解细致的需求是啥；
设计大大了解页面上需要的内容以及重要性差别；
设计大大了解你想要的感觉是啥（一般来说，大大都有自己的想法）；
GG们了解细致的需求是啥；
GG们了解需求的业务流程、逻辑关系以及边界条件等；
GG们了解做这个需求需要哪些方面的支持（是否需要后端、是否需要第三合作方等等）；
四、验收：［三观不正？你不好，快去掰回来］
承接第三点，分别进行以下的验收：
1、验收设计大大的设计稿
如果有不合适的地方，尽快进行修改，尽量在程序猿GG们没写页面之前修改完毕再交付给开发，避免开发不断的跟着设计稿改而改。
（我有罪！猿猿们请原谅我！）
2、验收需求
程序猿GG们开发完需求之后，先由测试大人进行功能测试验收，然后修bug，再验收，再修二次bug等。如果这个版本的需求都开发完成，那么产品汪们就需要进行验收，尽可能早的进行第一次验收，这样出现业务相关的bug就比较容易被发现。
不要到最后时刻才做验收！不要到最后时刻才做验收！不要到最后时刻才做验收！
五、上线［ 既然该独立，就去放纵不羁爱自由吧］
需求上线后，理论上从本期的功能层面上来说就完成使命鸟～
but，如果有以下情况的话，产品狗你给我回来，不要跑：
1、该需求被拆分成了n次实现。
有些需求可能第一版本先上个简单的，之后再继续去做优化，那么这个就需要被跟进数据，再去决定要不要去做优化；
有些需求，一开始就是为了测试用户反应，那么同样需要被跟进具体的数据情况，再去决定要不要取消这个需求或者要不要继续升级这个需求；
