注：本篇主要描述一个需求的成长史，不是一群需求们的血泪史，也就是说需求们的管理不在具体讨论中。

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

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

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

一、确认需求：［明确自己“有”了－>决定是不是要生下］

1、确认需求的本意

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

1. 产品经理自己；
2. 其他相关的产品经理；（老板、你的leader等）
3. 其他相关的部门；（运营、销售、广告、编辑等）
4. 直接的用户；

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

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

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.用户发布文章后，可以直接显示在某个细分分类频道中，但是如果要发布到主页内容流（所谓的精选），需要该网站编辑审核，但不会帮你进行格式整理，会进行封面配图，例如人人都是产品经理；

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

②确定流程中的逻辑判断

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

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

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

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

…..

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

原型图主要是用来：

1. 让猿猿们更直观了解需求；
2. 设计师大人更加直观了解需求，同时了解页面需要表现的内容以及重要性程度；
3. 让所有相关的人们都根准备预估工时；

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

1. 页面上展示的内容框架；
2. 内容的优先级；

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

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

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

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

1. 设计大大了解细致的需求是啥；
2. 设计大大了解页面上需要的内容以及重要性差别；
3. 设计大大了解你想要的感觉是啥（一般来说，大大都有自己的想法）；

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

1. GG们了解细致的需求是啥；
2. GG们了解需求的业务流程、逻辑关系以及边界条件等；
3. GG们了解做这个需求需要哪些方面的支持（是否需要后端、是否需要第三合作方等等）；

四、验收：［三观不正？你不好，快去掰回来］

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

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

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

（我有罪！猿猿们请原谅我！）

2、验收需求

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

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

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

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

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

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

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

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

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

至于需求上线之后的运营的事儿，就不在本文讨论范围啦～如果有遗漏或者描述的不对的地方，请指正哟～

#专栏作家#

killifer，微信公众号：killifer。华尔街见闻产品经理，人人都是产品经理专栏作家。脑洞大、笑点低、间歇性“有毛病”的理工科实力逗比少女。

本文原创发布于人人都是产品经理，未经许可，不得转载。