按:作者killifer,华尔街见闻产品经理。
之前写了一篇有关于需求分析中可能遇到的坑《你做“需求分析”,踩过这几个坑吗?》,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们没写页面之前修改完毕再交付给开发,避免开发不断的跟着设计稿改而改。
(我有罪!猿猿们请原谅我!)
2、验收需求
程序猿GG们开发完需求之后,先由测试大人进行功能测试验收,然后修bug,再验收,再修二次bug等。如果这个版本的需求都开发完成,那么产品汪们就需要进行验收,尽可能早的进行第一次验收,这样出现业务相关的bug就比较容易被发现。
不要到最后时刻才做验收!不要到最后时刻才做验收!不要到最后时刻才做验收!
需求上线后,理论上从本期的功能层面上来说就完成使命鸟~
but,如果有以下情况的话,产品狗你给我回来,不要跑:
1、该需求被拆分成了n次实现。
有些需求可能第一版本先上个简单的,之后再继续去做优化,那么这个就需要被跟进数据,再去决定要不要去做优化;
2、该需求是“测试性需求”。
有些需求,一开始就是为了测试用户反应,那么同样需要被跟进具体的数据情况,再去决定要不要取消这个需求或者要不要继续升级这个需求。
注:《你做“需求分析”,踩过这几个坑吗?》(点击阅读)
【作者介绍】killifer,微信公号:killifer。华尔街见闻产品经理,人人都是产品经理专栏作家。脑洞大、笑点低、间歇性“有毛病”的理工科实力逗比少女。