拆解需求是为了从用户的角度出发，提炼出真实、核心的需求点，将其转化为产品可实现的功能，避免产品变得臃肿和分散。通过考察需求的真实性、一致性、价值性和可行性，可以筛选出符合产品战略和用户需求的关键需求。
为什么要拆解需求？
作为产品经理，通常在经过用户调研后，我们收集到了很多现实的使用场景，和希望我们实现功能的意见。产品通常也对这些反馈，进行了整理。但这些反馈的视角，是用户，不是产品经理。我们下一步的工作，就是要站在产品的角度上去看需求。
如果用户说什么，我们就做什么，我们极可能解决的是用户一时的问题，不是根本的问题。他们不停地提，我们不停地做，产品会越来越臃肿，结构也越来越散。更悲催的是，当新客户进来时，我们发现功能不适用，还要不停的开发。
拆解需求，就是要把用户的需求，揉碎了，掰开了去看，找到核心关键点，转化成产品可实现的功能点，这样产品才有主基调和灵魂。
如何筛选需求？
Gerald M.Weinberg在《探索需求》中提到了需求理论：需求是我们想要的东西和我们不想要的东西。同时，我们收到的需求，总是含混的。做需求相关的工作，就是不断地降低含混。他还创造了一个“需求蛋”模型：
但在我们的调研过程中，我们接收到的需求，不那么容易一下子辨别是想要的还是不想要的。那么，这4个方面的考虑可以帮助你过滤一些不符合产品的需求，即我们不想要的东西。
真实性
- 用户真实性。这个需求是否是目标用户的需求？当用户向我们提出需求的时候，我们会先了解下提出人，以防假性用户干扰。比如说一个服务员和我们提员工提成报表的需求，我们会认为他是非真实用户，因为在实际工作中，他并不会接触到这一块，这块的真实用户是老板和财务等管理人员。
- 需求真实性。目标用户是否真的存在这个需求？是目标用户没错，但不一定是真实的需求。比如说洗车店提供上门洗车服务，听上去挺合理的，但仔细想想，并不能有效降低用户的时间成本，可能还会额外增加沟通成本以及经济成本。这不是一个真实需求。
通过考察需求的真实性，可以过滤掉一些虚假的需求。
一致性
- 产品一致性。需求功能和现在的产品战略和定位要一致。比如说用户提出需要三级分销的功能，本身我们的方向是医疗，不是电商，营销不会做的这么深入。这就不符合产品一致性原则。
- 用户一致性。用户之间的场景和痛点有一致性。由于个人习惯或者特殊场景，很多时候用户提出的需求是存在片面性的，和其他用户没有共性。这就不足以支撑我们去做。
通过考察需求与战略定位、产品定位、目标用户的一致性，可以过滤掉不一致的需求。
价值性
- 企业价值。需求能给企业带来什么样的价值？价值有多大？比如说用户想要诊疗系统中包含专业的财务分析模块，以方便他们会计做账。但我们不是专业的财务软件公司，这个功能对产品的价值提升帮助不大。会不予考虑。
- 用户价值。需求能给用户带来什么样的价值？价值有多大？某个用户提出这个需求的时候，对他们来说是有价值的，但不意味着对对其他用户有价值。比如说上面的财务模块，需要这个功能的诊所不多，一般会计人工或将数据导入专业软件就可以搞定了，对大部分诊所来说价值也不大。
通过考察需求的价值性，可以过滤掉没有价值或者价值不大的需求。
可行性
- 技术可行性。基于现在的技术水平，或者框架。组件，是否可以实现功能。比如说根据电脑的颜色自动更换系统界面的颜色，目前并不能实现。
- 成本可行性。投入成本过高，收益却很小，不是一个可行方案。比如说诊所想要药品数量不足时自动进货，但不同诊所供应商不同，要分别和上游进行对接，成本太高。
通过考察需求的可行性，可以过滤掉目前来说超出企业实现能力的需求。
从这4个方面筛选完需求后，我们留下了那些真实、有价值、可行的需求，下面还需要分类去分析。
如何拆解需求？
找到共性需求
从上面筛选出的需求中，我们首先提炼出共性需求。这些是我们首要解决的问题点。抓住了这些点，功能设计从大方向上来说，不会有偏差，后期最多是一些细节问题的处理。
怎么找共性需求？
- 找到共同痛点。比如说现在诊所使用的优惠券都是纸质的，每次发放和使用都是人工记录的，极其不方便。
- 找到共同解决方案。针对上面的痛点，诊所都想要使用电子优惠券，发放和核销方便，统计也简便、准确。
什么样的算共性？
- 需求比例高。这个比例不是固定的，看自己的业务需要。可能是80%，也可能是60%。
- 意见领袖建议。有时候调研一个比较新的需求，问了不少用户，但发现基本没有仔细想过。这时候就听取意见领袖的看法吧。一般他们想法比较新，而其他用户后面也会学习他们。
考虑个性需求
不是上面的共性需求，就是个性需求了。但个性需要也要好好分析，决策是不一样的：
- 如果需求本身是合理且常见的，但现有用户需求量较小，后面会有大量的增长，那在功能设计时还是要把这块考虑进去，只是实现的时候优先级比较低。
- 如果是较为个性的，以后通用的可能性很小，那考虑下功能能不能变相的去满足他，如果稍微有所改动，就能满足，那也可以考虑。如果实在很个性，就放弃不考虑。
仿照共性，这样的可能是个性需求：
- 需求比例低。比如10份有效结果中，只有1个提出。当然，这个比例也是根据自己的业务来定。
- 低质用户意见。不是说低质量用户的意见都是不重要的，但低质量用户可能为了自己的方便，不遵守基本规范。不符合规范的，想都不用想，打入冷宫了。
如何将用户需求转变为产品需求？
理解用户需求和产品需求的区别
需求按认知层面的划分，用户需求可以分成表面需求和本质需求。产品经理需要从获取的表面需求中提炼出用户的本质需求。理解用户的本质需求，有利于我们更好地提出产品需求。
有一个比较经典的故事：
福特在没造车前曾经问消费者们想要什么，消费者们告诉他说是更快的马。要是一般人恐怕就信以为真了，然而机智的福特看到了本质：消费者们其实追求的是更快的速度而非更快的马。于是乎，他基于更快的速度这个本质需求造出了车。
表面需求（用户想要的）
表面需求：用户只会从自己的角度出发，基于自己目前的痛点来提出解决方案，他们没有考虑别人，甚至没有考虑自己后续的发展。
十个用户可能6个提出的需求都不一样。我们需要识别表面需求的背后。
比如用户说有人恶意预约，占了号又不来，能不能把他拉入黑名单。我们会产生疑问，黑名单就能解决恶意预约的问题了吗？黑名单他真正想要的功能吗？
本质需求（用户需要的）
本质需求：他真正基于什么场景有什么困难，要怎么解决。
抛开他给我们提出的解决方案，我们听听他提出的理由。给他梳理一下，就能发现他的本质需求。可能十个用户提出的表面需求都对应着同一个本质需求，那我们抓住了本质需求，就可以针对性的解决，避免重复造轮子。
比如增加黑名单的本质需求是减少恶意预约，而黑名单功能只是表面需求。我们是通过黑名单的方式，还是其他的方式来解决这个问题，其实他们不在乎。
产品需求（我们能给的）
产品需求：我们基于自己对用户需求的理解，对技术成本的理解，给出一整套可行的解决方案，帮助用户解决本质需求。
用户需求可能会存在这些问题，导致不能直接变为产品需求：
- 用户想要的并不是他真正想要的，做出的产品没有解决根本问题。
- 用户想出的解决方案过于理想化，系统并不能完全实现，需要产品给出折中方案。
- 用户想出的方案只是一个片面的点，并不能形成一个完整的闭环，很多场景不满足。导致做出的功能不好用，体验差。
就像上面说的，用户本质需求是减少恶意预约，那我们不一定要做黑名单的功能，换成限制一日内同患者，同微信号的预约次数来解决，成本低效果也好。
将用户需求转化为产品需求
就问题达成共识
这里面有一个很大的原因：沟通偏差。有人可能有疑问，都是中国人，还不能理解对方说的是啥？还真是！一方面中文博大精深，引起误解是很正常的事。另一方面隔行如隔山，我们以为用户理解了我们的话，但极可能他们没懂又不好意思问，反过来也是这样。像这样的沟通，存在信息差也不足为奇。
如何才能避免沟通偏差？
- 让用户完整地描述一遍场景流程。注意听他的5W1H，即【什么人】在【什么时间】【什么地方】因为【什么原因】做了【什么事情】，是【如何做的】。
- 向用户重复一遍自己理解的场景流程。也可以用上面的5W1H来表述。
为什么要问场景，不直接问用户你需要什么？就像上面的，你问用户，用户会说：我要皮试啊，可是怎么要呢？当把客观场景描述出来后，我们都明白了其中的问题，也能首先就问题达成共识，这有利于后面提出解决方案。
帮用户想解决方案
让用户给你想解决方案你真的放心吗？想想自己有没有过这样被坑的经历？可能在刚开始做产品经理的时候，我们以为用户说什么，我们做什么，就是对用户好，就能让他满意。然而，等产品上线了，他却来投诉了。
千万要避开用户需求的2个误区：
- 理想主义用户提出的需求
这类用户想要一个彻底的解决方案。比如说上面的恶意预约，和我们提了好多方案：失约2次的自动加入黑名单，永远不能再预约；预约了又取消2次的加入黑名单，预约前先经过我们审核；提醒我们定期去查看黑名单客户，把一部分时间长的客户取消限制……这些都对，只是真的能杜绝掉吗？用户换个微信，换个姓名不是又可以约了吗？而我们花了这么大的精力，真的值得吗？我们给出的方案是做预约次数的限制，效果差不多，实现容易。
有时候产品所能提供的，是不完美的解决方案。表面需求，就是用户自己想出的1.0版解决方案。本质需求，就是不可达到的终极目标。产品需求，则是产品经理基于现行条件给出的优于用户所提解决方案的2.0版解决方案。
- 思维简单用户提出的需求
如果你真的按照他说的做，发现连个闭环都走不通，他们往往是“头痛医头，脚痛医脚”。你需要给出的是一整套解决方案。包括别的用户可能遇到的问题，而不局限于这一个用户。
比如说用户想要给客户发一张优惠券，那我们必须给他考虑一整个流程：创建，发送，领取，核销。发送有哪些渠道，领取有哪些方式等等。如果只想建完后发送，后面的不考虑，功能做完后发现都不知道客户来没来，还要手动记录，他肯定投诉。
那我们可以怎么帮用户想呢？
还是基于上面的场景，针对和用户达成的共识问题，提出我们的解决方案，看用户是否能接受。
我们想的方案是否真的满足用户需求呢？
还要反向去验证下。有3种验证方法：
- 自我验证。闭上眼睛把自己想象成用户，在他的场景里面完成一系列事情，看看遇到的问题是不是都得到了解决。
- 团队验证。把场景和解决方案和你的伙伴们讲述一下，看他们有没有疑问，是不是觉得你的方案能解决用户的本质问题，还有没有其他潜在没有考虑到的问题。
- 用户验证。把方案发给需求来源用户，请他看看是否解决了他的痛点。再发给其他同类型用户，看看这套方案里面有没有其他场景没有考虑到。
经过这3步的验证，我们的解决方案大方向上是没有问题的，但这其实也不能算最终的产品需求，请看下一步。
选择适合产品实现的方案
即便我们和用户达成了解决方案的共识，还要和开发达成共识，这是选择方案的过程。可以从这2个方面我们来评估下：
- 对现有功能的影响。是在系统里面做增量，还是大范围的改动，和其他功能之间的联系有多大。如果要做，会涉及到哪些功能点，哪些页面，评估出影响范围后，可以先pass掉一部分了。
- 开发实现的性价比。当我们把所有的影响范围列出来后，开发就可以评估时间和实现程度了。性价比过低的方案也要毙掉。
做产品千万别求完美，哪有那么多完美的方案，常常是鱼和熊掌不可兼得，我们的方案保证的是目标用户的真实需求，是有价值的，可行的方案。
总结
需求是功能实现的来源，找对需求，才能做对功能，才能解决用户问题，实现产品价值。
- 先从真实性、一致性、价值性、可行性四方面来筛选出合理的需求。
- 找到用户的共性需求和个性需求，优先考虑共性需求的实现。
- 识别用户的本质需求，将用户需求转化为产品需求。
虽然用户需求是根源，但产品的设计还需要考虑其他的点，很重要的一点是竞品分析。下节就会详细的讲述竞品分析，来确定产品的功能定位和优势。
需求分析就是从用户的需求出发，分析挖掘其背后的真实诉求或者预期达成的目标，进而再转化为产品需求的过程。例如用户想要一匹马，以便自己可以更快地去到目的地。但此时你可以提供给他一辆车，因为他关注的并不是骑马还是驾车前往，关注的是更快的到达。
所以需求调研分析的本质就两步：挖掘用户的真实需求（确认需求目标），提供对应的解决方案。
没有回复内容