需求分析，需要有层次的分析
编辑导语：作为一个产品经理，每天要接触到大大小小不同的需求。要对这些需求进行分析，才能更好地了解问题，从而制定相应的解决方案。那么，怎么做到有层次的需求分析呢？本文作者基于自身经验，对此展开分析，希望对你有帮助。
一、前言
以前我作为一名设计的时候，总有老板或领导对我和我的小伙伴们说：“你们要用产品思维去看待问题！”。
但是我是不屑一顾的，因为我们的产品经理当时除了画原型之外每天就是在和我们扯淡。因此产品经理在我的眼中，就属背锅这个能力让我佩服了，毕竟画原型图在身为设计的我看来简单极了，不过背锅这个能力确实是让我佩服的，毕竟锅背起来面不改色。
直到有一天我发现我可能真的不喜欢做图，于是我想了一圈我还能干什么？开发，头发会加速离开我的，不行；文案，整天想文章热点，脑细胞死亡，不行；测试，大部分都是妹子，好像可以啊……可是好像不好进啊！思前想后觉得好像就只剩下做产品啦！
以上属于个人经历的调侃，实际上我还是很感谢我还是设计时候的产品经理的，是他把我带进了门，让我对产品有了另一种不同的看法。
而我在立志于做个产品经理之后，开始看产品经理书籍，看其他优秀的产品经理的文章，再后来看系统的产品课程，从散漫学习到系统学习，发现自己好像会点什么了。
但是回头观看，我会什么了？连个需求分析都不会，真是属实够菜！
虽然不会需求分析，但是有了需求不能说自己不会啊。上网就是一顿找，找到很多需求分析的干货。一开始只知道SWOT分析、需求三要素等方法时，还是很好用的；后来知道的越来越多后，分析的就越来越混乱，哪个都想用，哪个都合适，但是最后发现还是用自己最常用的。
二、停下的思考
根据我过往浅薄的经验来看，我对需求分析的理解是：通过用户的问题，找到用户需求的最本质，给予最合适的方案，满足用户。听起来好像很准确，但是这个就好像，有人问你，你吃饭的意义是什么？本质是为了什么？我吃饭是为了维持身体机能，本质是为了活着。
还有领导对我说用产品思维去看待问题，什么是产品思维？我以前对产品思维理解是：不在其位不谋其政，换位思考，把自己放在需求方的角度去看问题，再用自己的专业知识去规划产品方案。
我现在感觉这个理解过于空洞，但是当时我觉得这个很准确，而且这个也指导我前行了很久。
虽然以前一直是这样的理解，但是用来指导用户三要素分析也是很合适的，而且从用户、场景、诉求来分析日常需求是足够用的，而且反馈到我们这边的需求也是产品需要改善的地方，在优先级排期的时候用四象限分析一下，然后按照排期等待进入开发就可以了。
而让我有不同思考是在一次年度战略会议之后，领导们通过对未来一年的规划和商讨，决定把公司产品的一个重要功能给改名字，改名字原因有几个：
要改的这个新名字申请了商标；
这个新名字在上一年的其他资料里面已经先展现给用户了，也就是说用户已经适应一年了；
改名字是为了打造自己的品牌特色，与市面上其他同类产品做出区分；
在公司年度战略和规划里这个功能需要改名字。
但负责这个功能的产品经理不想改名字，因为以前其他资料在试行的时候，有很多用户反应这个名字是错别字，但是奈何“胳膊扭不过大腿”，拖了几个月还是改了。
这件事引起了我很大的关注，我是很支持这个产品同事秉持着为用户负责的态度，向公司极力表达为什么反对改名字，虽然最后被领导的权力狠狠地压过去。此事我仔细想了一下，这个改名字真的只是“政治任务”么？
不全是，这并不单单是“政治任务”，还是公司战略的一部分，而公司战略是企业发展的方向。这改变了我以前对需求的看法，我对需求重新定义为：符合公司战略发展、用户期望的、可实现的需求。
战略发展是要排在第一位的，接下来才是要考虑用户期望和可实现，当然这个不是绝对的，要根据实际考量，不同公司不同机构对同样的需求是考虑不同的。就比如脑-机连接技术这种需求，对于马斯克的Neuralink来说是要考虑战略，但是我们公司来说真的是需要先考虑可实现的能力。
而既然考虑需求时，大部分是要先考虑公司战略的，那对于需求分析也是要重新整理的，毕竟需求分析是要用来分析需求的。
因此我对我现在的需求分析方法做一个梳理，不能再只是从用户、场景、诉求来分析需求，应该有更多的方式去思考。而且经历了长时间的思维固化，我如果再不梳理一下，可能我就废了，于是我罗列了一些我知道的需求分析方法。
这一看，我知道的不算太少，但是我平常用的就只有需求三要素和四象限分析。其他的分析方法只是在我的脑海中过了一下，还有的一些分析方法是自知道之后，就没有再想起过，真是让它们受委屈了。
三、需求分析的梳理
在对需求分析进行梳理前，需要对产品思维，或者说是思考的方式重新梳理，我觉得思考应该是：从时间维度、空间维度两方面进行有层次的、有结构的思考。而用这样的思考方式重新去看待需求分析，首先就是对需求分析的方式进行思考，找到每个分析方式应该在的层次。
分析的层次：这次对分析方式重新梳理，从上层到下层，我把需求分析方法分成了三个层次，分别是上浮层、落地层、游离层。
1. 上浮层
上浮层其实就是宏观框架，是与政治、经济、科学、地理都有很深的联系，是一种从全局考虑的谋划，以实现目标方向的指导规划。
1）PEST分析
以前我觉得这个很虚，虚的不要不要的，后来觉得这个才是需求的根本。如果没有现在的国家稳定和社会繁荣，企业能不能像现在这样发展这么好，还真挺难说。
而且宏观方面的东西知道大概框架就可以，过于关注也没有必要。但是对于特定行业是需要对不同的方向有重点关注，比如教育行业重点关注国家条例和指导文件，外贸行业关注国际环境和国家文件，等等。
2）市场分析
市场分析里面包括市场容量、市场趋势、市场格局和竞争力分析。市场容量可以分析某一行业是多少金额的体量；市场趋势可以判断市场的机会点；市场格局就是分析有哪些巨头；竞争力分析就是对于优劣势的比较判断。
对于市场分析可以让我们挖掘细分市场，并且判断我们的产品走什么路线，应该突出哪些功能。如果产品特色很难打造，或者需要投入很大才能打造出超越同行的特色产品，我们是不是应该放弃，转投另一个方向？
3）公司战略
公司战略是公司依据本身资源和实力形成自己的核心竞争力，并通过差异化在竞争中取胜，是公司发展的方向。在我个人的的认知里公司战略就是让公司合法、快速且有节奏的抢占用户和市场，然后赚钱。
所以我们必须对其优先考虑，除非你对公司了若指掌，你的方法比公司的战略指导还要赚钱，那就听你的，要不然好好思考公司战略怎么执行，证明领导的想法是对的，这是战略级的“政治任务”。而且前面的PEST分析和市场分析，就是让我们对于公司战略可以有更好的理解。
2. 落地层
不管多么好的规划指导，需要有东西（产品、经验、技术等）可以执行，而落地层的分析方式就是把我们可以执行的东西进行抽取、转换、分析，然后去实践、去验证。
1）用户分析
用户就是基本盘，这里的用户主要是指产品功能的使用者。对于用户画像的构建，我们大家都是比较熟的，这里就不赘述了。着重强调一下，用户故事地图和心理分析，我们需要从用户的视角去看问题，听起来好像是废话，但是我要说的是，像用户一样去亲身经历整个流程。
比如，公司是非学历培训公司，我们就自己从买课前的心理活动开始，到最后去考试，自己亲身经历一次。但是如果是幼儿教育培训公司，没孩子的可能需要去借一个了，孩子哭了还 Ta 就好了，嘿嘿。
2）需求分析
需求三要素：用户、场景、诉求。这里的用户指代范围很广，比如老板、产品功能使用者、业务部门、运营部门等。有时候干系人并不是需求提出方，我们需要先确定干系人，然后去分析这类人在什么样的场景（场景的核心是在空间加时间的点上触发别人的情绪）下，产生了什么诉求。
然后去构思解决方法，最后反复询问自己解决方案是不是满足了用户人性级需求，如果没有，那是不是还有什么改进办法。
3）优先级分析
对于优先级分析，方法有很多种，方法无好坏，我们需要的是在正确的实际用正确的方法。
四象限分析：时间管理理论，按照重要紧急两个维度，分为四个象限，具体方法：时间“四象限”法；
Kano分析：以分析用户需求对用户满意的影响为基础，判断方法：知乎Kano分析和MBA智库·百科Kano分析；
生命周期：产品策略和需求优先级策略在生命周期不同阶段会有明显差异，产品生命周期大致可分为初始期、成长期、成熟期、衰退期，在不同的时期侧重的是不同的，比如在初始期时，产品/技术要重于运营和营销，这个时期的策略是打造特色，并且刚需功能要满足使用，不要掉链子。当然这个要根据各自的行业，各自的产品去考虑，别人的经验只是参考；
产品机会点：在《产品思维30讲》里梁宁老师讲过痛点、痒点、爽点，这些实际上和Kano模型里面的基础型、魅力型、期望型是想通的，我说这个是因为在《幕后产品》里面有讲到导入歌单需求，这个需求在二八原则里面，属于20%的长尾需求，只有少数几个人在讨论。但是这个功能给网易云音乐带来了近百万个活跃用户，这个导入歌单需求应该算是爽点，是魅力型需求。
3. 游离层
贯穿，是我对这一层次的定义。它贯穿上浮层和落地层，不管是思考宏观问题，还是考虑执行问题，都需要用这些方法来思考。
1）真伪需求
需求的真伪判断，在产品的生命周期里，是司空见惯的。我们需要对每一个需求进行判断，不管是宏观层次还是执行层次。
而对于真伪需求的判断总是模棱两可的，我们需要根据产品生命周期、当前公司战略、技术水平、销售情况等很多情况进行斟酌，同一个需求在不同时期下都有真伪之分。
2）数据分析
从战略到产品的制定和执行，都是离不开数据分析的。
在《数据资产论》里面，作者定义数据资产为：能够产生商业价值的数据。而从这本书中我得出我们数据分析的目的，就是为了实现公司的商业价值，我们分析的数据，就是能够产生商业价值的数据。
3）风险和对策
对于风险，我们平常考虑的主要是项目延期和项目变更。对于宏观方面的风险预测我们是很少考虑的，毕竟能发生的也很少，但是我们身边很多产品很大程度上是在和政策抢时间，比如网贷、游戏、教育等。
因此对于风险的预测要考虑更多，不仅仅只是局限在技术的实现难度。而对于可以预测的风险，我要提前想好对策，对于不能预测的，我们需要在遇到时及时想到对策。
4）投入产出
这就是需要我们对于投入和产出做一个平衡关系，而且需要我们对于目标是明确的、量化的。
在需求分析时，这点是需要着重考虑的，公司的目的是为了盈利，而一项在前期投入很大收入预期却很模糊的项目，我相信对于大多数老板都是不愿意投资的。
四、分析的使用
以前用5W2H来分析需求的时候，总有一些用不完整的感觉，可能是对于产品开发来说，考虑在哪里（Where）和由谁做（Who）总是很多余，因为地点是办公室，人是研发人员，万古不变，后来就逐渐放弃了，只用用户三要素进行分析。
有一次想起高中政治老师教我们记知识点的时候说过，你们记知识点的时候，用是什么，为什么，怎么做来记。就比如，价值规律是什么，价值规律为什么这样，我们怎么来应对价值规律。
我觉得和5W2H很类似，于是斗胆用2WH（What、Why、How）来简记。我套用这个公式来分析用户三要素，发现这个和用户三要素配合起来十分契合，而且还可以扩展到很多方向。
举个例子：情人节到了，小张因为工作忙，忘了这个节日，女朋友很生气。小张想给女朋友准备一个礼物，来让自己免受折磨之苦。
1. 是什么
用户是谁？
什么时间发生的？
人物参与都是谁？
小张自己的解决方案是什么？
……
2. 为什么
3. 怎么做
方案一：道歉，买口红；
方案二：道歉，买包包；
方案三：道歉，买衣服；
方案四：道歉，买口红、买包包、买衣服；
方案五：分手！
五、需求分析的具体使用
上面那个小例子比作一个需求的话，看起来实际上只要2WH就可以了，不需要对需求分析方法进行分层，而且实际用起来确实是如此。这个问题我也想过，为什么我还要对需求分析进行分层，而分这些层次看起就是要写分析报告才会用的，平常分析很少用到。
因为在平常的工作中，有时候我对需求套模板用2WH和需求三要素分析完后，得到一个初步的结论，然后开始画原型，原型都画的差不多啦，突然想起，我这个功能下一步要怎么展开？如果用的人少，没有反馈怎么办？
当然这种情况是偶尔的，一般来说，是不会想下一步的，是先做出原型，评审之后，开发上线，看反馈，看其他部门的需求，毕竟需求总是源源不绝的，没有一开始就完美的功能，总是在不断完善中改进的。
我很少从整体的全局的角度去看待整个产品，所以用分层是来指导是我到底应该怎么做，分析到哪一步，这么分析是不是合适。
举个例子：现墨文化公司（希望有生之年我可以成立这个广告公司）是一个想要以中国传统文化为锚点，主打传统文化特色的广告公司。公司刚成立两年左右，广告只是局限在周边的小公司，辐射范围很小，于是公司老板想做个小程序，借助互联网的东风和地推的方式来快速推广自己的门店，打出自己的名声，接下巨多业务，成就财务自由。
以下为部分思考：
Q：公司老板想做什么？
——小程序
Q：公司的主要客户是哪些？
——小公司的老板或者设计部门，大公司的宣传部门或者设计主管
Q：这些对标的客户有具体分析么？
——没有，纯粹是按照老板直觉
Q：公司的广告制作品质质量怎么样？
——还算可以，对比其他小广告公司要好点，对比大公司广告差点
Q：为什么要做小程序？
——借助换联网的传播能力，提高自己的辐射范围
Q：怎么做，用哪个平台？
——有360、微信、支付宝等渠道，首先以微信为主要平台进行传播推广
Q：规划这个小程序需要展示什么东西？突出什么重点？
——首先是公司作品内容，需要以什么展现形式来突出重点的特色，画板，全屏，或者是全景图；其次，需要加分享奖励，推荐客户有奖励；先上线预约功能。
……
这样分析是顺着思路直线下来，有时候会走入深度误区，需要借助表格来辅助。
上面是我对于我这个做小程序的需求进行分析，有点粗糙（虚构出来的故事想太深有点难）。
而且对于其中的每一个小问题，都可以进行2WH再度发问，比如产品的主要功能是什么，为什么要做这个功能，怎么做这个功能等等。模板只是框架指导，探究深度需要看自己的产品，自己所在的行业，是不是需要更深的自问。多层深度发问，借助思维导图可以更好的分析。
表格的内容是可以按照自己的产品进行增删的，选择自己最常用的，然后发散其他，最终选择出最合适的方案。
六、总结
上面的分析方法，实际就是根据自己分析常态，制定相应的模板进行分析，而且分析的广度和深度都可以进一步扩展，没什么难度，难度是需要思考关键目标、关键行动、关键依赖，然后对各方面的进行权衡。
但是怎么判断什么是关键的信息，这个就要大量的工作去锻炼，需要对整个行业和公司的产品足够了解。
参考资料
《幕后产品》
《数据资产论》
《产品思维30讲》
知乎文章：什么是卡诺KANO模型？
本文由 @墨惜白 原创发布于人人都是产品经理。
题图来自 Unsplash，基于 CC0 协议