占在用户角度
需求的拆解，核心都是站在用户角度
假象自己就是用户，处于用户所属的场景，面临用户当前面临的问题（肯定是有问题才会有需求，否则用户为什么平白无故要用你的产品、功能？）
或者再换一种角度，如何说服用户、客户购买或使用你的产品？告诉用户我们是用什么xxx架构、xxx语言实现的多么NB的系统？
常规思路都是我们发现你们有什么问题，然后我们产品有什么功能，可以怎样帮助你解决这些问题
不仅限于需求本身
http://www.woshipm.com/pmd/849019.html 需求理解和定义的过程可能不在需求本身，而是在需求之外，跟人的因素、心理学、社会学等有很大的关联关系。 — 要多方面、多维度的理解、分析需求，才能真正解决问题，软件开发的目的都是为了解决问题，定义清楚问题才能解决问题
通常我们做产品的时候都讲以用户为中心，以需求为导向。
这里的需求都有一个前提，就是关联了用户，所以我们平时更多的都是在讲用户需求，也就是与“人”相关。
大家都知道，人的世界里真真假假、虚虚实实，表达反馈出来的信息不一定是真实的，做为产品经理就需要掌握需求辨别和定义的方法。
描述用户的某个需求看似一件简单易做的事情，感觉上只需要指出用户想要干什么，产品能够提供什么就可以了，实则不然。
比如，用户在商品管理时有如下需求：“用户可以临时调整商品的价格，其规则是：用户申请对某个商品临时调价，并设定临时价格有效的起止日期，临时调价审批通过后，在该临时价格有效期内系统按临时价格销售该商品，有效期结束后，系统恢复临时调价前的销售价格”。
这个需求看上去没有任何问题，描述的比较清晰，事实上仍可能有如下问题不清楚：
- 用户申请对某个商品进行临时调价的目的是什么，调价前后对商品的销售会有什么样的影响，有没有不需要通过调价来实现的方式；
- 用户申请对某个商品进行临时调价，这里的“商品”是尚未报价的还是已经报价的，是已上架的还是已下架的；
- 设定临时价格启用的起止日期，起止日期可能会产生歧意，是否包含“止”的那一天，系统从“起”天0:00:000还是9:00:000 AM开始，到“止”天23:59:59还是17：59：59结束，不同行业、不用用户都可能有不同的答案；
- 如果临时调价审批不通过，系统是删除这个申请还是保留该申请允许用户继续编辑，要看用户的实际使用场景，有时可能删除比保留来得更合理些；
可能还有其他不明确的问题，每个人分析问题的角度和解决问题的方式都不尽相同，产品经理要尽可能降低这种需求理解上的成本，比如不完整和二义性是需求定义和表达需要避免的。
**
避免伪需求
伪需求就是用户看上去想要这个，实际他想要那个，伪需求”是基于真实需求的业余表达。
学会思考需求背后的场景，频次很低也是伪需求
我是北方人，有一年冬天打算去买一件红遍社交圈的加拿大鹅。但是看了一下网上的价格，确实有点囊中羞涩。于是，便想起了代购会不会便宜一点。于是联系了在新加坡的姐姐。老姐给我来了一句，在新加坡买羽绒服不存在的。
转念一想是啊，谁会把羽绒服店开在新加坡呢？新加坡全年平均气温26摄氏度。根本不需要羽绒服。哈哈，现在想想幸好我不是加拿大鹅的亚太地区经理，否则我一定要被辞退啊。
上面这个例子其实很好地说明了一个需求在不同的场景下，很可能会变成一个伪需求。
所以在我们的实际工作中，接到一个需求时，一定要去研究需求背后的场景，在这个场景中，这个需求是高频需求还是低频需求？如果是低频需求那就没有解决的价值，与互联网的网络效应是相悖的。更应该去聚焦高频需求，要解决群体的问题。而非个体的问题。
直接给到的解决方案要转化为需求，不能还原成需求的解决方案都是“伪”需求
在平时工作中，其实你会经常听到这种“需求”，产品经理你帮我加个按钮吧。产品经理你帮我加一个搜索框吧。这些所谓的“需求”，看似好像没有什么问题。但是你细细分析一下，就会发现，其实这些不是“需求”，这是解决方案。
这样会造成什么样的结果呢？就是你解决了一个问题同时又得到了一个新的问题。因为一个需求可能会有很多解决方案。同样，一个解决方案也可能会对应多个需求。
假设你现在负责一款在线理财产品，你的运营同事说需要在用户注册的过程中获取用户的一些私人信息，大概需要的信息是姓名、身份证号、年收入等。
你看到这个解决方案没有还原为需求，直接对产品进行了修改。改版的产品上线发现，注册率断崖式地下跌。
然后通过用户调研发现，之所以会出现这种情况是因为在用户刚刚接触产品的时候，还没有产生信任，这个时候问用户要这么多的私人信息。用户当然是一种抵触的情绪。所以就导致注册未完成用户就退出产品了。这就是注册率下降的原因。
那么正确的方式是应该怎么做呢？
首先，运营同事告诉你需要在注册的过程中，获取用户的一些私人信息，大概需要的信息是姓名、身份证号、年收入等。
这个时候，你询问了运营同事的目的——为什么需要用户这些信息呢？
原来是需要通过这些私人信息，来进行对用户分层，进行精细化运营。推送给不同的年龄，不同年收入的用户不同的理财方案。
你明白了目的之后，给出了解决方案：
首先，用户在初次进入产品时，还未产生对产品的信任。这个时候去索要用户信息呢，大部分会被拒绝并且会影响注册率。倒不如在用户体验产品，并且达到了aha时刻的时候再去向用户获取私人信息，这个时候成功率会高很多。同时，不会影响注册率。最后，这个问题得到了解决同时也没有影响注册率。
在我们平时的工作中，会遇到各种各样的解决方案。
这个时候，一定要询问对方的目的。从目的出发，去还原成需求。
再根据需求的四要素（用户、场景、诉求、任务）层层分析得到最优解决方案。这才是产品经理应该做的。
而不是让别人对你的产品“指手画脚”。一定要谨记解决方案是要通过需求转化的，直接给到的解决方案一定要转化为原来的需求。
不动脑子地照“抄”并不是竞品分析，但会是“伪”需求
如果说提到需求很容易联想到产品经理，那么在产品经理的工作中，一定会有一个文件夹是竞品分析。
在这个充满竞争的时代，可能一两个星期就要做一次竞品分析。很多小白产品经理在做完竞品分析之后，就会把竞品比较好的功能全部照搬过来。有些时候其实是没有意义的。产品经理在低头赶路时，一定要记得抬头看天。
网易云音乐想必大家都不陌生吧？—— 一个以歌单为核心功能的在线音乐播放软件。
在网易云音乐刚起步时，大家都在吐槽这个软件好难用，听到自己喜欢的音乐必须要保存到歌单里面才能听。并且没有音乐排行榜。推荐方式都是通过歌单。反观这个时候，市面上的音乐产品，酷狗、QQ音乐、虾米没有一个是没有音乐排行榜的，同时没有一个要通过歌单来进行推荐的。
你是否会有疑问？为什么市面上的音乐播放软件都有排行榜。唯独网易云音乐没有呢？难道仅仅就是为了标新立异？
在开始的时候，我也很不理解。直到有一次看到网易云音乐的产品经理的访问，这才解开了我的疑惑。
原来，网易云音乐在产品初期就立志成为一个聚焦长尾音乐的分享平台，希望让更多的人发现那些好听但是苦于没有资源推广的音乐。
这个时候，你就会发现竞品里的排行榜，在网易云音乐里面就显得格格不入了。那些能够上排行榜的音乐除了音乐本身质量过关以外，更多的是因为资源更好。如果网易云音乐也参照竞品加入音乐排行榜，那么就与自身的产品定位背道而驰。
所以我们平时在做竞品分析时一定要不盲目地去抄功能需求。而是要学会深层次的思考，竞品为什么要做这些功能需求，这些功能需求背后都会隐藏着什么？它们的战略是什么，范围是什么，结构是什么，框架是什么。对应的分别是产品的战略、产品的定位、产品的产品架构、产品的信息架构等等。
在做学习竞品的时候一定要学会立体地去分析。而不是仅仅看到一个点，要从点及线，再从线及面。不动脑子地“抄”并不等于竞品分析，作为一个产品经理一定要学会有所为，有所不为。
不要只听用户说什么，更重要的是找到背后的元问题
在日常的工作中，产品经理应该是距离用户最近的。会经常听到很多用户的反馈，这让我想到张小龙的一句话，每天微信都有一亿用户教我怎么做产品。
其实这也侧面反映出产品经理每天都会听到大量的用户反馈。然而面对这么多的用户反馈我们应该怎么做呢？是全盘接受，还是全盘否定。又或者是各有参半呢？在我看来，这些都不重要，重要的是发现他们背后的元问题。
福特与马的故事想必大家都耳熟能详了吧，在世界上还没有车的时候，大家都在希望可以找到跑得更快的马。但是福特却直接给到了用户一辆车，它不是马，但是比更快的马还要快。
是不是很有意思呢。
其实这就告诉产品经理一定不要只听用户说了什么，更重要的是找到背后的元问题。
福特就非常聪明，用户之所以需要找到更快的马，无非是想提高效率，更快地抵达目的地。所以在这背后的元问题就是从用户要更快的马变为了如何让用户更快、更有效率地抵达目的地。显而易见，福特给出了更高效的解决方案。
在大学时期呢，学校周围都会有一些小旅馆。旅馆的生意非常好，这个时候呢，老板想把旅馆进行扩建。但是他每次看到大学生来都会说：“最近宿舍好吵，没法在学校里面学习了。”老板于是搜集了很多用户的反馈，发现大家都这么说。老板就灵机一动。原来，大家来我这里是因为宿舍太吵，没法学习啊。于是把原有的旅馆改成了学习室。结果可想而知，那些说为了学习的大学生，就再也没有来过。
我相信大家看完上面的两则例子，都应该明白了解决用户背后的元问题的重要性。产品经理在了解用户的反馈的同时，要把握用户背后真正想解决的问题是什么？面对这个问题有没有更好的解决方案。
不要为了短期目标，而损害长期目标
这一点在平时是比较难注意到的，所以需要我们时刻提醒自己。
让我们看一下网易云音乐在面对短期目标和长期的目标是如何取舍的。
网易云音乐产品达到PMF时候，为了提升产品的使用频次，所以团队中有人提出添加场景音乐，可以直接在特定的场景中直接播放场景列表中的音乐。而不是要在自己的收藏的歌单中找到相应的歌曲再进行播放。
通过这种形式可以大大提高用户的使用频次和拓宽用户的使用场景，但是网易云音乐却没有这么做。主要是因为网易云音乐的长期目标是成为一个分享歌单的音乐平台，但是如果为了在短期内提升用户的使用频次和拓宽用户的使用场景。那就势必削弱用户使用歌单的频次，顾此失彼。
经过深思熟虑，最后，网易云音乐仅仅只保留了在车载场景和跑步场景的专属入口，其他的形式依然通过歌单来进行音乐的播放。这就是一个很好地去平衡了短期目标和长期目标给出的解决方案。
在我们平时的工作中，常常面临如何去权衡短期目标和长期目标。这个时候就需要产品经理去权衡利弊以及分析影响的范围。短期目标与长期目标的比例最好保持在1：1，首先考虑，如果为了达到短期目标那么会对长期目标造成什么损害。之后要考虑可能会影响到的范围是什么？是否需要进行功能模块之间的联动。动一发而动全身。
区分需求与诉求
:::info
提取真实需求
:::
Eg：
哪个是需求，哪个是诉求？
A.成人甲：我得吃点东西，饿了 ——需求，客观存在，就是饿，是否可以不饿？ — 不可以，饿
B.孩子乙：妈妈我想吃冰淇淋 ——诉求，要做什么事情？是否可以吃其他的？ — 可以，可替代
C.老师丙：每张卷子都要家长签字 ——诉求，为什么要签字，目的是什么，是否可以不签字？ — 可以，可替代
D.路人丁：这天气太热了，得凉快凉快 ——需求，客观存在，就是热，是否可以不热？ — 不可以，热
所以，需求的特点是：
客观存在的，此时此刻不会发生任何改变的
所以，诉求的特点是：
讲出来的，可以有多种解决方案来代替的
坑爹诉求举例：
对于课程（起点学院）有什么期待，想获得什么
1.对产品经理有系统的认识，学习实战经验
2.学习最完善的产品方法论和团队管理
3.多分析案例，多介绍小程序，人工智能方面的应用
4.希望能够系统学习产品知识，很系统的那种
5.BAT的实战经验
6.……
PS：实战经验学不到，更多都是诉求，记住事实和规律（拍脑袋想出的大多数规律，原来是这样做的，大家都是这样做的，一般是这样做的~~缺乏了创新意识）
区分需求和诉求时，最大的困难：自己
兴奋而草率，宏伟而理想。
着急而粗心，重视而放大。
PS：经常想到一个功能，而不是需求本身，经常会主观 — 区分需求与诉求，对诉求的解决往往不能解决真正的问题，找准需求才是。
兴奋而草率，会觉得某个事很牛掰、有的干、市场空白，就去干了，但是方向不一定对。静下来想想，第一步是否正确，做的到底是需求还是诉求。
宏伟而理想，这个事特别大一定能干成，没有人干过，自身基础条件都有，但是成的关键点是你做的每一步都是满足用户需求的。
着急而粗心，觉得迭代慢了，加速迭代，但是没有达到根本，没有get点。
重视而放大，捡了芝麻丢西瓜，坏处相应也被放大
区分需求与解决方案
:::info 避免陷入开发思维，解决方案是无限的，同一需求可能有多种解决方案，直接绕过了需求，可能也错过了最优的解决方案 :::
解决方案（Solution），就是针对某些已经体现出的，或者可以预期的问题、不足、缺陷、需求等等，所提出的一个解决整体问题的方案（建议书、计划表），同时能够确保加以快速有效的执行。通常指解决问题的方法
区别
需求：
- 要做什么
- 提供什么功能、提供什么价值、解决什么问题
- 做到什么程度
- 支持100个用户还是100万用户？（性能约束）
- 支持100策略还是100万策略？（规格约束）
- 需求的四要素（用户、场景、诉求、任务）
- 客观存在，不可改变
- 比如期望支持100万用户，这100万用户就是存在的
解决方案：**
- 怎么做，解决问题的方法
- 先做啥，再做啥
- 可替代
- 是否有其他的做法也能达到这样的效果
- 比如Apache能支持100万用户，Nginx也能支持100万用户
边界
比如 支持**IPSec 引流协议 是一个需求还是解决方案？
既是需求，又是解决方案？只要符合相应的要素，需求与解决方案的定义只是特性描述的分类
同一个描述在不同场景下的定义也不一样，有的场景下是需求，有的场景下是解决方案
所以讨论一个点是需求还是解决方案时，不能脱离对场景的阐述**
需求：
- 要做什么 **— **支持了IPSec功能，用户便可使用IPSec协议方式进行引流，具有更高的穿透性以及安全性
- 提供什么功能、提供什么价值、解决什么问题
- 做到什么程度 **— **支持功能，支持这个协议
- 支持100个用户还是100万用户？（性能约束）
- 支持100策略还是100万策略？（规格约束）
- 需求的四要素（用户、场景、诉求、任务） **— **支持了IPSec功能，用户便可使用IPSec协议方式进行引流，具有更高的穿透性以及安全性
- 客观存在，不可改变 **— **用户就是要用IPSec，因为IPSec自身是一种技术，也是一种功能，在网关产品上，用户可以勾选使用IPSec，一些安全规范上也明确要求就是要使用IPSec
- 比如期望支持100万用户，这100万用户就是存在的
解决方案：**
- 怎么做，解决问题的方法 **— 用户想要**更高的穿透性以及安全性，可以使用IPSec协议
- 先做啥，再做啥
- 可替代 **— 用户**可以使用IPSec协议，也可以使用自己新定义的私有协议
- 是否有其他的做法也能达到这样的效果
- 比如Apache能支持100万用户，Nginx也能支持100万用户
若有收获，就点个赞吧
0 人点赞
