需求分析的过程和方法，从需求收集到需求落地
需求分析的过程和方法，从需求收集到需求落地因为工作情景中的需求大部分来自于用户，因此本文也主要以用户需求分析为主，其中部分内容同样适用于其他需求来源主体。不管是来自于哪种渠道的需求，都要将其沉淀到需求池中，并进行需求分析。在需求分析前，需要先了解我们接收得到的需求一般来自哪。按照主动性划分，需求可以分为被动来源和主动来源。被动来源就是来自于老板，用户以及运营等产品相关岗位的反馈。主动来源的渠道就很多了，主要包括定期的用户访谈、运营数据分析、竞品动态追踪、内部会议研讨等。
需求分析可以说是产品经理最常见的工作之一了，无论是新产品的上线还是产品迭代都离不开需求分析。需求分析决定着产品的研发和迭代方向，一旦出现偏差就会和用户的真实需要背道而驰，因此掌握正确的需求分析方法论也就特别重要。作者就需求收集到需求落地过程中，应当如何完成需求分析才能够更全面展开分析，一起来看看。
什么是需求呢，用最简洁描述其实就是用户在一定场景下尚未解决的需要。用户，场景和需求内容三者缺一不可。从开始的用户需求到最后的产品需求，背后有一个需求分析的过程。
不同的产品经理所采用的需求分析方法和流程并不完全一致，段位越高的产品经理分析流程可能越简约。但基本的宗旨都是一致的，那就是发现用户最本质的需要，进而提供相应的产品功能去满足它，为用户创造价值。
本文尝试归纳一种普遍性的需求分析流程，可以快速地运用到工作中去。
一、需求来自哪在需求分析前，需要先了解我们接收得到的需求一般来自哪。按照主动性划分，需求可以分为被动来源和主动来源。
被动来源就是来自于老板，用户以及运营等产品相关岗位的反馈。
主动来源的渠道就很多了，主要包括定期的用户访谈、运营数据分析、竞品动态追踪、内部会议研讨等。
不管是来自于哪种渠道的需求，都要将其沉淀到需求池中，并进行需求分析。
因为工作情景中的需求大部分来自于用户，因此本文也主要以用户需求分析为主，其中部分内容同样适用于其他需求来源主体。
二、需求分析方法论1. 需求是什么
需求是什么，也就是用户对需求的描述。这里有两点需要注意，一是要收集来自于用户的客观需求，所谓客观，就是产品经理不能引导用户说出自己的需求。
第二就是确保需求描述的完整性，这种需求发生在什么场景，用户的具体需要是什么。需求一定是和场景结合的，脱离了具体场景的需求也就丧失了其价值。
2. 为什么会产生这种需求
在接收了用户需求具体内容之后，产品经理需要分析为什么会产生这种需求。了解了原因之后，其实也就为下一步的产品研发或迭代指明了方向。
但就是这一步其实对产品经理的定性能力要求很高。“用户需要的是汽车，而不是一匹更快的马。”福特发明汽车的故事相信大家都已耳熟能详。在与用户的交流中，想要洞察用户表面需求背后的底层动机并不容易。
最容易想到的角度就是马斯洛需求层次理论，可以从这个角度来思考用户提出的需求是否契合其中一点。马斯洛把需求从低层次到高层次分别为七个层次：生理需求、安全需求、归属与爱的需求、尊重需求、认知需求、美学需求、自我实现的需求。例如用户希望自己的抖音账户可以设定为私密账户，其实就是为了满足安全需要。
除了最底层的需求层次理论以外，也可以思考该需求能满足用户什么欲望，例如被激励，收集控，强迫症，利益相关，新鲜感等等。例如用户希望app可以有成长体系，就是满足自己的被激励需要。
一款好的产品是一定能够满足人性或者是欲望的。
第二可以从角色—场景—路径的角度来分析，用户的同样的需求，换个用户是否存在，换个场景是否成立，改变使用路径是否存在？如果是，那么这个需求就是用户、场景或者是路径决定的需求。例如各大app出现的老年人模式，各种音乐app出现的车载模式，根据查询单号自动带出对应的快递公司等。
第三可以从更为宏观的系统运行的角度来思考，用户的需求是否是为了提升效率，节约时间，促进系统生态的完善，或者是解决当前用户使用阶段/业务阶段出现的问题等（这里需要思考仅靠产品能否解决问题）。
例如用户说它需要更快的马车，背后实际上是对效率的渴求，网易云音乐推出评论的功能，除了满足用户的自我呈现需要，从系统生态的角度来看，信息接受和信息传播一同才能构成完整闭环，否则用户只听到经典的音乐而感慨万千，却无处释怀。
总而言之，在倾听了用户的需求之后，需要从多个角度洞悉用户需求背后的深层次原因，这样才能让产品准确解决用户痛点。
3. 需求做不做
收集了需求，也弄清了需求的背景和原因，那么这个需求到底要不要做呢？
这需要从多个层面来考量：
（1）用户层面
首先要思考的是这个需求解决了用户哪些痛点？这个需求是否具有高频性，是否是强需求？例如每天都要吃饭，这是强需求，每天都要刷2次牙，这是高频需求。如果用户提了一个需求，既不高频，又不属于强需求，就要考虑到底要不要上线该需求。
再则是从用户体验的角度，这个功能实现前后用户的使用路径会发生改变吗，这个需求会牺牲用户体验吗，如果是以牺牲用户体验为代价的需求，也需要权衡。
最后是思考它是不是个“伪需求”。“伪需求”就是呼声最为强烈，但上线发现其实并没有什么人用，效果并不理想的需求。之所以会产生这样的现象是因为，互联网时代声音由“沉默”转向了“沉没”，很多用户的声音我们其实并没听到，表面上很大的声浪远不能代表大部分人的想法或者需要。要避免“伪需求”，需要做细致的用户调研。
（2）产品层面
先定位开始说起。产品经理应该始终明晰自己产品的定位所在，一切需求都要的服务于产品的当前定位。例如你不能因为司机在等红灯时无聊，就要求滴滴打车上线游戏功能。
这里需要注意的是，有的需求可能符合产品定位，但不是产品当前阶段要做的事情，也需要排除。例如在产品冷启动阶段，应该聚焦于核心使用路径与核心需求，其他需求即使合理，但也不是当前阶段应该做的。
其次要考虑的是，现有产品功能是不是从侧面也可以满足用户所提出的需求。例如很多人呼唤微信语音进度条，但是微信的语音转文字方案，在大多数场景下其实从侧面就能替代语音进度条。
最后还要从整体的角度思考新需求是否会影响产品设计语言。例如淘宝上线直播的功能，这就需要从设计语言的角度对产品进行重构。因为直播是个大风口，所以这样的需求不得不做。但是其他的需求如果影响整体设计语言，势必也要仔细思考一番。
（3）商业化层面
商业化层面主要需要考虑市场规模，商业模式和成本预算方面的问题。小的功能性需求其实并不需要考虑市场规模和商业模式这样长远的问题。但是一个大的功能上线，就要考虑到它的引流效果，可能带来的盈利增长点。例如抖音在其app中上线“抖音商城”，这是一个非常大的动作，必然要考虑到市场规模，商业模式这些问题，正是电商市场空间远未饱和，所以字节才开始布局。
无论是什么需求都需要考虑成本预算。这里的成本分为研发成本与非研发成本。研发成本很好理解，非研发成本主要包括用户教育成本，内容是否需要人工审核，以及各种运营推广成本等，非研发成本其实就是如何让用户喜欢上这个功能的成本。王坚老师在《结网》一书中有提到，一般而言可以按照研发成本占20%，非研发成本占80%进行测算。
（4）内外部资源情况
巧妇难为无米之炊。需求做不做有时候也不是自己能决定的。
产品经理针对当前需求需要思考，哪些核心资源是已经具备的，哪些是欠缺的。如果当前相关资源欠缺，需要外部的合作伙伴吗，如何进行协调沟通，这些都要思考全面。
拿到一个需求，放到上面这些维度进行考量，可以解决大部分的需求做不做的判断性问题。但是有的时候，可能并不需要这么复杂，就一句话，老板要你做，你能不做吗？
4. 需求做什么
如果把需求进行划分的话，无非就两种，别人已经做过的需求和别人没有做过的需求。如果是做别人没有做过的需求，我们直接进行大刀阔斧的创新就可以了。但创新毕竟是少数，很多时候我们做过的东西别人早就有类似的概念出来了。像微信这样现象级的产品最初也是来自于Kik Messenger的产品概念。
有一句话讲的特别好，不要重新发明轮子，因为没有产生价值增值。那剩下的就是别人已经做过的需求了。虽然别人已经有了，那么我们也可以思考的是，能不能二次创造价值和放大价值？这才是关键。
可以的创新点有其实有很多，比如说更新的体验，更新的技术，更好的商业模式，更适合的时机，更强大的平台，更完善的管理。例如同是短视频平台的美拍和抖音，抖音赋予了用户全新的体验，同时电商，有人To B，有人To C，有人To B2C，这就是商业模式的不同。
之前我就特别不理解，为什么新浪要打造一个酷似Instagram的绿洲？后来对比使用发现，绿洲确实更符合国人的社交媒体使用习惯，而且国内缺乏图片社交app，依托于微博平台的强大引流，是很有前景的。也就是说，绿洲的产品需求源自Instagram的概念，但是却赋予了它很多的创新，这也未尝不可。
此外，对于一些细小的功能性需求，比如说脑洞大开的微信消息置底功能，因为它比较具象，就不太适合从更新的体验，更新的技术，更好的商业模式等角度来分析。这种情况可以借鉴HWM思考方法，它主要适用于头脑风暴前去寻找解决问题的方向，扩展我们的思路。 HWM思考方法主要包括否定，转移，积极，脑洞，分解几个部分。
就拿微信消息置底功能来说，这个需求本质是用户需要保护隐私，从“转移”角度来看，那可以出一个聊天框不显示的功能，或者是聊天框自主排序的功能，就不需要了置底这么奇葩的功能了。从“脑洞”的角度来看，当用户频繁删除与一个人的聊天记录时，下次退出聊天会主动提示是否隐藏与该用户聊天记录，或者推出阅后即焚的功能等等。
5. 需求怎么做
（1）优先级排序
在工作场景中，同时会有许多需求需要做，这时候就需要对需求进行优先级排序。常见的方法有KANO模型，四象限法则和金字塔型划分。
① KANO模型
在卡诺模型中，将产品功能/需求和服务的特性分为五种属性：必备属性、期望属性、魅力属性、无差异属性、反向属性。
魅力属性：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；
期望属性：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
必备属性：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低；
无差异属性：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意；
反向属性：用户根本都没有此需求，提供后用户满意度反而会下降。
KANO模型需要进行相应的用户调研，计算出相应的better-worse系数值，以确立需求的优先级。一般情况而言，在产品设计时，要尽量避免无差异属性、反向属性，着力抓住用户的核心需求，解决用户痛点，即基本型需求，在确保基本需求解决的前提下，为用户提供兴奋点，即期望属性与，魅力属性。
② 四象限法则
四象限法则将需求等级划分为：重要紧急，重要不紧急，不重要不紧急，不重要但紧急。
这里主要是涉及到两个判断标准，重要性和紧急性如何判断。紧急性很容易，主要看时间宽度，离deadline很近，那就很紧急。重要性则有根据产品的不同规划，依据实际工作场景确定，例如是否关乎核心功能使用，是否破坏了用户体验，是否影响产品商业化等等。
对于第一象限的事情，需要尽快分配资源，抓紧完成。
第二象限的事情，需要花80%的时间在上面的，精细化处理好。如果不及时处理完，就堆积到第一象限。
第三象限和第四象限相对来说是不重要的事情，但是它们也是需求，可以每天花费一定的时间，统一去处理。要注意这类需求要和第一第二象限的严格区分开来，不能因为边缘任务影响主线任务进展。
③ 金字塔型需求
金字塔型划分需求，将需求从下到上划分为四个模块：可用性、更佳体验、可扩展能力、生态。
其中可用性和更佳体验，是整个产品的最为基础的部分，更高层的可扩展能力，生态。都是在这基础上建构的。这种划分非常清晰，产品经理可以直接定位手头需求属于哪个层级，进而进行需求优先级安排。
（2）关键任务安排
根据划分出来的优先级，产品经理就要协调各方技术资源进行关键任务分配了，产品，UI，研发，测试团队共同合作，完成需求上线，最终向用户传递价值。当然最主要的还是前面的需求分析的过程，到这里关键任务安排，很多产品经理应该都是轻车熟路，就不再赘述。
三、结语我们梳理出了需求分析的一般流程，从用户需求表达，需求背后原因追溯，需求要不要做，到需求做什么，以及怎么做。
但是在实际工作中可能并不需要思考这么多，或者这么多的流程可以放在一起进行综合考量，尤其是对于资深产品经理来说，有的时候需求分析不仅是理性的思辨，更闪耀着感性的灵光。
总而言之，要了解条条框框，但也不能被条条框框所限制。
作者：我的鞋子大了，青芒产品笔记，定位于个人产品学习成长平台
本文由 @我的鞋子大了 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
