本文给出了将需求分为两类——工具类需求、客户端需求的更容易理解的两种情况。
前言
需求分析是产品经理的必备基础工作，每个产品经理可能大部分时间都在工作，但大部分产品经理可能不会刻意总结方法论。 总的来说，不总结方法论也没什么问题。 因为我熟悉基本的工作。 但是，总结写方法论有以下好处。指导自己的工作，在不知道自己该如何着手需求的时候，给自己提供框架锻炼自己的结构化思维和总结能力，可以和自己对话提高自己的认知，取得了意想不到的成果，个人平时也很懒，通常会写东西很久
对
什么是需求分析
人需求的分析，是确认终点寻找路径的过程。根据这个定义，需求分为两类。
一是目标比较明确，没有太大争议性，此时的需求分析主要集中在寻找路径上。 二是在目标不明确或极其不明确的情况下，有必要在确认目标后再寻找路径。
第一类需求主要包括一些公司职能部门管理后台一些效率性工具、营销工具等
例如财务管理、订单管理、路由配置等，这种需求考验产品经理的基本功。 包括业务流程整理、功能逻辑整理、功能列表和详细信息，提供最终的解决方案、优先级调整、程序分解和迭代计划等。需要注意的是，这里所说的目标比较明确，而一些新人产品经理容易犯的错误，无论业务部门提出什么样的后台需求，我都会承担。
这很容易导致后续的变化，因为业务人员通常提出的不是需求，而是解决他们所认为的需求点的计划。 产品经理必须认识到需求和项目群的区别，并通过项目群确认需求本身是什么。
举个简单的例子，运营人员提出了需求，他说希望在推送配置界面中添加EXCEL，引入推送人员名单功能。
这个需求看起来很合理。 这样运营就可以迅速导入推送人员名单，仔细想想这是需要吗？ 还是说，这个需求的本质是，添加EXCEL的部署功能是产品的最终形态？ 这个问题我不在这里回答，我举一个相似的我在工作中遇到的实例。
第二类需求主要是一些用户端需求
例如，推出新功能、玩新游戏或优化以前的功能。 但是，大家不太清楚这个玩法是如何有效的。 这样的需求，除了针对第一类的需求，考验产品的基本功外，还需要产品管理者计划MVP (最小可执行化产品)的能力、数据分析能力等。可能有人会说有第三种需求，但是现在什么都不从0~1开始做产品。 仅限于这篇文章的场景，这种东西不是一个需求。 这是要建立整个产品线。 也就是说，产品经理需要对宏观的了解、对业务的了解、对微观的控制等能力。 我个人没有写这样文章的实力。 如果学生想学习这样的能力，我建议学习梁宁的《产品思维30讲》，《增长思维30讲》。 之后，个人也简单谈谈自己对工作的理解吧
需求分析框架
需求分析框架用比较直白的话来说，值得吗？ 你要怎么做？ 怎么做？价值与否需要分析目标和价值，采取什么形式需要组织业务流程，分析使用场景，设计功能细节，但如何做主要是确认优先级，调整资源，完成迭代计划。 以下是个人总结的需求分析框架图。
严格来说，怎么做已经不属于需求分析的范畴，但面临的需求比较大，在研发资源不足的情况下，有必要考虑怎么做。 例如，优惠券系统涉及模板制作、运用发行券、用户领取券、使用券、核销、数据统计等，当研发资源不足业务急需时，需要分解整个大需求，分多期进行。 mndhd也将触及需求分析的边缘
2个案例
以下是自己工作中遇到的两个实际需求分析案例：
案例1：财务结算报表需求
商业背景：公司甲方是某中小信贷公司的一级代理中介，其功能是为小额信贷公司寻找二级渠道客户，用户通过二级渠道办理业务，钱直接转账到中小信贷公司(由于业务法规限制，系统在用户支付时，
如下图所示。
当时的财务对我这样提出需求的大概就是这么说的——
“需要两个结算报告页面。 两个报告都有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协议