在互联网公司里，产品经理现在是需求的代言人，基本言必称需求。今天老板提了个需求、明天客户提了个需求、后天拍脑袋了一个需求。

问题是，什么是需求？

“用户希望打电话的时候，按一下xx按钮就能实现录音”

“大促活动时，我们能筛选出来不同的用户群体，同样的商品，让不同的用户群里能看到不同的价格”

“你给我做个自助取数功能吧，把表里的数据能够导出来”

“在埋点管理模块做一个事件序列检测，在测试数据上报的时候，就可以通过验证客户端是否上报了设定的序列来测试是否有bug了”

“用户提现的时候，为了保证安全性，需要增加一个手机验证码的验证”

以上都是需求，有用户的、客户端、运营的、产品经理自己的。但是都有一个共同点，都是明确的要求具体的功能。所以，需求一般是明确的对功能的需要。

按照常见工作流程，就是

上线后发给需求方，所有人kpi完成。

若这是产品经理自己想出来的需求，有些开发还会PK一下，“你这需求不合理，用户不是这个需求，这个需求没价值”。很多时候，产品经理直接搬出来用户的原话、或者后台留言来明确，这就是客户的需求，开发也就不说什么直接去做了。

看起来非常正常的流程，基本没啥毛病。但是，有问题。

“用户希望打电话的时候，按一下xx按钮就能实现录音”，什么人在什么场景下需要打电话录音？在该场景下打电话录音是为了解决什么问题？

“大促活动时，我们能筛选出来不同的用户群体，同样的商品，让不同的用户群里能看到不同的价格”，为什么要不同用户看到不同价格？是为了提高促销商品的总销售额？总销量？总利润？。

“你给我做个自助取数功能吧，把表里的数据能够导出来”，为什么要导出数据？是因为本来数据可视化不好看，需要放到excel里重做？是为了把数据共享给其他人？

“在埋点管理模块做一个事件序列检测，在测试数据上报的时候，就可以通过验证客户端是否上报了设定的序列来测试是否有bug了”，这个需求想解决的问题是什么？是埋点经常埋错吗？还是上线后经常有上报数据的错误，需要这里发现？如果是埋点经常会埋错误，原因是什么？开发不够仔细？是一个开发经常埋错还是所遇开发都经常埋错？是哪种错误？字段名字写错还是少开发埋点？

“用户提现的时候，为了保证安全性，需要增加一个手机验证码的验证”，增加手机验证要解决的问题是什么？是确保提现操作是拥有该资产的本人的一个验证。要是手机丢了，验证码填写对了还能保证是本人吗？

需求不应该是用户或者客户提的，提需求的只能是产品经理。正常的工作流程应该是：

产品经理在接到需求的时候，应该弄清楚5W1H：什么人（who），在什么场景下（where and when），遇到了什么问题（what），为什么会有这个问题（why），怎么才能解决这个问题（how）。其中问题是核心。

客户或者用户，提出需求，是因为思维上，人们都会普遍按照自己的理解想解决办法。但是作为产品经理，需要透彻了解到描述的需求后面提需求的人在具体场景上想要解决的核心的问题，然后基于该问题的理解，提出产品经理的需求。

这里的需求分析，主要是指后端或者toB的需求。

分析需求，就是要把握需求的三要素：人、场景、问题。

提需求的是人，但提需求的人往往代表的是一个角色。

场景，是场和景的组合是在一个空间内，由人和物组成的画面。

问题，是让人觉得不爽的点，而且是基于持续的问why和how得到的本质的不爽的点。

分析需求，就是分析特定的觉色在特定的时间、空间和人物构成的环境中本质的不爽的点。

覆盖人数越多，场景越宏大，问题越普遍则需求越有价值。

如微信小程序的场景定位为无需下载，即开即用，用完即走。所有需要临时使用下的网络服务，都是小程序的场景。如邮寄个快递、定个餐、冲个话费、交个电费等等。由于生活中广泛存在这种低频次的刚需应用，相对于下载一个app再注册登录，使用小程序能为用户带来了极大的便利，再基于微信庞大的用户群，所以小程序爆发出强大的生命力。

屁股决定脑袋，分析需求的时候，首先需要注意的是人，每个人提需求多是为了他自己或者他代表角色的利益。这无可厚非，但是很多个人或者角色的利益诉求与总体利益的最大化是可能存在冲突的，比如，在内容公司里，内容运营团队总是不太喜欢推荐部门的。

在相对小的公司里面，利益冲突相对好解决，因为老板的管理半径可能覆盖到最下面的团队。一个对公司整体最优的决策是可以在老板的影响范围之内制定的。当然老板自己拎不清的情况另说了，如果老板自己都拎不清，最好的解决办法是赶紧换一家公司。

在大厂里，由于层级多，部门多。很多事情的出发点并不是解决生产力问题，而只是为了解决生产关系的问题。比如某个需求提出来，即使分析出来该需求需要解决的问题在你们部门做并不是最合适的，但是主管就想要这块业务，这时候分析需求的目标就不是人+场景+问题了，而是这事在你们部门做是多么合适，多么成体系以及你们做起来多么有经验等等。以大厂拥有的资源来说，一个基层产品经理的决策失误对于资源的浪费并不会对公司整体产生什么影响，浪费掉的资源相对于公司整体拥有的资源来说是九牛一毛。但是你对于部门老大的忠心是能实实在在影响到你的晋升和年终奖。

场景是用户感受到不爽的时候的时间、空间、关联的人和物构成的整体的画面。分析需求的时候，构建场景是为了方便将自己代入到该画面中去体会和共情。

网上传言，乔布斯能1秒钟进入傻瓜状态，马化腾需要10秒钟。这种进入傻瓜的的状态，就是忘掉自己所有的既有经验，将自己带入到普通用户的场景中去。现在的所谓互联网“智能”电视，普遍是不怎么智能的，因为普通的老百姓，基本都是自己搞不定的。当前互联网电视的设计逻辑都是给有丰富网络使用经验的人做的。或者设计电视功能的人都是基于自己的网络水平设计的。比如，看电视要联网，要配置WiFi帐号和密码；使用电视过程中，要看电视台，要切换信号源到HDMI或者HDMI2；主页巨多tab，让人不知道怎么切换怎么选。设计电视的人丝毫没考虑到，全国上过大学的人只占总人口的不到5%，还有剩下的90%以上的人，在买了一个新的高大上的互联网电视之后，面对不小心切换的信号源，怎么按都找不到原来的画面的时候的无助。

在toB业务中，考虑场景的时候往往不止需要考虑遇到问题的当前时刻，还需要考虑上下文，也就是业务本身的业务流程。有些时候问题是单个业务点的，有时候问题是整个流程导致的，只有了解整体流程才能提出整体的解决方案。

对于一般的数据平台什么是需求分析，会分为数据采集、ETL、数据仓库、数据应用几个模块。最典型的应用是BI（Bussiness Intelligence）报表。要做出来BI报表，需要从端上采集数据，服务端ETL后存储到数据仓库；数据仓库中又把数据分为DWD，DWS，DWB，ADS等数据层级，需要数据开发把数据从DWD层一层层开发出上层；最后再使用可视化工具做成BI报表。采集、ETL、数据仓库和可视化分别有独立的人来开发和配置。一般这种类型的数据平台，BI报表的使用方经常会吐槽数据不准，数据有问题。一旦使用方报问题，就需要从报表开始往回一直查到数据采集来定位问题。经过几次报问题之后，可能发现了端上开发上报的埋点的字段出错比较多。这时候，由于每次报错都会让数据仓库的开发和ETL的开发查，他们就会开始吐槽，开始提保证埋点质量的需求。产品经理此时针对埋点可以提一对测试工具的需求，然后给端上的开发和测试找一堆活来“保证”埋点质量。貌似也能解决问题。但是从整体来看，BI不准的核心问题是，数据处理链路过长且中间大量的人工对接。超长链路的的大量人工的非标准接口的对接必然出错。要解决问题，应该是从优化流程入手，减少流程中的人工处理，固化为程序自动处理。

问题，是让人觉得不爽的点。

云服务市场潜力很大，在于没有云服务的时候，哪怕你搭个小网站也需要自己去IDC买机器，装系统。更不用说在使用过程中还有软件的bug，甚至硬件的故障都是不可避免的。回来使用过程中还不知道哪天就出了问题了，你还得往机房跑。所以，想做互联网开发服务的人，在做核心开发的时候，还需要顾及到机器的问题，甚至出问题后花费的精力是让人崩溃的，相当让人不爽。所以，这时候普遍的解决方式是招聘专业的运维，来运转维护机器的正常运行。对于资深的运维，应该都是跑过机房的，在轰鸣的机器中间更换硬件，安装系统，这事让运维相当不爽。如果这事让运维提需求，那么对于运维来说，能远程监控，远程安装系统最好了。dell、惠普等服务器厂商还真的都有这话服务，在服务器上，独立于你安装的系统之外，有个嵌入式的系统，给该系统分配ip地址后，你可以远程管理你的服务器，就像在本地连接了键盘显示器一样。但是这个产品解决的是运维的问题，并没有解决做互联网开发还是需要运维的问题。说明这种解决方式，不够本质。

计算机最基础的架构，从底层到上层依次是硬件，操作系统和应用程序。硬件就是CPU、内存、硬盘、网卡等。操作系统，对于服务器，一般安装Linux系统。应用就是程序员开发的各种服务。

以上三个层面，都会出现问题。硬件的故障、操作系统崩溃、应用报错等等。服务器厂商提供的独立嵌入式系统方案，解决的是操作系统层面出故障时候，可以不用去机房的问题。但是，对于互联网开发者，并没有解决硬件故障问题以及操作系统故障了还是需要重装的问题。而云服务，直接把应用以下的问题都解决了。所以相对来说更加本质。

最近一个BI朋友跟我吐槽，他们操作系统开发新版本，但是端上的所有预置应用的所有的埋点都需要他一个一个去输出，一个个跟开发对。开发埋完了之后，测试还要一个一个验收。让他感觉自己每天上班就是做重复无意义的劳动，同时开发和测试也很烦躁，因为涉及到多人对接，且埋点量特别大，还总是出问题。所以这个需求就是解决BI角色在每天的工作中的主要内容有数据分析变成了流水线工人一样的重复低水平劳动的问题。同时，还有开发和测试在数据埋点工作中的大量相似的重复低水平劳动和经常出错的不爽。

看似是这个问题了，但是为了探究本质，我们需要一直问why，一直问到无法再问或者再问下去已经没有意义。

BI不爽，他为什么不爽？因为埋点重复工作量大且经常出错。为什么埋点重复工作量大？因为当前的数据采集工具只能够支持人工埋点数据的上报。为什么埋点工具不能支持自动化的数据采集？因为设计埋点工具的人认为不能自动采集？对于安卓的APP，用户的操作行为不能自动采集吗？能，为什么设计埋点工具的人会认为不能的？因为设计埋点工具的人对于安卓的原理不了解。为什么让对安卓原理毫不了解的人去设计埋点采集工具？——这是老板管理的问题，没有合适的人做合适的事。那为什么没有设计出来合理的采集工具也能执行开发这个采集工具？——决策流程有问题。为什么决策流程有问题？因为部门没有人制定合理的能及时发现问题的流程。为什么使用中发现问题了，很长时间仍然没有改进？因为老板没有发现有问题，无法调动资源改进。——综上，问题的核心原因是老板的管理水平问题。可以预见该部门做的其他产品大概率也是乱七八糟的，因为兵熊熊一个，将熊熊一窝。

本质是表象的对立面。

地球围绕太阳转是表象，万有引力定律是本质。但是水星绕太阳旋转就不符合万有引力定律，所以万有引力定律不够本质，要广义相对论才够本质。

导线在磁场中切割会产生电流是表象，法拉第电磁感应定律是本质

光速是30万公里每秒是表象，光的本质是电磁波。

变化的电场会产生磁场是表象，以上例子中，所有电和磁相关的，本质都是麦克斯韦方程组。

本质是各种表象的真实性质，是能够解释表象并能够预测表象的道理。

所以我们说，透过表象看透本质。

本质的特征无论是科学领域还是社会学领域都是适用的。问题是，科学的本质好判断，不是民科在科学是否是本质上还是容易达成共识的。而产品经理关于需求后面的问题的本质的判断往往是社会学相关的。

在《华尔街之狼》电影中有个经典片段，小李子给学生上课，把手里拿的一只钢笔给了学员说，“把笔卖给我”。学员支支吾吾的说，这支钢笔很好，能用来记录，就不会忘记了；这个笔很好写，我喜欢。。。。。

这个片段的映射是，影片前半部分，他让自己一个手下把笔卖给自己，手下说：“能给我签个名吗？”

所以说，销售的本质不是产品多好，而是创造需求。有需求，人们自然会产生购买行为。

看起来很本质了。

双十一的时候，很多人会买很多自己不需要的东西，没有需求，也买了呢？

有需求会产生购买，但是购买不一定都是由于有需求。需求是购买的充分条件，不是必要条件。对于销售来讲，创造需求是牛顿运动定律，不是相对论。

我认为，销售的本质，是满足欲望。销售的技巧是激发欲望。卖笔的时候，对方想给你签名是炫耀的欲望，买吃的是人生存的欲望，双十一不需要东西也买是满足贪婪的欲望。

外卖那么火是满足懒惰的欲望，微信用户爆发增长发生在微信上线“摇一摇”，至于陌陌最初快速的发展也是满足人的本性。

欲望就是人性，人性是“五色令人目盲，五音令人耳聋，五味令人口爽，驰骋畋猎令人心发狂，难得之货令人行妨。”人性也是是贪嗔痴，是傲慢、暴食、色欲、嫉妒、贪婪、懒惰、暴怒。人性也是马斯洛需求理论中不同层级的欲望。

欲望是天生存在的，也可以是被激发的，欲望不被满足的时候，人就会不爽，将不爽变成爽，人会获得满足感。

人性的欲望与现实的矛盾是问题的本质。

当然，实际的工作中，很多时候，并不需要层层分析道人性的欲望这个层级。就好比分析销售，能到创造需求就够了。使用牛顿运动定律能解决的问题没必要使用相对论。但是知道更本质的分析方法什么是需求分析，对于和其他人讨论、pk或者把握核心和本质的时候，能看到更深刻的层次。