资讯 专栏
此为临时链接,仅用于文章预览,将在时失效

一个需求的“艰难”成长史

作者:人人都是产品经理
2016/03/08 10:16

按:作者killifer,华尔街见闻产品经理。

之前写了一篇有关于需求分析中可能遇到的坑《你做“需求分析”,踩过这几个坑吗?》,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.用户发布文章后,可以直接显示在某个细分分类频道中,但是如果要发布到主页内容流(所谓的精选),需要该网站编辑审核,但不会帮你进行格式整理,会进行封面配图,例如pmcaff;

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。华尔街见闻产品经理,人人都是产品经理专栏作家。脑洞大、笑点低、间歇性“有毛病”的理工科实力逗比少女。

长按图片保存图片,分享给好友或朋友圈

一个需求的“艰难”成长史

扫码查看文章

正在生成分享图...

取消
相关文章