
前言
需求分析无疑是产品经理必备的基础,也是每个产品经理大部分时间可能都会做的事情,但大部分产品经理未必会刻意总结出一套方法论。一般来说,不总结方法论是不会有问题的。因为你熟悉基本事实,所以总结方法论并把它写出来有以下好处:
指导自己事情,在自己不知该若何着手做一个需求的时刻,可以为自己提供一个框架
磨炼自己的结构化头脑及总结能力
写出来与自己对话能提高自己的认知,会获得意想不到的收获
我平时比较懒,偶尔会写一些乐器,但是一般不能长期坚持,希望能一步一步坚持下去。
什么是需求剖析
个人需求分析是:通过确认目的地找到路径的过程。
从这个意义上说,需求可以分为两类:
第一类是终点对照明确,无太多争议性,此时的需求剖析主要集中在寻找路径。
第二类是终点不是异常明确、甚至是极为不明确,此时需要先确认终点再去寻找路径。
第一类需求主要包罗一些公司职能部门治理后台一些效率性工具、营销工具等
如:财务管理、订单管理、路由设置等。这些需求磨练了产品经理的基本功,包括业务流程排序、功效逻辑排序、功效列表和细节、提供最终解决方案、优先级协调、方案拆卸和迭代设计。
需要注意的是,这里说的终点对比是明确的,相对的。一些新人的产品经理容易犯的错误是,业务部门在后台要求什么我就拿什么。
这将很容易导致后续的变化,因为业务人员往往不会提到一个需求,而是一个解决他们需求的点。产品经理必须能够识别需求和解决方案之间的差异,并通过解决方案了解需求是什么。
举个简单的例子:运营人员提出一个需求,说,我想在推送设置界面增加一个EXCEL函数,导入推送人员列表。
这个要求看似合理,让运营快速导入推送人员名单,但仔细想想。这是一个要求吗?或者说这个要求的本质是增加一个EXCEL导入功能是产品的最终形态?这里不回复这个问题,以后会举一个类似的例子。
第二类需求主要是一些用户端需求
就像是引入了一种新的功效,一种新的玩法,优化了之前的功效。但是,这款游戏的实际效果谁也无法确定。与第一种需求相比,这种需求不仅需要磨练产品基本功,还需要产品经理规划MVP(最小可行产品)和数据分析的能力。
有人可能会提出,还有第三种需求,就是现在从0到1什么都不做。在本文的场景限制下,这种工作不是需求,而是需要一条完整的产品线,需要产品经理把握宏观,熟悉业务,对微观有掌控力。我暂时没有力气写这样的文章。如果我有同样的能力学习这类工作,我推荐学习梁宁的《产品心智30讲》和《提升心智30讲》,以后我会努力去理解自己的事情。
需求剖析框架
需求分析的框架,简单来说就是:值得做吗?是什么样的?怎么做?
价值是否值得做,需要分析目的和价值。什么样子需要梳理业务流程,分析使用场景,设计功效细节。具体怎么做,主要是确认优先级,调整设置资源,完成迭代设计。以下是个人需求分析的框架图:
严格来说,怎么做已经不在需求分析的范围内了。然而,当需求很大,RD资源不足时,我们需要考虑如何去做。比如优惠券系统,涉及模板建立、发放优惠券的操作、用户领取优惠券、使用优惠券、验证、数据统计等。当RD资源不足,业务急需的时候,我们需要把一个整体的大需求拆解出来,分多个阶段做。从这个角度,我们也可以到达需求分析的边缘。
2个案例
以下是我在自身事务中遇到的两个真实需求分析案例:
案例1:财政结算报表需求
企业支持者:
A公司是小贷公司的一级代理中介,职能是为小贷公司寻找二级渠道客户。用户可以通过二级渠道解决自己的业务,钱可以直接转给小贷公司(由于商业法律的限制,系统无法在用户付款时直接分账)。每个月底,小贷公司会分账给A公司,甲方分账给二级代理公司。
如下图所示:
当时财务就是这么跟我说的。也许上面写着-
“我需要一页两个结算报告,都有balabala字段,都有EXCEL导出功能。”
让我们应用需求框架来分析这个需求:
1。目的分析:
这个需求的受众是谁?-金融(空字…)
对别人有影响吗?-没有
这个要求的目的是什么?-是否需要列表并将其导出到EXCEL?
显然不是,因为前期有EXCEL,只是研发从数据库里拉出来的。她想要的是能够更高效的分账和对账,最终目标是“更高效的分账和对账”。
这里必须要说空,因为有些新产品公司是直接根据需求方的要求做这两种形式的。
2。价值分析:
这个需求有价值吗?它的价值是什么?显然,这只是一个优先顺序的问题。只要没有更高优先级的需求,这个需求就一定要做,因为无论是开发还是财务都可以节省时间。
3。业务流程梳理:
从上图可以看出,财务重点在于上下游账目的结算和审核。
4。场景分析:
在这里,由于这是一个新项目,我对这个业务条线的结算场景不是很了解,所以需要和财务部门进行以下对话(这一步极其关键,只有知道怎么用才能设计出相应的效果):
我:你能简单说明一下你将来会如何使用这两份报告吗?
财务:每个月底小贷公司转账,然后我用“对账单1”检查转账是否准确。每个月,我都会根据“报表2”计算一些应付账款渠道
我:那为什么要分成两份报告?研发前拉个报告给你不是可以吗?
财务:因为给渠道结算不能让他们看到成本,给小贷公司结算也不会给他看渠道成本,他们也不在乎(他们已经获得了第一次结算场景的全貌)。
我:那我给你打个报告。再打开会不一样吗?(我问这个问题不是偷懒,因为东西量相差不大,主要目的是含沙射影地挖掘它的使用场景。)
财务:这个还可以,就是差了点,有时候渠道要检查月中数据是否一致。此时,没有必要导出EXCEL报表并发送。只需切一张图对照贫困数据进行检查(获得第二个使用场景)
我:除了和解,表格对你还有其他帮助吗?
一套激活朋友圈大量好友,寻找潜在付费客户的方法。
财务:我们也会统计各个渠道带来的利润,看各个渠道的重要情况。
我:分成两个表你怎么算利润?
财务:(财务有点犹豫,之前没想好)我可以自己把表格组合起来,调和一下(第三场的全貌我拿到了)
从上面的对话中可以看出,财政局提出的方案并不能满足她自己所有的使用场景,虽然后续的对话中还有一部分关于功效的细节,这里就不赘述了。
可能有人会问,财务是对的,她现在把两种形式结合起来,自己一个人对账就可以了?
所以首先是穷到很容易出错。最重要的一个问题是,如果她要做一个表组合,必须保证后台找到的两个表的数据排序是一样的,否则数据会错位!如果直接开发推出,后面就要面临一个问题——需求交换# @!¥%@%¥!%¥
5。功效设计:
有了详细的使用场景,在业务理解和基础功效设计上就不会有什么问题,产品形态也很简单。最终的互动草稿直接附在下面:
至于后面的步骤,这个例子就不用做了,因为效果简单,东西量小。
案例二:优化认证转化率
小贷公司整体业务流程如下:用户登录注册→认证获取额度→申请→审批→支付。
由需求支持:
项目上线半年左右,业务已经逐渐稳定。所以我就想能不能提高业务效率。当时整体认证转化率在35%左右,直觉空大大优化了。于是我自己清空数据库拉了一个星期的认证相关的业务号和埋点数据,做了如下图:
这张图很容易看出,当你进入页面=并提交身份认证,联系人1点击=和联系人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。迭代设计(关注it):
1)由于这个需求效果不能确定,不能做全量更新,然则我们那时没有ABtest支持。以是就想了一个折中设施,就是挑选一个量相对来说还可以,认证页面漏斗和整体没有太大差异,(记得选的是华为渠道吧,天天注册量1000多)
2)举行内部非强制升级提醒,此处提醒一下,一定不要在某一个渠道发包,由于渠道会有抓包机制,由于你在A渠道新版本的包,其他渠道若是版本低的话会将A渠道的包抓去更新,这样不仅会导致包的渠道号庞杂,而且万一所做的改动起到的是负效果,损失将会很大。
3)考察数据��若是有效果则全渠道更新,若是没效果,则将定向渠道代码回滚,再次更新,守候后续新版本将所有渠道全量升级统一版本
随后基于数据举行了很多优化验证,这里就不说了。直接说效果吧。优化确实有效果。联系人1点击→联系人2点击的跳转率从25%左右下降到16%左右,整体转化率提升了3个百分点。每个月可以为公司节省17W左右的推广成本(实际节省的推广成本因每个月的目的不同而不同)。
第一步到第二步上报的数据与预期一致,只是交互在后面做了一点优化和改进,这里就不讨论了。
最后的话
我最想说的是,方法论和框架是用来辅助我们的,而不是用来限制我们的。
当我们不熟悉需求分析或者需求对比很复杂时,我们可以应用框架来帮助我们找到解决方案。当需求分析已经成为本能,我们应该学会放下框架和方法论。现实中我们会遇到成千上万的需求,需求分析要幼稚多变。甚至有些需求只是为了改变自己的文案。这个时候,如果我们还停留在框架或者方法论上,无疑有点像猫画虎。
以上是个人对需求分析的理解和总结。不到位的请求神指教,欢迎大家一起交流。