前言
关于需求分析无疑是产品经理的一项必备基础功,也是每个产品经理可能工作大部分时间都在做的事情,但是尽大部分产品经理可能不会刻意的往总结一套方法论。总的来说不总结方法论也不会有多少题目,由于究竟基本工作很熟手,但是总结了方法论并写出来有以下几个好处:
- 指导自己工作,在自己不知该如何着手做一个需求的时候,可以为自己提供一个框架
- 锻炼自己的结构化思维及总结能力
- 写出来与自己对话能进步自己的认知,会获自得想不到的收获
个人平时也比较懒,偶然会写些东西,但是通常不能长久的坚持,也希看自己能慢慢坚持下往。
什么是需求分析
个人对需求分析就是:确认终点寻找路径的过程.
从这一定义来说需求分为2类:
- 第一类是终点比较明确,无太多争议性,此时的需求分析主要集中在寻找路径。
- 第二类是终点不是非常明确、甚至是极为不明确,此时需要先确认终点再往寻找路径。
第一类需求主要包括一些公司职能部分治理后台一些效任性工具、营销工具等
如:财务治理、订单治理、路由配置等,这类需求考验的是产品经理的基本功,包括业务流程梳理、功能逻辑梳理、功能列表及细节,提供终极解决方案、优先级协调、方案拆解及迭代计划等。
需要留意的是,这里所说的终点比较明确是相对的,有些新人产品经理比较轻易犯的错误是,业务部分提啥后台需求我就接啥。
这样很轻易导致后续改改改,由于业务职员提的往往不是一个需求,而是一个解决了他们所以为的需求点的一个方案,产品经理一定要能识别需求和方案之间的差别,透过方案看到需求本身是什么。
举个简单例子:运营职员提了个需求说,我想在推送配置界面里加一个EXCEL导进推送职员名单功能。
这个需求看上往很公道,这样运营就可以快速的导进推送职员名单了,但是仔细想想这是一个需求吗?或者说这个需求本质是加一个EXCEL导进功能是产品的终极形态吗?这个题目在这里不做回答,后面会举一个相类似的我在工作中碰到的实例。
第二类需求主要是一些用户端需求
比如推出一个新的功能、一个新的玩法、对以前功能做优化。但是对于这个玩法究竟效果如何,大家都不能很确定。此类需求相对于第一类需求除了考验产品的基本功以外还需要产品经理有规划MVP(最小可行化产品)能力、数据分析能力等。
可能会有人提出还有第三类需求,就是现在啥都没有从0~1打造产品。在这篇文章的场景限定下,此类不属于一个需求,这是要做一整条产品线,这即需要产品经理对宏观了解把握、对业务熟悉、对微观的有掌控等能力,个人暂时没有实力写这样文章,假如有同学想学习此类能力,推荐学习梁宁的《产品思维30讲》、《增长思维30讲》,后续个人也会尝试着从自己的工作理解中来简单谈谈
需求分析框架
需求分析框架用比较直白的话来说就是:值不值得做?做成啥样子?怎么来做?
值不值得做需要往分析目标和价值,做成啥样子需要往梳理业务流程、分析使用场景、设计功能细节,而怎么来做主要就是确认优先级、调整配置资源、完成迭代计划,以下是个人总结的需求分析的框架图:
在这张图上很轻易看出进进页面=》提交身份认证,联系人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左右推广本钱(实际推广本钱节省随着每个月目标不同而不同)。
第一步到第二步的跳失根据上报数据和猜想大体一致,但是后续还做了交互上优化,也进步了一点,这里就不再阐述了。
最后的话
最好我想说,方法论与框架是用来帮助我们的,不是用来限制我们的。
在自己对于需求分析不熟悉的时候或者需求比较复杂的时候可以套用框架来帮助我们找到解题思路,当我们对需求分析已经成为本能的时候应该学会放下框架和方法论,在实际工作中会碰到千种千样的需求,需求分析也要灵活多变,甚至有的需求就是改个文案,此时还陷进在框架或者方法论就无疑有点照猫画虎了。
以上是个人对需求分析的理解与总结,说的不到位地方请大神指点,也欢迎大家一起交流。
本文来自投稿,不代表微盟圈立场,如若转载,请注明出处:https://www.vm7.com/a/ziyuan/11545.html