网上科普有关“数据需求分析 挖掘最根本的欲望”话题很是火热，小编也是针对数据需求分析 挖掘最根本的欲望寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。
数据需求分析：挖掘最根本的欲望
1、一切源于欲望
1.1欲望！何为欲望？
心理学上对欲望的解释是由人的本性产生的想达到某种目的的要求。在这个定义里有两个关键词：本性、目的。它指出了欲望的源头，是由人的本性产生的，是一种本能，人人皆有。同时也指出了欲望的产生原因，是为了达到某种目的。
举个例子，吃饭，这是一项最基本的生理欲望，每个人为了生存必须要吃饭。要吃饭，就得先把饭做出来。我们有微波炉，电饭锅等等很多可选择的工具来帮我们做饭，甚至，做特殊的食物有专用的工具提供给我们，比如面包机。再者，如果你不想做饭，连出门都懒得出，你可以用一款叫“饿了么”的软件将食物快递上门。
前面提到的微波炉，电饭锅，面包机以及“饿了么”软件，都是我们可以用来满足吃饭这项生理欲望的工具。换个角度，这些工具不就是工具生产厂家的产品吗？换句话说，产品就是为了满足人们欲望而产生的工具。既然产品是为了解决人们的需求问题，也就是说需求就是人们的欲望。
1.2 欲望，如何满足
每款产品都有自己要解决的核心的用户需求，也就是说产品都有一个核心的欲望需要去满足。比如，“饿了么”软件就是满足人们叫外卖的欲望。但是，叫外卖的方式有很多种，为什么用户一定要用“饿了么”软件呢？这个时候，就需要对欲望进行深入的分析，已提供更好的服务来满足人们的欲望，这个活动常常被产品人称作需求分析。
举个苏杰大大在《人人都是产品经理》中的一个例子：绝迹小朋友想去吃火锅，这是一个欲望。但是绝迹小朋友真的是嘴馋了想去吃火锅吗？可能绝迹只是饿了，但是这四川娃子饿了就只想到吃火锅。如果真的只是饿了，给他俩包子也可以满足绝迹的欲望，还能节省成本，何乐而不为呢。这就是一个典型的需求分析过程，通过需求分析找到了最简单的满足人们欲望的方式。
再来谈谈“饿了么”软件，在这个软件出现之前人们也是能叫外卖的，那么这款软件有什么更好的满足人们叫外卖欲望的方面呢。我们先来看看以前叫外卖的痛点。叫外卖有两种方式，如果店铺有官网，可以去官网订餐，但是，这些只限于一些大型连锁餐厅，比如麦当劳。另一种方式就是电话预定，但是前提是你要有店铺电话，一般人肯定不会有附近所有餐厅的电话。“饿了么”软件就解决了这两个痛点，它能搜罗用户周围提供送外卖服务的所有餐厅，并为所有餐厅提供网上订餐服务，同时也免去了获得餐厅电话的需求。通过分析，“饿了么”软件提供了更好的满足需求的服务。
2.合适的欲望碰到合适的人
2.1 用户角色建模
每一款产品都有自己的受众，没有哪款产品是每个人都需要的。为此，我们需要对自己产品的受众进行分析，看看这些用户使用产品的习惯是怎么样的。这样可以更好的提取用户的需求。
首先，要找出产品的受众，这个流程一般被称为用户角色建模。用户角色建模首先要通过头脑风暴的方式列出可能的用户角色集合。还以“饿了么”软件为例，一般都是什么样的人会叫外卖呢？劳累一天的上班族，学校的学生，偶尔想改善伙食但不想出门的人，加班的人，不会做饭的人。
在收集了用户角色集合以后，我们需要对这些用户角色进行整理，看看角色之间有没有包含或者重合的地方，如果有，则需要考虑是否用角色需要被丢弃。比如上面的用户集合中，不会做饭的人并没有典型的特征，而且，在上班族、学生、加班的人中都可能会有不会做饭的人。则，不会做饭的人完全可以被其他角色所代替，这个用户角色就可以被丢弃了。
在整理完毕用户角色后，可以将每个用户角色写在一个卡片上，并在每个卡片上写下这个用户角色的一些特征，这样可以方便的对用户角色进行分析。比如，在上班族卡片上可以写上对菜品质量要求较高，可以熟练使用电脑，可能会经常使用该软件等等。
有些时候为了对用户角色更加深入的了解，一般会对重要的用户角色建立角色实例。角色实例是一个贴近生活的用户场景，通过角色实例可以建立起一个真实的人物，让我们对角色有更真切的了解。如果上班族是我们主要的目标用户，我们为上班族建立一个角色实例如下：
有业界的大大建议在设计新系统时对一些极端人物建立角色卡。这些极端人物并不是产品的典型用户，但是他们却是真的会使用我们的产品。比如一些花痴小妹妹，叫外卖或许对她们来说并不是必须的，但是她们可能仅仅是为了看某个送外卖的帅哥，而经常定那家餐厅的外卖。我们不需要浪费太多时间在这些极端人物身上，甚至这些人物的需求根本不会被实现，但是花点时间在这些用户身上，或许会产生一些意想不到的灵感。
2.2 需求源于角色
前面在用户角色建模上浪费了很大精力，其实都是在为这里的需求收集做准备。不同的角色肯定会有不同的需求，这个时候，我们需要将自己代入角色，仔细想想如果自己是这个角色，会有什么样的需求。将所有考虑到的需求都记录下来，为以后的需求整理做准备。
比如，作为一名上班族，很晚才回到家，这个时候叫外卖肯定希望外卖会很快的到达。而且上班族一般都习惯刷卡，如果提供刷卡或者网上支付功能会很方便。而“饿了么”软件就为用户提供的外卖到达时间的预估，用户可以方便的选择可以快速到达的外卖。
再考虑学生，学生这是个没有收入的群体，所以物美价廉的外卖是他们的首选。学生一般对快递的送达时间会有相对较大的容忍度。学生中对刷卡的需求不是很迫切，他们一般更喜欢现在付款，所以如果有货到付款的服务会很合适。同时，如果可以用学生卡打折，我想会很受学生们的欢迎。
3.欲望也有轻重缓急
在需求收集和整理完成后和项目开始开发之前，我们需要召开需求评审会来确定每个需求的优先级和开发计划。如果你的团队正在使用 Scrum 敏捷开发，那么你们一定在用用户故事来整理用户需求。用户故事通常使用客户和团队都可以看懂的表达方式来写，每一个用户故事都是产品的一个需求。当然，用户故事还包括需求的商业价值和相关人员。使用用户故事可以方便的与客户沟通，而且不用查看繁琐的需求文档。
用户故事一般使用如下格式：为了[商业价值]，作为[角色]，我想要[做某事]。还是使用“饿了么”软件为例，比如上班族想找到送外卖快的餐厅的需求可以表述为：为了让外卖更快的送达，作为上班族，我想要查看每家餐厅的外卖送达预估时间。
在用户故事确定以后，我们需要召集开发人员，客户还以一些产品的相关人员来参加需求评审会。在会议上，我们需要对每个需求的商业风险，技术风险，开发耗时和优先级作出评估。
首先需要确定的是商业风险，也就是确定哪些是核心需求，哪些是亮点需求。核心需求需要尽早完成，缺失了产品就不完整。而亮点需求有则会给产品加分，没有也不会影响用户的使用。一般来讲，核心需求的商业风险会比较低，因为这些需求都是产品必须的，被砍掉的可能性很低。而亮点需求的商业风险就会高，可能会因为开发时间不足而被砍掉或者被放入下次版本迭代的周期中。
下来需要确定技术风险和开发耗时，技术风险代表的是这个需求开发的难易程度。如果这个需求所需要的技术开发团队从来没接触过，需要对这个技术从头开始学习。那么这个需求的技术风险就会很高，因为这个新技术不知道开发团队是否能掌握，多久才能掌握。技术风险的评估对开发耗时的评估有很大影响。开发耗时在 Scrum 开发团队中一般用时间点来计算，一个时间点代表一个理想工作日。在我的团队中，一般使用斐波那契数列来划分时间点的等级。因为我们发现工程师经常在为一个需求的时间点而争论不休。如果为一个需求是 2 个时间点还是 3 个时间点而争论，这是有意义的，因为 3 个时间点比 2 个多了一半的工作量。但是如果在为一个需求是 99 个时间点还是 100 个时间点而争论就是没有意义的，因为这一个时间点的差别对我们的影响很小。为了避免这种无意义的争论，我们使用斐波那契数列来划分时间点，这个时候工程师只需要考虑这个需求的耗时更靠近 89 还是 144 ，而不用为了细小的差别而争论不休。在评估技术风险和开发耗时时，一般都有技术人员和项目经理来确定，其他人员不应该左右技术人员和项目经理的思维。
最后则是评估需求的优先级，综合分析以上三个要素，来最后给需求评估优先级。一般情况下核心需求的优先级往往是最高的，不过有时候由于技术风险过大，或者开发耗时过长，有些核心需求的优先级会被降低。在优先级评估完毕后，开发团队会确定第一轮的迭代要完成的需求。如果是使用 Scrum 敏捷开发有一段时间的话，开发团队是知道自己在一个迭代周期能够完成多少时间点的任务的，也就是团队的速率。一些高优先级的需求由于时间点太大而不能放入本次迭代，而使用其他优先级相对较低但时间点小的需求代替的情况也会时常发生。
4.让欲望在掌握之中
在完成需求评估后，开发团队就会进入开发阶段。在 Scrum 团队中，需要对开发中的需求进行管理。常用的方法是在一块木板或是一面墙上列出正在开发的，开发完成的，正在测试的和完成了的需求。这块木板或强被称为看板。每个人都可以在看板上清晰的看到团队现在的开发状况。我的团队没有使用实体的看板，而是使用 JIRA 这个软件提供的电子看板。
在开发过程中，需求的变更是必然会发生的。正常情况下，如果一轮迭代已经开始了，Scrum 团队是不会中途停止的。新的需求必须在下一轮迭代中才能加入，这样可以保证开发的正常秩序。为此，我们在看板最前方新加了一项：待开发。我们会将变更的而且有限级高的需求放在这一列，以保证在下一轮迭代中实现这些需求。
大部分公司都会要求写需求文档，这样对所有需求归类，并且可以方便以后的查阅。但是这些需求文档有时候书写的并不是很规范，或是很全面。导致查阅的时候很难找到我们需要的内容而且在需求，有时候甚至是写完后根本无人去理会。而且，在需求变更时需要进行维护，耗费人力，文档在多次修改后导致内容很乱，或是前后需求矛盾的情况时有发生。
现在一个新的需求管理方法，需求的实例化，可以解决这些问题。需求的实例化是不再编写和维护需求文档，而是直接使用高质量的测试用例作为需求文档。通过测试用例可以很清楚的看到产品的需求内容，而且，在需求变更时，必然会产生新的测试用例，而不必费力去维护。在清晰的表现需求的同时，减少了维护需求文档的人力。
大老板在下基层体察民情的时候说：“我觉得这里应该放一个饮水机”。那么很有可能“放一个饮水机”是伪需求，领导渴了是真需求。要满足真需求，需要做的是随身带一瓶水。要满足伪需求就必须满屋子的放饮水机。
客户说“我需要一个自动汇总每月销售数据的报表”。那么很有可能“自动汇总”是伪需求，“数据真实、灵活的呈现”是真需求。要满足真需求，需要首先做一个销售明细的Excel导出，在线外灵活的筛选求和；要满足伪需求就得准备好应付各种体位的“自动汇总”。
用户说“我想有一个批量审批的功能，每天点OA太费劲”。那么很有可能“批量审批”是伪需求，“梳理出那些值得我审批”的是真需求。要满足真需求，需要梳理一遍业务流程，不一定涉及系统的改造。要满足伪需求就得准备在做好一个“一键审批”按钮后再做一个“一键撤销”。
当用户直接提出解决方案的时候，往往意味着诞生了又一个“伪需求”。因为他们所指的方向并不一定能到他们所想去的地方。
用户随意指的方向和他们真的想去哪儿，就是伪需求和真需求的区别。
我觉得在需求之前，应该是产品短期和长期的价值体现和变量（这个产品的引爆点，一般我们都考虑用户量和日活等因素…）
第二个在需求之前的是框架
产品逻辑搭建需要的产品框架体系，使得产品能够按照既定逻辑进行，不至于引起偏差……（创意期产品直面客户大多谈模式，就算你拿原型去讨论他们也不会有太多问题存在）
在此基础下，在用户应用和头脑风暴中的问题，我把这些问题称之为需求，而需求的真伪我觉得应该这样划分（个人习惯）。一个周期内验证一套框架逻辑即可，在框架逻辑内的，是真需求，这些需求可以分为易用性、应用性、流程性三类。易用性决定了产品的难易使用度（我把这个称之为周期内的客户的脑容量），应用性则是产品测试期既定逻辑的错误、用户限制（也就是我们管的太宽）等问题的发生，流程性则是在整个产品链条上的既定、预估问题发生变化（这个不太好看出来，需要综合分析）
在产品逻辑、设计中，易用性最简单搞定，数据埋点和支撑可以让你看到你的客户在哪里跳出高或者点击强烈，客服也能收集到不少的类似问题，规划和更改着重在前端。（如果是B端的部分产品经理，已经可以进行用户思维模拟化的话，就自己去走原型流程，进行更改－慎用，很多问题不是你想当然的）
而第二个应用性是后端的功能性问题发生，一般这些问题发生，大多是我们脑洞太大，场景和客户要的有偏差（如果你是直接项目负责，那么恭喜你，想太多…憋着笑，改吧）这种便差的发生一个是数据分析得出（需要些基础和对产品全局的了解，不会分析数据的赶紧学），第二个就是客户通过客服，营销指导的次数呈指数级增加（史上最难操作：）），应用性会改变部分框架，严重的应用性问题会改变整个产品逻辑。
第三个就是我们的既定核心价值没有体现出来
客户误解，或者客户不关注这个价值。这类问题是数据整个的综合分析，（骚年，事情已经不是你能搞定的了，开大会吧…）这种场景蛮少见，小一点的公司看不到。
现在我们来说说辩识真伪需求～（这个难度很大，脑袋里有东西，但是没怎么总结过呢，我尝试下，大家表骂我…）
第一，伪需求后面藏着真需求；
第二，部分伪需求可以通过已有产品模块解决，只是客户没发现（这里反思流程和易用）；
第三个最难，客户说的直接需求不是他想要的或者表达的，我还是建议你直接问细致的，我帮你琢磨下…
没法举例，因为我做saas+B电商的，语言服务类，俗称翻译电商，产品及其产品构成以人的智慧和学识构成…
这里有些划水，迟到+上班，这两天我再更新一个。。。。
继续，仔细想了下，发现在上面架构中，辩识真伪需求已经不是很难的事情，难的是场景的多样性：
首先，不管是真需求还是伪需求，都是在一个量级用户下的需求反馈统合，我们在分析归类后进行的深度挖掘的结果，然后根据量级用户来选择具有偏向性的一方，选择的偏向性为最快到达你阶段性目标的…猜测或逻辑。（在初期逻辑和价值确认后，我们不在考虑产品大架构和大框架的问题，那么我们的思维角度就要从P的角度转向为C的角度，主要做的工作就是归类、分析、反思）
我做B端（客户拜访和沟通中的需求）
举例1：
我在上上个月和营销去拜访一个客户，为了传播产品的理念和模式，那么我主要介绍给他的是我们贴合行业特性的协同平台和只为公司服务的封闭式订单平台，而我带去的目的性是他用我的产品并感兴趣，我们互加了微信和QQ，在过程中，我期望产品的讨论主要在当前模式下的产品应用，那么这个东西涵盖了易用和应用性（这些是当时就可以分辨出来的），而逻辑性却是比较难的。
那么这里我开始编：
1. 用户提出，二级域名这个东西接受起来很麻烦，每次总是分不清楚；（不确认需求）
2. 用户提出，在订单平台其实可以有更多种服务，能不能把订单外的X种服务增加出来；（假需求，这需要另一套逻辑兑现和落地）
3. 用户提出 ，产品在某个模块点击不进去；（真需求）
4. 用户提出，X个模块在逻辑上应该是这样的…（不确认需求）
…
那么现在开始分析：
第三个需求可以马上判定为真需求，因为我们经常进入一个误区，就是客户理解能力和部分模块的稳定性；
第二个需求判定为暂时性假需求，其实这并不是一个假需求，而是在当前周期内，我需要验证的并不包含这条逻辑；
不确认需求中的第一个，是因为这是个个体现象还是一个群体现象？需要收集验证。
不确认需求中的第四个，分几种情况，你足够了解这个市场，或者你有做过调研，那么这个是假需求，是订制需求；而你刚进入这个行业，那么先判定成为不确认需求；
数据需求收集：
这个中间分为全埋点和只使用工具+部分埋点的，那么如果是第二种，你看数据的时候，就要贴合你的核心需求来看（这问题好大，MD，掉坑的赶脚啊）。
举例：
我们直接略过渠道验证，纯粹认为来源用户都是需求用户。
那么我要看的数据是：
注册转化率（7-15天周期内的变化）：我的核心是不是被清晰表达，逻辑被认可；
细节中间可以看（如果有的话）：
从注册步骤1-3，用户在哪个步骤退出率较高或者停留时间较长。
（前者说明此模块有问题，后者说明你给用户造成了麻烦，需要优化）
留存率（次日、周、月-这个数值在你了解行业的前提下可调，和活跃一样）：整个产品模块和逻辑是否吸引用户，痒点是否有效；
留存率分为刺激性和非刺激性（如果想深入知道这些理论，最原始的应该是斯金纳的书）。
…常规数据的略过好不，最多你从热力图，点击分布，点击数据等，能看出在你框架下用户最期望用的产品和用户的疑难点，这玩意不难理解，多看看多将心比心下就好。
那么其实重要的是部分埋点数据，关键数据的埋点可以让我们看到客户的大致使用范围，比如：
我想要看到客户登陆后，是先进Saas协同，还是先去订单中心查看下有没有适合的订单；
我想要看到客户登陆后，点击统计和设置的情况；
我想要看到客户登陆后，点击帮助和退出的情况；
我想要看到多少客户只用saas；
我想要看到多少客户只在意订单和收入；
继续细分，我想要看到客户在哪个页面退出率最高等…
这些都可以帮助我们找到客户的需求点，同时还有一个~
按照客户分级，单一客户应用的潜在需求可能是你平台上的其他需求，那么，做一个刺激性、单一流程性的活动是比较不错的…
以上：你已经根据这些内容开始修改你的前端、完善你的产品、帮助系统；并且从中区分出了客户主体，对客户的掌控性开始建立…
额，我忘记说数据需求中，数据偶尔会说谎这个事儿了，不过这个不太难，电话反馈、有将反馈或者问卷调研什么的，如果愿意，直接出一个新产品模块来看看是不是当初的问题引起的A/B版就好~
需求没有真伪，只有你对需求的把握是否准确到位。对某种需求有需要的人群，是否是必要即时去开发新功能的。需求分先后，产品的完善是一步一步的，先解决大部分人群的需求，再慢慢去完善解决部分人的需求。
关于“数据需求分析 挖掘最根本的欲望”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！
本文来自作者[声英彦]投稿，不代表共度号立场，如若转载，请注明出处：https://goduck.cc/cshi/202503-13500.html
评论列表（4条）
我是共度号的签约作者“声英彦”！
希望本篇文章《数据需求分析 挖掘最根本的欲望》能对你有所帮助！
本站[共度号]内容主要涵盖：国足,欧洲杯,世界杯,篮球,欧冠,亚冠,英超,足球,综合体育
本文概览：网上科普有关“数据需求分析 挖掘最根本的欲望”话题很是火热，小编也是针对数据需求分析 挖掘最根本的欲望寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望...