需求分析是软件项目成功的关键，它通过明确客户需求、减少重复开发、节约时间成本、提高产品质量、降低需求变更率等方面为软件开发提供了核心的保障，更好的需求分析工作将帮助企业开发人员更好地开发软件，提高企业核心竞争力，并增加用户对软件稳定性和完善性的信任。
需求分析是需求管理里比较重要的一步，往往用户说的和Ta实际想要的不一致，提需求背后的动机是什么，需要我们分析。
比如，业务部门提了一个需求，想做一个积分系统，提升用户留存率。
那么，这个需求是要解决的问题是什么呢？是现在留存率很低吗？是什么原因导致留存率低呢?一定要做一个积分系统吗？做了积分系统是否就可以解决问题？
往往用户会把问题和方案混淆到一起，产品经理要懂得分析，识别背后的动机，不要说什么，我们就做什么。
很多人说的伪需求，其实我认为不存在伪需求，只是你没有挖掘到需求背后真正的动机。
那么我们该如何去分析需求？
「用户-场景-问题-现有解决方案」，即什么人在什么情况下做什么事情，遇到了什么问题，Ta现在是怎么解决的。
1、用户
在需求分析中，用户是分析的源头所在，我们需要理解产品的目标用户，并将其进行合理分类，才好列出相应分类用户的场景以及场景下的问题。
要注意这里的用户指的是一个群体中抽象出共同特征的集合，单个用户价值大，如：一线城市白领、大学老师、18岁的少女。他们在特定场景中，可能普遍遇到相同的问题、产生相似的需求。
2、场景
指用户要使用一个互联网产品有着其所附属的外在环境（比如时间空间）与内在心理状态（比如各种情绪），这些因素共同构成了产品的典型场景。
对于一个产品经理，「场景」是要经常挂在嘴边的词语。对任何产品的分析、用户问题的描述，都要是在一定场景下进行的。脱离场景的产品设计很可能没有办法解决真实场景下的用户问题。
场景的例子：
暑假某日，下午3点，烈日高照，我和队友在操场上踢比赛。
期末时期，我在图书馆复习功课。
周末下午1点半，我和对象到附近万达广场逛街。
3、问题
问题是用户在特定场景下完成某个任务过程中出现的，它是理想与现实状态的差距，有些人也直接将问题理解为用户需求或痛点。
比如，期末时期，我在图书馆复习功课，第5章的复习重点不知道是哪些。--备考指导需求
4、现有解决方案
这个概念很明确，就是他们面对问题做出了什么回应，不过需要注意的是，这个是用户现在这个时候所选择的解决方案，而并非未来产品可能提供的解决方案。此外，不知所措、无动于衷也是一种解决方案~
比如，
二、需求分析的步骤
信息收集阶段
评估阶段
角色：针对同一个功能，不同角色的需求不相同
场景：分析需求真实发生的场景，考虑实际情况，看时间、地点、人物、环境、事件或采用5W2H来进行分析。
流程：分析满足需求的关键路径，考虑是否完全满足。
4、分析商业价值
商业价值可以分为用户需求价值和产品方案价值两个维度，如果是B端，则是业务需求价值和产品方案价值两个维度。
用户/业务需求价值，由以下几个维度判断：
强度：用户对这个需求有多迫切，这点决定了用户的付费意愿以及留存相关性；比如，打工人每天忙忙碌碌，有些人习惯早上喝一杯咖啡清醒一下，提高效率，那商业办公楼下的咖啡厅的留存和用户付费意愿就很不错。
频度：用户触发需求有多频繁，用户的使用频率和使用次数；比如记账，有的人每天花一笔，记录一笔。
广度：用户持续存在需求的时长，这一点决定了用户未来的使用时长以及循环使用的周期；比如，K12教育就在小学到高中这12年，是用户的使用产品的整个生命周期最长也就是这12年了（排除复读这种特殊情况）。
长度：这个需求的用户群体有多大，这个盘子的市场有多大，蛋糕有多大；比如，web3是未来的趋势，市场是非常大的，还是有很多细分领域没有得到满足；再比如，养老，现阶段老龄化问题，早期婴儿潮时期的家长们，慢慢地都将步入老年阶段，相匹配的服务还是差很多的。
精炼阶段
比值大的可以优先去做。
三、四个需求分析的方法
方法1：用户故事和用户故事地图
在产品工作中，有时候会遇到这样一些问题：
做产品规划时，会漏掉一些关键功能，没有很好的需求分析方法论。
版本迭代时，只见树木，不见森林，不停的做功能需求，却忽略了产品全景。
研发拿到的是产品提交的功能需求，却没有弄清楚真实的用户需求，开发出来的功能达不到预期。
最近get到一个新技能，用户故事地图，利用用户故事地图，就可以解决以上问题。
1、用户故事
我们做需求分析，概括起来，可以分为两步：识别用户需求，转化成功能需求
在识别用户需求，并转为功能的过程中，有几个关键要素：用户、功能和希望达成的目标。使用用户故事，刚好可以把这几个关键要素串联起来。
用户故事可以发现用户需求，并定义解决方案，即功能。
在讲用户故事地图之前，先来说下用户故事。
用户故事，最早由Kent Beck提出，Kent Beck是敏捷开发创始人，提出用户故事的本意，是想解决共识的问题。
用户基于某个场景，提出了自己的需求，产品经理基于用户的需求提出解决方案，将其转为功能需求，研发基于产品的功能需求文档进行开发， 最终发现开发出来的功能根本就不是用户想要的。
或者本来可以有更好的实现方案，但是因为只看到功能需求，而没了解到用户需求，所以没机会把更好的方案做出来。
产品在产品的认知范围内做决策，研发基于研发的认知做决策，而产品的认知和研发的认知却不一样。
产品经理不断的细化需求文档，写得越来越标准，但不同的人，对相同的文档，理解不一样，共识问题想完全靠文档解决，是不现实的。
那如果让研发能知道用户的真实需求，是不是就能解决这个问题呢？
于是Kent Beck 就提出用户故事这个方法，大家都喜欢听故事，从一开始，就只说用户故事，而不是只说功能需求。
这样，产品和研发对用户需求的理解是一致的，能更好地达成共识。
2、 用户故事怎么写？
一个完整的用户故事，应该包含三部分内容：用户、功能、价值。
用户：是谁要用这个功能。
功能：具体是什么功能。
价值：通过这个功能，用户能获得什么价值。
通常用这样的格式表达：作为一个<用户>，我想要<功能>，以便于<价值>。
例如：作为一个<在外务工的农民工>，我想要<一匹马>，以便我<春节可以回家过年，与亲人团聚>。对于这个用户故事，由于产品经理没见过车，也不知道有车的东西，于是提供了马这个解决方案，但是开发人员知道有车，就会提出车这个更好的解决方案。
写用户故事地图，应该遵循几个原则：
独立的。如果两个故事有依赖，则合并为一个大的故事。
可讨论的。故事本身就是一个沟通的工具，用户故事不是合同，不需要写得过于详细。
有价值的。这是用户故事最重要的一条，要是没有价值，还做他干什么呢？价值让研发不仅做，还要知道为什么做。
可估算的。估算用户故事，可以帮我们更好地判断工期，评估是否有足够的资源，有多少人办多少事。如果不能估算，可能有几种原因：①研发不了解业务；②研发缺少技术知识；③故事太大。
颗粒度小的。过大的用户故事不便于评估，如果双周迭代，3-5天的颗粒度是合适的。
可测试的。如果故事不可测试，就无法衡量是否达到预期，是没有评判标准的。
3、用户故事地图
上面说了用户故事，再来说下用户故事地图。
用户故事地图，是由用户故事组成的全景图，用户故事由活动和用户故事组成，活动是完成用户目标的核心步骤，用户故事是根据核心步骤拆分出来的小任务。
例如，用户在电商产品，核心步骤可以分为：浏览商品——下单——付款——收货——评价，在浏览商品这个步骤里，可以分为更细的任务，如查看首页、搜索、对比、查看详情、查看评论等。
用户故事地图，有这样几个作用：
和业务、研发，甚至用户一起梳理需求，不遗漏关键功能。
在团队内达成共识，让项目成员有全局感，既见树木，又见森林。
更好的规划版本，每次新迭代，都是做的当前最重要的功能，不浪费研发资源。
4、梳理用户故事地图的方法
梳理用户故事地图，需要组织一次头脑风暴会议，参与人须是各岗位关键角色，包括产品负责人、项目负责人、业务负责人、技术和老板等，人数控制在7人以内，但不要少于3人。
这些角色可以从多个角度提供建议，使产品/功能更加完善。
开会前，要提前准备一些材料。最好准备一个白板、不同颜色的便利贴、胶带等等。
如果没有条件，也可以使用线上工具。
第一步，进行产品定义。我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。
第二步，梳理骨干故事。梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。
第三步，拆分故事。在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。围绕这个故事写更多细节。
在这个过程中，先让大家在一定时间内按照自己的想法写出来，把每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上
第四步，沟通确认。这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。
完成所有故事梳理后，就出现了下面这张图：用户故事地图。
方法2：HWM分析法
1、HWM分析法
HMW，即How Might We，它是处理产品需求的一种行之有效的分析方法。
找方向：HMW=解决这个问题的方向，打开思考的困局
扩展思路：把一个小问题大幅扩展，把问题想透
头脑风暴：暂时不需要考虑具体的方案，让头脑风暴更高效
创新点：让每个吐槽都可能被变成创新点
（1）为什么产生“我们可以怎样”的问题
“我们可以怎样”式提问（HMW）是可以引发头脑风暴的简短问题。HMW产生于你的观点陈述、或者设计理念，是创意构想阶段的种子。创造出来的HMW需要足够宽泛，包罗一系列广泛的解决方法；但是又要足够狭窄，使得团队的讨论有一个有帮助的边界。
举例：“我们可以怎样设计脆皮甜筒，才可以让冰淇淋不下滴”过于狭窄，“我们可以怎样重新设计甜品”又过于宽泛，介于两者之间的范围最合适的问法可能是，“我们可以怎样重新设计冰淇淋，让它的便携性更好？”
值得大家注意的是，范围核实的HMW问题，会根据项目本身、以及项目所处进度而有所变化的。
（2）什么时候用
头脑风暴前：解决头脑风暴效率的问题
分析用户反馈：在碰到用户反馈时，马上用HMW分析
和领导PK：用HMW对付领导是一个好办法
（3）最适用场景
面对明确的用户和问题：一类明确的用户，在碰到一个相对明确的问题最适用
锻炼自我的思维：把任何事情都用产品的思维来分解
通过『How might we…』和头脑风暴来发散，保证了我们不会错失有关产品设计的各种可能性和细节，通过卡片分组来抽象我们整理出想法中的产品逻辑和需求层次，而具体的 storyboard、workflow 和线框图的过程则保证了我们所有的想法和需求都能落地成为可见的设计。
举例：在产品设计流程中HMW的使用
（4）怎么产出“我们可以怎么样”？
从你的观点（Point of View，POV）或问题陈述本身出发。把大的挑战拆分成一些可执行的小任务。寻找问题陈述的多个方面，来填充”我们可以怎样...…?
案例：
挑战：在本地的国际机场，重新打造地面体验
观点（POV）：带着三个孩子的妈妈，急匆匆地冲进机场进站，结果却在门口等了好几个小时。这个时候她需要逗弄自己淘气的小孩儿们，因为这些“磨人的小妖精”只会激怒其他同样焦虑等待的同行乘客。
发挥积极影响：我们可以怎样 利用孩子的热情让其他乘客开心？
移除消极影响：我们可以怎样 将孩子和其他乘客隔离开？
逆向思维：我们可以怎样 把等待变为旅途中令人神往的一部分？
质疑假设：我们可以怎样 完全除去机场等候时间？
在形容词上下功夫：我们可以怎样 进机场变得“让人焕然一新”，而不是“急匆匆”？
找到没有预想过的资源：我们可以怎样 利用同行乘客的空闲时间，分散妈妈的负担？
从需求或环境中创造类似体验：我们可以怎样 让机场像 spa 中心？或者像游乐场？
从问题出发应对挑战：我们可以怎样 设计机场的体验（挑战），让孩子们（问题）愿意去机场玩？
改变现状：我们可以怎样 让淘气吵闹的熊孩子变得不那么烦人？
把问题分成多个小任务：我们可以怎样 让孩子开心？我们可以怎样 让带着 3 个孩子的妈妈放缓匆忙的脚步？我们可以怎样 安抚延误的乘客？
2、HMW的分解方法
（1）HMW的操作逻辑
（2）明确用户和问题
如：
用户问题：顾客到了餐厅，不知道吃什么？
产品价值/目的：提供餐厅的顾客满意度
用户问题：某O2O服务产品，用户在订单完成后，80%用户不会回来点评
产品价值/目的：提升用户的留存率
（3）拆解问题的方向
否定：如何想办法让用户放弃这个想法？
积极：如何让用户提升自己来解决问题
转移：如何让其他人解决问题，继而解决这个用户的问题
脑洞大开：不敢想的一些方案
分解：把很大的问题拆解成2-3步
（4）针对HMW做方案
穷举：通过头脑风暴，穷举所有可能的解决方案
打开思路：不要自我限制，先列出来，后面有限制办法
（5）不好的、不明确的HMW
不能太空、太宽泛
不能太窄、过于具体
不能完全超出自身能控制的区域
方法3：KANO模型分析法
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意度之间的非线性关系。
KANO模型从两个维度来评估评估需求：
两个维度结合得到四类需求：
必要型需求：此类需求如果没有，产品则无法使用，如手机的通话功能
期望型需求：此类需求与用户期望的契合度极高，此类需求实现程度越高，用户的满意度也越高，如视频软件的优质视频量
兴奋型需求：即爽点型需求，用着爽，但是一般要付出较大的成本
无差别型需求：做不做这类需求对用户影响都不大
根据卡诺模型，我们把用户需求分为三个层级：
第一层：基本需求，用户满意度低，需要程度高。是用户必备的需求，必须全部满足。
如果不满足用户会引起极大的不满，甚至放弃使用；这类需求即便全部满足了用户，用户也会认为这是理所当然的。
比如，微信聊天、钱包转账、添加好友、购买商品、发表评价等。如果一个社交软件无法聊天、电商APP无法下单，或者用户买的东西缺货、质量不好、配送延迟等，理应在服务基本保障内或用户预期内的需求得不到满足，用户的满意度很急剧降低，失去口碑。
第二层：期望型需求，用户满意度会随着满足程度逐步升高，不满足的话可能引起用户不满。
比如，外卖订单，如果承诺是1小时送达，如期送达是服务承诺，属于基本需求范畴；如果30分钟就送达了，这是超出了用户预期的，用户的满足感能得到很大提升。用户永远期望自己的快递或外卖更快地到达，这是用户的心理期望。
第三层：兴奋型需求，大大超出用户预期的或者用户从来没有想到的，突然给满足了，用户的满意度会大大地增加。
一次只满足用户一个兴奋型需求即可，如果能挖掘出多个兴奋型需求，那就分多次让用户爽。
比如，平常微信红包是200元上限，情人节可以发520元，这就让姑娘们很兴奋，盼望着天天过情人节；比如，趣头条新闻还能赚钱等。这都是在满足用户基本需求之外，让用户更兴奋的需求。
基本型需求是用户痛点，衣食住行美医娱等覆盖用户生活的方方面面的基本需求。期望型需求是用户痒点，用户期望得到更好的服务，无论是物质上的、精神体验上的。兴奋型需求是用户爽点，能让用户心潮澎湃的东西，是产品的杀手锏。
卡诺模型使用注意点：
没有绝对界限的需求层级，个体有差异、群体也差异。你的期望需求可能是别人的基本需求，你所满足的兴奋型需求，或许竞品早就提供了。要结合自己产品的使用场景、目标人群仔细区分。
没有绝对的层级。今天是期望型需求，明天就可能是基本需求了。比如用户习惯了微信520红包，哪天情人节不可以发520了，用户就会感到失望。随着时间的推移，兴奋的会变成期望，期望的会变成基本需要。
层级的关系不是非A即B，不用太纠结把某个需求归类到哪一层，需求背后的业务目标和用户体验更重要。
方法4：Y模型
Y模型，顾名思义，形状像一个字母‘Y’。这个模型把产品开发过程分为三个主要分支：用户需求、用户目标和技术实现。
其实就是指从问题到方法（解决方案）的转化，或者说从用户需求到产品功能的转化，主要回答“5W2H”。
如何理解
“1”是用户需求，这部分是关于产品经理为谁设计产品，以及他们需要什么。也是前文提过的需求的第一种深度——观点和行为。
“2”是用户目标，是需求背后的目标和动机，需要考虑到需求的目标和背景，同时也要结合自身公司业务，进行需求的拆解。是需求的第二层深度——目的和背景。
“4”是人性，是价值观，是需求的本质，任何需求分析到最后都是人性的底层需要。
“3”是需求分析后转换的产品功能，是需要各部门配合确认的产品落地方案。
“1”→“2”→“4”是深入，分析的时候需要多追问几个“why”，在某个场景下，用户为什么有这个需求？目的是为了解决什么？这么做就能解决吗？有没有其他方案代替？符不符合公司业务形态？是个别还是大众？...不断提问回答，再提问再回答...
只有充分理解了用户的需求，我们才能确保我们的解决方案或产品能够真正满足他们的期望。
“4”→“2”→“3”是浅出，要回答“How”，怎么解决？"Which" 指的是在众多可行的方案或功能中做出选择，这一决策背后蕴含着对价值的深刻判断，需要评估性价比和优先级。"How many" 涉及的是在一次迭代或发布中应包含多少个功能的问题。产品经理应该做的是，把简单留给用户，把复杂留给自己。
举例
用户需求（“1”）：用户表示想要一个能够记录每日步数的应用。
用户目标（“2”）：深入分析后，发现用户真正的需求不仅仅是记录步数，而是希望通过这种方式来监控自己的健康状况，激励自己保持运动习惯。因此，产品需求变成了开发一个集步数记录、健康数据分析、运动计划推荐、饮食推荐于一体的健身应用。
马斯洛需求（“4”）：深入分析后，发现这个用户目标背后涉及到的是马斯洛需求层次中的健康需求和自我实现需求。用户渴望通过改善饮食来保持健康（健康需求），同时也希望通过达到减肥目标来获得成就感和自信心（自我实现需求）。
产品功能（“3”，初步设计）：基于用户目标和马斯洛需求的分析，我们初步设计了产品的功能，包括记录每日步数、营养摄入计算、个性化饮食计划推荐、食物热量查询、饮食记录与分析等，以支持用户实现健康饮食的目标。
产品功能（“3”，迭代优化）：在产品上线后，可以根据用户反馈和市场变化对产品功能进行了迭代优化。例如，增加了社区互动功能，让用户可以分享饮食心得和成果，增加社交满足感；引入了AI智能推荐系统，根据用户的饮食偏好和身体状况提供更加个性化的饮食建议；优化了用户界面和操作流程，提升用户体验。
在实际的产品开发过程中，“用户目标”和“产品功能”之间往往是相互影响、不断迭代的关系。Y模型分析需要产品经理具备深入的市场洞察力、精准的价值判断能力、以及高效的资源管理能力。只有这样，才能在竞争激烈的市场中立于不败之地，为用户创造更大的价值。
