需求分析是什么&案例解析

14 评论 1.4万 浏览 125 收藏 18 分钟

本文将需求分为两类——工具类需求、用户端需求;并进一步给出了两个案例方便理解。

前言

关于需求分析无疑是产品经理的一项必备基础功,也是每个产品经理可能工作大部分时间都在做的事情,但是绝大部分产品经理可能不会刻意的去总结一套方法论。总的来说不总结方法论也不会有多少问题,因为毕竟基本工作很熟手,但是总结了方法论并写出来有以下几个好处:

  1. 指导自己工作,在自己不知该如何着手做一个需求的时候,可以为自己提供一个框架
  2. 锻炼自己的结构化思维及总结能力
  3. 写出来与自己对话能提高自己的认知,会获得意想不到的收获

个人平时也比较懒,偶尔会写些东西,但是通常不能长久的坚持,也希望自己能慢慢坚持下去。

什么是需求分析

个人对需求分析就是:确认终点寻找路径的过程.

从这一定义来说需求分为2类:

  • 第一类是终点比较明确,无太多争议性,此时的需求分析主要集中在寻找路径。
  • 第二类是终点不是非常明确、甚至是极为不明确,此时需要先确认终点再去寻找路径。

第一类需求主要包括一些公司职能部门管理后台一些效率性工具、营销工具等

如:财务管理、订单管理、路由配置等,这类需求考验的是产品经理的基本功,包括业务流程梳理、功能逻辑梳理、功能列表及细节,提供最终解决方案、优先级协调、方案拆解及迭代计划等。

需要注意的是,这里所说的终点比较明确是相对的,有些新人产品经理比较容易犯的错误是,业务部门提啥后台需求我就接啥。

这样很容易导致后续改改改,因为业务人员提的往往不是一个需求,而是一个解决了他们所认为的需求点的一个方案,产品经理一定要能识别需求和方案之间的差别,透过方案看到需求本身是什么。

举个简单例子:运营人员提了个需求说,我想在推送配置界面里加一个EXCEL导入推送人员名单功能。

这个需求看上去很合理,这样运营就可以快速的导入推送人员名单了,但是仔细想想这是一个需求吗?或者说这个需求本质是加一个EXCEL导入功能是产品的最终形态吗?这个问题在这里不做回答,后面会举一个相类似的我在工作中遇到的实例。

第二类需求主要是一些用户端需求

比如推出一个新的功能、一个新的玩法、对以前功能做优化。但是对于这个玩法究竟效果如何,大家都不能很确定。此类需求相对于第一类需求除了考验产品的基本功以外还需要产品经理有规划MVP(最小可行化产品)能力、数据分析能力等。

可能会有人提出还有第三类需求,就是现在啥都没有从0~1打造产品。在这篇文章的场景限定下,此类不属于一个需求,这是要做一整条产品线,这即需要产品经理对宏观了解把握、对业务熟悉、对微观的有掌控等能力,个人暂时没有实力写这样文章,如果有同学想学习此类能力,推荐学习梁宁的《产品思维30讲》、《增长思维30讲》,后续个人也会尝试着从自己的工作理解中来简单谈谈

需求分析框架

需求分析框架用比较直白的话来说就是:值不值得做?做成啥样子?怎么来做?

值不值得做需要去分析目标和价值,做成啥样子需要去梳理业务流程、分析使用场景、设计功能细节,而怎么来做主要就是确认优先级、调整配置资源、完成迭代计划,以下是个人总结的需求分析的框架图:

严格来说,怎么来做已经不属于需求分析范畴,但是当面临的需求比较大但是研发资源不足时候就需要考虑怎么来做了,比如说优惠券系统,涉及到模板创建、运营发券、用户领券、用券、核销、数据统计等,在研发资源不足业务有比较急需情况下,就需要将一整个大需求进行拆解,分多期来做。从这个角度来说也够得着需求分析的边

2个案例

以下是自己工作中碰到的2个真实的需求分析案例:

案例1:财务结算报表需求

业务背景:

公司甲为某小贷公司一级代理中介,其职能是为小额贷款公司寻找二级渠道客户,用户经二级渠道办理业务,钱款直接打到小贷公司(由于业务法规限制,系统无法直接在用户付款时候进行分账),每月月末,小贷公司分账给甲公司,甲再分账给二级代理公司。

如下图所示:

当时财务是这么跟我提需求的大概是这么说的——

“我需要一个2个结算报表页面,两个报表都有balabala字段,都要有个EXCEL导出功能。”

下面我们套用需求框架对此需求进行分析:

1. 目标分析:

此需求受众是谁?——财务(废话……)

是否影响其他人?——否

此需求目标是什么?——是要一个列表吗和EXCEL导出吗?

显然不是,因为前期分账也有EXCEL,只不过是研发从数据库拉取的,她要的是能够更效率的分账与核账,最终目标是“更效率分账和核账”。

此处必须要废话一下,因为有的新人产品经理会真的直接按照需求方提的要求做出这么两个表格出来。

2. 价值分析:

此需求有无价值,价值几何?很显然有,只不过是一个优先级问题,只要没有更高优先级需求这个需求肯定要做的,因为可以节约开发和财务双方的时间。

3. 业务流程梳理:
可参见上图,财务核心点就在于向上游和下游的结算、核账。

4. 场景分析:

在这里,因为这个是一个新项目,我不是太了解此条业务线结算场景,所以需要和财务进行了大概如下对话(这一步非常关键,知道怎么用,才能设计好对应功能):

我:你能简单说一下你以后要怎么用着两张报表吗?

财务:每个月月底小贷公司打款过来,然后我用“报表1”进行核对打款是否正确。每个月我根据“报表2”计算应付渠道多少款

我:那为什么要拆成两个报表?之前研发不是拉一张报表给你就OK了吗?

财务:因为结算给渠道不能让他们看到成本,结算给小贷公司,也不会给他看渠道成本,他们也不关心(已经获得第1个结算场景全貌)

我:那我做一个报表给你,你再拆不一样吗?(这么问不是为了偷懒,因为工作量差不了多少,主要目的还是旁敲侧击挖掘其使用场景)

财务:这样也可以,但是有些麻烦,而且有的时候渠道方中途想核对一下月中数据是否一致,此时不用导出EXCEL报表发过去,比较麻烦,直接截个图对下数据就可以了(获得了第2个使用场景)

我:除了对账,表格对你还有其他帮助吗?

财务:还会去统计每个渠道带来利润,看看渠道大体情况

我:那分成两个表格你怎么统计利润?

财务:(财务有点支吾,估计之前没考虑到)我可以自己再把表格合起来然后对账(获取了第3个场景全貌)

从以上的对话可以看出财务所提的方案,满足不了她自己所有的使用场景需求,当然后续对话还有一部分是关于功能细节的,这里不赘述了。

有的人可能会问,财务说的也对,两个表格到时候她自己合起来对账就OK了?

那么首先这样麻烦,容易造成错误不说,最关键的一个问题是,她如果要去做合表,必须保证后台所查出来的两个表格数据排序是一样的,否则就会造成数据对不齐!如果直接开发上线,后续就不得不面临着一个问题——需求变更#@¥!¥%@%¥!%¥

5. 功能设计:

有了具体的使用场景,对业务了解,基本功能设计就不太会出多少问题了,这个产品形态很简单。下面直接附上最终的交互稿:

至于后续的几个步骤,在这个例子中不需要做,因为功能很简单工作量小

案例二:优化认证转化率

某小额贷款公司,整体业务流程为:用户登录注册→认证获取额度→申请→审批→打款

需求背景:

在该项目上线半年左右,业务已经逐步趋于稳定了。于是就琢磨着看能不能提高业务效率,在当时整体的认证转化率在35%左右,凭直觉有很大的优化空间,于是就自己倒腾备库,拉了一周的和认证相关的业务数与埋点数据,做出了下图:

在这张图上很容易看出进入页面=》提交身份认证,联系人1点击=》联系人2点击,这2步跳变流失比明显比较大,于是就有了“优化认证转化率”的需求,套用需求分析框架。

1. 目标分析:

此需求受众是谁?所有进入我们APP无特定属性用户。是否影响其他部门/人?应该不影响。此需求的目标是什么?提高用户进入认证页到获得额度的总体转化率。

2. 价值分析:

此需求价值几何?

简单来算一笔账,市场运营推广费,平均一个注册用户在4~10多块,我们就按照6块来算,我们每天新注册然后到认证页面用户在1W2左右,如果能将认证转化率提高X%,那么每天可以等价为公司节省下:

12000*[1-35/(35+X)]*6=72000*X/(35+X)元

(公式得来是因为我们要维持放款量是一定的,转化率高了对应的拉的用户量就可以减少,大家可以自己推算)

简单代入,如果提高了1%,那么每天可以为公司节省2000元左右推广费,如果提高了5%呢?那么每天就可以节省9000元,一个月就可以省下27W!!!的推广费用。

3. 业务流程梳理:

此处应该说是问题分析了。第一步到第二步之所以跳失这么高,大胆猜测原因:

  • 1)骗贷用户,身份证提交不了(因为身份证需要拍照,我们接了三方防伪,假冒身份证提交不上来)
  • 2)未成年用户(身份证年龄前端计算低于18岁就不给提交)
  • 3)页面采集用全部展开方式,信息太多,对用户不太友好

紧急联系人1→紧急联系人2  仔细去用了,分析一下大胆猜测跳失率如此高的原因:

填写联系人系统需要读取用户通讯从通讯录中选取,当初在设计时候为了提高用户体验就将授权分散在各个步骤,需要用到时候才授权。

此处猜测之所以联系人2比联系人1点击跳变这么大,可能是在联系人1点击时候,获取用户通讯录授权让用户产生担忧而造成大量流失。

参考了其他竞品和世面上软件,所有授权在用户第一次进入APP之后就全部一起弹出。

4. 场景分析:此处无

5. 功能设计:

针对以上的猜测,做以下优化:

  • 1)增加身份证照片上传报错上报埋点,将报错原因上传至后台
  • 2)将提交身份证按钮报错也上传(以前前端拦截不上传),并上传报错信息
  • 3)在用户打开APP即获取所有授权,减少用户获取联系人时候

6. 优先级协调:

系统和业务已比较稳定,精细化运营优先级可以提高。

7. 资源协调:

依照6,只要价值阐述得当,团队认可,资源肯定到位,而且工作量很小……

8. 迭代计划(重点阐述一下):

  • 1)因为这个需求效果不能确定,不能做全量更新,但是我们当时没有ABtest支持。所以就想了一个折中办法,就是挑选一个量相对来说还可以,认证页面漏斗和整体没有太大差异,(记得选的是华为渠道吧,每天注册量1000多)
  • 2)进行内部非强制升级提醒,此处提醒一下,一定不要在某一个渠道发包,因为渠道会有抓包机制,因为你在A渠道新版本的包,其他渠道如果版本低的话会将A渠道的包抓去更新,这样不仅会导致包的渠道号错乱,而且万一所做的改动起到的是负效果,损失将会很大。
  • 3)观察数据,如果有效果则全渠道更新,如果没效果,则将定向渠道代码回滚,再次更新,等待后续新版本将所有渠道全量升级统一版本

后续又根据数据进行了多次优化验证,这里就不说了,直接说结果吧,优化的确有效果,联系人1点击→联系人2点击跳失率从原来的25%左右下降到16%左右,整体转化率提高了3个百分点样子。每个月可为公司节省17W左右推广成本(实际推广成本节省随着每个月目标不同而不同)。

第一步到第二步的跳失根据上报数据和猜想大体一致,但是后续还做了交互上优化,也提高了一点,这里就不再阐述了。

最后的话

最好我想说,方法论与框架是用来帮助我们的,不是用来限制我们的。

在自己对于需求分析不熟悉的时候或者需求比较复杂的时候可以套用框架来帮助我们找到解题思路,当我们对需求分析已经成为本能的时候应该学会放下框架和方法论,在实际工作中会遇到千种千样的需求,需求分析也要灵活多变,甚至有的需求就是改个文案,此时还陷入在框架或者方法论就无疑有点照猫画虎了。

以上是个人对需求分析的理解与总结,说的不到位地方请大神指点,也欢迎大家一起交流。

 

本文由 @wens 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 接地气

    回复
  2. 说的很棒,导出表格的需求太真实,基本天天都会见到~~还有类似的可不可以这里加一个XX按钮呀~~

    回复
    1. 是的,你说的不错,还有要加一个字段的等等等等

      回复
  3. 学习了

    回复
  4. 说的真好,感觉就是一直想说的,一直都没有深挖需求,就像你说的案例1,财务希望做两张Excel表格方便他核对,我在想如果我接到这个需求还真的会按照财务说的给他在系统里面怼两张表上去,看到后面了才清楚所有需求都要深挖一下,不然做出来的东西不光没有降低办事效率反而更加繁琐了,这样肯定是不对的

    回复
    1. 💪加油,我也怼过

      回复
  5. 学习了 😯 想请教下楼主,1目标分析2价值分析3业务流程4应用场景5功能设计,这5点会全部在PRD中体现吗?还是作为一个分析过程另外记录,在PRD中输出比较关键的内容,提交到程序猿or甲方?

    回复
    1. 1,2,4一般会在PRD的需求背景里做阐述,3,5是会在功能介绍里阐述
      提交给开发还是甲方这个是根据公司要求的。
      如果提交给程序员,要务实一些,需求背景简略有力,功能介绍详实、边界清晰、框架条例
      如果提交给甲方,要务虚一些,功能框架做简略介绍即可,多对背景、预期效果做阐述

      回复
    2. (#抱拳) 感谢回答
      现在手上的项目(已经做了一年)是个跨境电商自营平台,从0开始搭建到现在,总结起来现状是①迭代快,每周都会更新大大小小的功能,②支撑项目的团队人员较少,开发2~3人+测试1人+产品1人,③没有高度规范开发的标准,很多模块互相耦合或者模块耦合了业务,④当然也是团队实力不够强大。导致每日经常要做擦屁股的工作(也有业务上的细碎需求),小到改文案、改页面、给表加字段、给某字段的编辑权限加限制等等,留下来可以深度分析需求和撰写文档的时间剩得不多,所以需求提到这边后,文档只能输出一份,同时给甲方、程序猿、测试、自己看,所以最近在想着优化这个文档的框架,学习一些大腿的方法论,慢慢迭代

      回复
    3. 加油,可以的,初创公司可能避免不了你所说情况,越是这样越是要重视文档质量。祝你公司早日起来,但是创业公司死亡风险很高,无论怎样后续都会发现好好梳理文档的价值。

      回复
  6. 写的挺好的,我最近就遇到一个情况:财务的提了需求,也没说具体的内容,然后领导安排去做这个需求,需求调研什么的不用做 就让除原型…真的扎心!

    回复
    1. 非常理解你的感受,也遇到过类似的情况,曾经也为这样事情感到苦恼,苦恼之余也想着如何应对,以下是个人在长期的被蹂躏之中总结的一点应对方法,包括对待自己和对待他人,希望对你有所帮助:

      1.尽量能去联系你们财务,告诉他这个需求你可能没有理解到位,后续做出来怕不符合他的要求,导致他工作不能顺利进展。然后再去展开后续对话。避免去说他没说清楚,在你一步一步问细节时候,他自然而然会清楚的

      2.如果无法与财务直接取得联系,去和领导沟通,但是要站在领导的角度和利益来说这个事情,比如如果你的领导是老板,你可以说:老板,这个需求可能是我没有理解也有可能是财务没有说清楚,如果我直接来出原型,做出来东西后续会耽误财务工作不说,也会浪费研发资源balabala,最终目标是能直接联系到财务,并且让财务配合你,而且也为自己争取时间

      3.明确自己定位,教会别人来怎么和你沟通。每个人对产品经理的理解可能都不一样,可能老板想的是“你是产品经理,你不是专业的吗?怎么这个还需要问财务?”。对于这一点,我自己的理解是产品经理从宏观到微观的价值应该是:商业破局、产品方向把控、产品方案输出、项目管控。 那么以你自己的理解,你觉得你在公司的价值是什么呢?那么就把你自己对自己价值的理解在每一次沟通中都能体现出来(如给财务发邮件,可以说“我对财务业务细节不太懂,需要您指点,以便我形成更专业的方案方便你使用”),相信在一次一次的沟通表达中,别人就会知道下次怎么来跟你提需求,怎么探讨需求。

      以上只是个人总结感悟,不到位地方或者和你理解不一致地方可以灵活运用修改甚至,但是希望所说对你有所帮助。 😉 😉 加油兄弟

      回复
    2. 厉害了

      回复
    3. 财务的很愿意去沟通,但是领导不给时间

      回复