功能需求调研

需求调研分析是产品经理人员常常去做的事情，用户调查的方法多种多样。然而，怎样提高用户调查的有效性却是个值得思考的问题，网上有很多提供调查方法的文章和理论似乎并没有系统完整地阐述如何进行用户调查，那么用户调查究竟应该怎么做呢？1.分析并明确调研的对象刚开始，第一件事就是确定调查对象。当我们做调查时，俗话说问对人做对事，含义：研究不同的用户群，获得不同的需求。用户按其研究对象可分为不同的类型。根据调查目的的不同，采取不同的调查方法，以发现不同的调查对象；所以明确的调查目标是整个调查过程中的关键第一步。从时间上看，调查目的可分为三类：i、产品状态：目前用户对产品的使用现状如何？ii、具体需求(用户来源、使用路径、资费等)：产品需求得到用户的认可吗？iii、使用体验：产品经验的表现如何？还有哪些地方需要改进？2.设定目标，使问题更聚焦2.1、在产品生命周期的不同阶段，用户调查有着不同的使命。在产品开发初期，我们可以根据调查结果得到不同的用户需求作为构建系统的依据，在产品上线后，我们可以从用户那里收集反馈，改进业务流程或用户体验。不管您是想要了解用户的观点和行为，验证假设，还是量化研究结果，您都必须在进行研究前确定这次调查的目的，因为任何无意义的闲谈或问卷调查都是无效的和干扰。2.2、其实很多人习惯问用户“你想要什么其他功能？”，“您觉得这个APP好用吗？”这样类似的问题，但这是把客户引向错误方向的开始。千万不要让客户告诉你怎么做系统。正确的方法是通过用户对业务和使用习惯的描述来构建或改进系统。所以在调查的过程中，有必要设定要达到的目标，然后围绕这个目标展开。确定调研目标后，我们要针对目标制定调研计划。调查的对象具有哪些特点？目标用户的地理位置？调查预算是多少？采用何种调查方法才能达到调查目的？问用户什么问题，以验证我们的疑问和假设？调查时间，地点，参加人员，设备，物料等准备工作。3.明确调研的形式研究方法很多，常见的有：眼动试验、A/B测试、可用性试验、用户见面访谈、电子问卷、焦点小组、参与式设计等。每一种方法都有其优缺点，我们在产品的不同阶段选择合适的方法，这里恰当的意思是指适合产品规模，同时也适合公司规模，比如许多中小型企业根本就不需要做眼球运动试验或可用性测试。基于我的经验，下面的几种方法是比较常用的，并且可以产生不错的效果：关于用户见面访谈采访用户最直接有效的方式就是和用户进行更长时间更深入的交流。更容易得到用户的真实想法和潜在因素，通常用于解决具体问题。在有了明确的目标之后，研究者提出的问题需要仔细推敲和打磨。在文章的下一部分，我们将重点讨论问题的组合。电子问卷调查问卷调查是一种常见的研究方法。问卷调查的优点是调查范围广，可以得到更多人的反馈，用于数据统计/分析。缺点是不够深入，问卷的设计会很大程度上影响用户的回答。因此，设计一份合理的问卷直接决定了本次调查的质量。一份优秀的问卷需要两个主要方面:长度和问题类型。通常问卷时间5分钟内即可，设定的问题要尽量具体，不要空洞。在问题设置上，要尽可能避免使用封闭式问题(提供多个选项，类似选择题)，因为这样的问题容易诱导回答者，从而导致结论不准确。另外，使用半封闭式和开放式问题的好处是，这样的问题可以让回答者思考更多，获得更准确的信息。真实场景调研在一些传统书籍中，也称之为“现场观察”，但现在更多的是再现场景。说白了就是创建用户平时使用产品的场景，看看用户在熟悉的环境下是如何操作的。在B端产品中，通常是进行实地考察。这种方法可以使产品人员对需求和业务流程有更直观的了解，更容易得到一些被忽略的细节。在观察的过程中，需要多思考，尝试总结整个任务的步骤，寻找脉络。4、分析调研结果4.1、对调查研究中的关键问题进行分析，得出相关结论，用来回答调查研究中的问题和假设。以需求为导向的分析过程如下：我们的调查用户和目标用户是否匹配？如不匹配，试着在下一次调查中找到更准确的目标用户。4.2、用来比较调查结果是否有很大的不同。使用者是否认为我们的产品满足他们的需求？这是一种痛点刚需还是一种无关痛痒的小需求？使用者认为我们的产品很酷？是否有特点？是否愿意为此付费？通过对调查结果的分析，如果我们的需求假设得到验证，还有哪些地方需要进一步改进？如果需求假设没有得到验证，是因为我们的研究用户不匹配，是需求有问题还是解决方案有问题？想想这些问题能不能解决，怎么解决。优化后，我们将进行下一次用户调查，并继续迭代。5.分析用户行为和真实想法；5.1、对调查结果进行分析，这是调查的最后一步，也是最重要的一步。若将用户需求比作一条污染河流，则我们通过调查得到的往往是河流下游的“可见需求”。经常会有困扰用户的问题，用户可以自己想象得到的功能等等。但是污水总是源源不断地从河里排出，我们必须找出一种方法去寻找来源，就是得到“没有意识到的需要”和“无形的需要”。5.2、潜意识地通过产品人员对真实工作场景的感同身受而提出更加合理的解决方案，无形需求是指产品人员对业务的深刻理解和用户心理去构思出用户无法想象的解决方案。因此在经过调查研究之后需要归纳和总结并大胆的提出设想，再去不断的进行实践和验证。并且，通过研究用户的想法，可以使产品人员了解用户为什么提出这样的需求，基于什么样的业务和心理前提，这样的需求是否值得响应等等，对需求分析有明确的指导意义。用户研究可以从不同的用户得到不同的观点，但产品不能追求满足所有人的需求，产品有自己的特点和定位。

第一篇文章《需求分析师如何分析需求》蜻蜓点水讲了下如何分析功能性需求，也是由于想的不够深入，经过这段时间的需求分析总结，此篇文章将更详细的讲解如何分析功能需求。对于功能需求的分析主要从两方面入手：业务场景和系统界面。一、业务场景什么是业务场景？场景是我们设计功能时的一个重要参考依据。所谓场景，就是用户在进行这步操作时所处的周围环境。这里的周围环境包含的维度很多，比如用户的属性，年龄、身份、工作等。场景不仅指物理环境，比如在车上、飞机上、教室里，还指任务场景，比如开空调的业务场景是因为夏天很热，需求是身体凉快不热。任何产品都是一种物质存在，要使其有意义，就应该置其于恰当的社会环境中，而且这种环境与其他工具或人密不可分。可以通过一个表格来描绘业务场景，比如描绘信评人员在财报更新的时候需要做跟踪评级。为了保持寝室卫生，大学几个室友在寝室决定轮流打扫寝室卫生用户在提需求的时候，多问几个为什么，为什么要提这个需求？目前是遇到什么困难？现在是怎么做的？如果涉及到业务数量的，还可以问下量大不大？比如某公司就只有一个客户做某业务，为了这一个客户去开发一个大功能，浪费人力、物力甚至造成项目延期。但也不是说，就不做，如果后续做这项业务的客户会越来越多，开发功能是需要的。将用户提出的需求业务场景梳理清楚后，接下来就是需要过滤用户的需求，有时候客户提出的需求并不是“真”的需求。很多时候因为客户自己本身对业务的不了解或者对行业知识不了解，基于某些情况，客户提出一些假需求，客户提出“假需求”的情况有：客户对自己本身对业务或行业上的知识不是很了解；客户基于“花少的钱获得更多的功能”心理提出很多个性化的需求；客户在提需求的时候有时候也会撒谎；客户不知道自己要什么导致假需求的产生。识别客户的需求到底是不是真的需求，最重要的一条是识别客户提出需求的动机，知道为什么客户会提出这个需求？（又回到业务场景的问题了）知道客户提出需求的动机以后，多问几个为什么，如果客户在回答问题的时候前后不连贯，或者没有逻辑，这类需求往往就是假的需求。在过滤掉客户假的需求以后，需要知道如何去表达需求，为了使需求更连贯和完整，建议采用“情景场景剧本”的方式来表达需求。把需求当成一个情景剧，有人物、有业务场景、有目标、有故事背景、有做事的动机、有情节等，可以用语言或者图形的方式将故事描绘出来。如果发现故事中有些情节是是断裂的或者是讲不通的，那有可能你的需求并没有真正弄清楚，需要重新去梳理一下你的这个需求。二、功能界面将用户的需求理解清楚后，只是脑海中或者文字的说明，需要更形象，通常是除了文字说明还需要画原型图，很难理解的需求，画出系统界面后，开发人员能一下子看明白。功能界面需要将每个功能按钮、查询条件、交互方式、以及界面上字段的类型、取数来源、排序等都需要细化。画原型图的工具用的比较多的是Axure。以上是画的比较好的原型图，连滚动条和翻页都考虑到了，可以说是比较具体的，开发人员一看就知道要怎么做。

一、为什么做需求调研？软件项目往往从用户的一个或者多个需求开始，需求调研就是彻底搞清楚弄明白用户到底想要什么，帮助用户把心中的想法具象化，这些具象可以是流程、功能、性能、界面等等。用户在提交需求时，往往有以下两种情况：（1）用户只是想到了某一点或者几点的功能，想法不成熟也不成体系。这种情况，需要我们帮助用户完善需求，一步步的挖掘用户到底要做成一个什么样的东西，这是一个引导的过程。（2）用户负责或者参与某项具体工作，想要通过信息化的手段实现。这种情况，需要我们先充分调研用户工作流程后，深入与用户讨论交流，让用户多说，我们多听。一般来说，用户并不是软件研发的专业人士，用户的很多想法、设计、思路和具体的软件设计有着一定的差别，这就是专业人士发挥的空间。专业人士依托用户的想法，结合自己的经验知识和用户一起用更工程化更科学的方法建设软件项目。因此，需求调研的时候，不仅要弄清楚用户的需求，还应该用自己的经验帮用户归纳出更加合理的需求。二、如何开展需求调研？1、准备软件项目开始的时候，我们一定会拿到用户关于软件的一些描述。首先，我们就要基于这些描述弄清楚用户要做的是一个什么样的软件，这类软件通常有什么样的功能，这类软件的应用价值是什么？有了这些信息后，我们才能在需求调研的时候更好地引导用户，有的放矢。2、调研准备工作完成后，可以开始与用户进行调研沟通，这时需要关注三个方面，即项目背景、业务流程和项目角色。项目背景调研的对象是项目发起者，一般是领导。项目背景，是了解用户建设项目的根本动机，也就是初衷。在不同的建设动机下，用户的软件的要求会有很大的差别。充分的调研项目背景，可以很好地把握客户的期望值和建设目标，从而有效地屏蔽风险点。业务流程调研的对象一般是业务负责人。业务流程，是调研的关键与核心，是最需要花时间、下功夫的，这需要反复地与用户沟通，充分把握用户的想法、要求。另外，业务流程不能简单地把线下流程照搬到线上，要找到线下流程的痛点，然后，在线上流程中进行调优。项目角色调研对象一般是一线工作人员。项目角色调研和具体业务息息相关，项目角色就是项目最终的使用人员，核心点是关注每个角色在业务中的任务，做好权限的切割和业务的流转。3、总结需求调研结束后，要有内容输出，一般来说就是需求调研报告。在需求调研报告中，要阐明项目背景与目标、通过本项目要解决的核心问题、项目中关键业务流程（必要时可以绘制业务流程图）、项目中的角色分工等。

产品经理要发现需求，而不是复制已有的需求。功能需求文档能够帮助产品经理深入理解需求，理解“为什么要做、为什么这么做”。本文乃作者应一位朋友要求，将项目分析的经验总结并撰写成文。我所在的公司将产品文档区分为FRD (Functional Requirement Docs, 即功能需求文档) 和PRD (Proct Requirement Docs, 即产品需求文档)。二者各司其职缺一不可，甚至在项目推动进程中，功能需求文档的重要性要高过于PRD。同事经常说，当你输出了一份好的功能需求文档，PRD就只是简单的体力活而已。一、为什么要做功能需求文档功能需求文档是人写的，给人看的。在我的认知里，功能需求文档有如下两点价值：对写的人：通透认知对看的人：统一认知产品经理在撰写一份合格的功能需求文档时，需充分调研场景、挖掘需求、分析利弊，梳理逻辑以达到逻辑自洽，一步步推演得出最终的设计方案结论。在这个过程中，产品经理能够以书面的形式整理并反复推演自己的逻辑，帮助自身深入理解需求，理解“为什么要做、为什么这么做”。而项目组里的同事，原先对产品需求、方案解决的问题是几乎一无所知的。产品经理要在一个短短的评审中将“为什么要做、为什么这么做”说透，则需要功能需求文档的支持。一份功能需求文档就像一份项目Kick Off的ppt，帮助视觉、开发等同学快速把对方案的认知拉到与产品接近的水平。因此功能需求文档是一面镜子，帮产品经理自清；也是一剂催化剂，帮项目成员迅速catch up。二、写功能需求文档前的思路准备1. 需求场景分析开门见山的，往往是最重要的，也是最考验的。我惯用的分析流程是需求来源、场景还原、痛点追溯。（1）需求来源是对于需求的数据具象如今产品经理收到需求的途径有很多，业务同学的反馈、用户的满意度调研、用户的使用数据、竞品的调研报告、产品对于世界动向的感知等等。每个声音途径的权重是不同的，各家产品经理需要表述清楚本期项目的需求具体来自哪个途径，并将需求声音的强度进行数据化表达。比如我们公司用jira管理业务同学的反馈，则在明确需求来源时，就可以搜集提过该需求的jira数量，以此初步定量需求声音的强度。（2）场景还原是对于需求的背景故事补全需求表达的是“用户想要的方案”，而且用户往往会在其中掺杂某些“自以为是”的产品方案设计。因此产品需要做的是抓着用户需求的藤蔓一路向上，到达的第一级便是场景还原。还原出明确的场景，有助于产品对需求跃然出生动的体感，而非停留在干涩的文字转述。场景包含三要素：谁、什么条件下、做什么。其中的核心是「什么条件下」，吃透条件有助于判断该需求的频次。（3）痛点追溯是对于场景的刨根问底还原场景后一定要记得多做一步——再多问2个问题：用户为什么要做这件事？在做这件事时遇到了什么问题？如果不刨根问底，就容易掉进“场景陷阱”，以为已抽象到最底层了。比如我们本月遇到用户提出打卡作业需要一次性布置多份内容不同的主题，经分析后我们发现用户的场景是“在未复学前安排老师做线上的打卡集训营”。有的产品经理此时已觉得分析到位，需求了然于胸，于是找了几个做打卡集训营的竞品研究研究，就准备输出产品方案了。这样就容易沦落到无脑的抄袭照搬中。正确的方式是深入到用户中，挖掘场景背后的目的。用户要做打卡集训营是想通过内容进行引流获客，因为疫情期间无法线下引流，线上投放又对转化率和现金流要求较高。因此我们除了满足打卡的基础工具支持外，还需要搭配营销解决方案，甚至与平台内的其他投放渠道进行联动，帮助用户获取更多曝光。甚至如果能找到一种更好的线上获客方式，我们完全可以不提供打卡工具，也能够满足用户。需求场景分析就是抽丝剥茧、寻根溯源的过程，把需求还原成场景、把场景还原成痛点。在这个过程中，对要解决的问题、要达到的目标会愈加清晰。2. 竞品方案分析明确需要解决的问题后，建议找几款已然能够较好解决该问题的产品，深入分析后作为参照。新手产品在接触一款新的产品时往往会束手无策，尤其遇到复杂的产品时，容易迷失在眼花缭乱的页面中。此时要注意竞品的分析方法，并且找到能与我们问题对标的具体功能，只取一瓢饮即可。（1）竞品功能定位明确竞品的功能定位：给谁用的？做什么用的？做成什么样？比如在研究竞品的打卡功能时，发现竞品将打卡类型区分为“打卡课程”、“作业课程”、“解锁课程”、“专栏课程”4种，此时则应该通过区分竞品提供的功能差异，明确这4种类型分别对标什么使用场景，不同的场景中用户关注的信息分别是什么、管理动作是什么。举个“打卡课程”和“作业课程”的例子。竞品提供的功能中，打卡课程和作业课程的核心区别有3：在创建方式上，打卡课程创建时有开始与结束时间；而作业课程没有；在子任务生成方式上，打卡课程在创建完毕后，系统会根据设置的时间范围创建出对应的子任务列表；而作业课程创建后无子任务列表，仍需用户自行在课程内创建；在数据统计上，打卡课程侧重打卡完成进度和时间进度的比较；作业课程侧重子任务数以及作业提交的份数。从这些功能差异点上，还原出各自对标的场景：打卡课程满足的场景，是用户需要布置一个有始有终的打卡任务。如英语教育机构内常见的每日打卡活动，从固定日期开始，到固定日期结束，每日打卡学习的内容均不相同。机构管理者关注的重点，是学员是否每日按要求完成打卡任务。作业课程满足的场景，是用户以一个课程或一个班级为单位去统一管理作业。如培优辅导机构内老师经常会在课后给学员们布置提高题，机构就可以在建班时为这个班级创建一个作业课程，这个作业课程自身无必要设置开始与结束时间，因为班级的周期可以非常长也可以很灵活。老师需要布置作业时，在课程内添加作业子任务即可。机构管理者关注的重点，是总共布置了多少次作业，学员又提交了多少。（2）竞品概念模型经验丰富的产品可以通过测试，反推出竞品的概念模型：有几个实体？实体和实体间的关系是什么？同样以上文中的竞品举例，分析后不难发现，竞品存在“课程”和“子任务”两个系统。子任务是依据课程的规则生成的。老师创建课程后，系统依据规则生成对应的子任务，将课程分发给学员后才可生成学员的课程。学生提交作业的过程，就是提交与子任务关联的答案。由于概念模型不是本文重点，图中仅绘制了流程中涉及的核心实体，实体的具体属性及其他关联实体，这里不作展开。（3）竞品功能使用流程测试竞品的功能主流程、异常流程，有助于我们在异常流程的设计中做参照。3. 核心方案抽象心中有了远方 (需求场景分析) ，手里也有了地图 (竞品方案分析) ，剩下的就是设计路线了 (核心方案) 。许多产品经理在设计核心方案时容易照搬竞品的方案，这里建议采用“否定分析法”，确保功能是充分且必要的。比如竞品设计了打卡具备独立的打卡介绍页，支持富文本编辑。新手产品也许会想：“嗯这个功能不错，我要抄过来”，但却忘了多思考一步——打卡子任务也有内容，打卡介绍页也有内容，为什么两边内容要分开做？不给用户提供打卡介绍行不行？要回答这个问题，则需要思考清楚打卡介绍和打卡子任务的不同定位——打卡介绍，正常的用法是用于介绍一份打卡作业，相当于书的封面，吸引别人把读；而打卡子任务则相当于书的内页，是正文内容。因此需要打卡介绍的场景，更多是要用图文介绍的方式吸引潜在客户参与，对于现有客户的客情维护则不需要打卡介绍。而我们的客户由于行业及规模属性，几乎没有面向潜在客户打卡的场景。这样分析下来，就能得出与深入思考前相反的结论：打卡介绍对我们而言是一个不必要的功能，不做。三、功能需求文档的表达方式即便思路清晰万事俱备，语言表达也是文档中不容小觑的重要一环。好的表达方式能够给FRD加分，差的表达则容易蒙蔽FRD中思维的闪光。每个人有自己惯用的语言组织方式，这里仅列举几个能给文档加分的表达小技巧。1. 举例代替描述需要注意在描述场景时，尽量讲具体、完整的用户故事，新手产品要避免抽象模糊的需求描述。用户故事最好有实例支撑，如用户调研时获得的某个经典素材，甚至是与用户沟通时的聊天截图。比如“调研发现A机构在疫情期间无法线下开课的情况下，选择采用微信群内打卡接龙的方式，与学员保持高频沟通，圈住学员。A机构采用的打卡频次为每日一练，每日内容为机构老师精心选择（配上内容案例），会在当晚12点前准备好第二天学员打卡的内容”，这样的表述，就会好过“调研发现，机构有每日打卡的需求”。2. 图表代替描述尽可能避免大段文字，长文对于开发同学来说看着会较为费劲。撰写文档时可以考虑用ppt绘制结构性的内容；用表格表达多维对比；用processon绘制用户使用流程。3. 一次说清一件事请记住：不同流程不要混在一个流程图里，不同系统不要混在一个概念模型package里。新手产品往往容易犯把所有信息塞在同一张图里的错误。比如流程图时把多角色多流程放一起，不仅绘制流程图时指向线很多，难以表述，而且读者的理解成本也很高。建议如遇这种情况，分开绘制，一个流程画一张图，一次说清一件事。4. 阶段性结论较大项目在功能需求分析时抽丝剥茧层层深入，篇幅较长，建议阶段性给一个结论，且实际的可往下执行的结论。如场景分析part，结论是“哪些场景已覆盖、哪些未覆盖，本期重点覆盖哪些”；竞品分析part，结论是“竞品哪些点值得学习，哪些虽然涉及精巧但不符合我们受众人群，哪些不值得借鉴”；项目方案part，结论是“本期有哪些重点方案要做，为什么做，解决什么问题”。像这样的阶段性总结，可以帮助你把思路一个个串起来，也能让听的人顺着你的思路走，不走神不跑偏。结语关键点总结需求场景分析需做好需求具象、场景还原、痛点追溯，势必“多追溯一层”竞品方案分析需从功能上深挖，明确对标场景，还原竞品概念模型，势必“多挖掘一层”核心方案抽象需否定分析通过举例、绘图、聚焦表述、阶段性总结的方式，使文档可读性更强此文断断续续3周才成稿，写完回读过去写的部分，并不是很满意，仿佛蒙着一层雾，不够精炼不够直击。产品需练、文笔需练，路恒漫漫，一点小小思考，供各位参考。本文由 @撕裂时间的少年 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。

当你的领导质疑产品调研时间过久，甚至说出：一个产品的调研，如果是他做，两天就完事之类的话，那么作为项目负责人的你，怎样才能和领导说明需求调研的方法论，并准确的执行呢？作者从多年的项目经验出发，对B端产品需求调研的方法论进行梳理，与大家逐一分享，本文首先向大家介绍一下需求的背景分析。什么是需求？需求被定义为：用户在产品使用过程中对产品的预期和使用现状的差距，我们服务的传统企业客户比较多，一般传统企业进行转型都是为了降本增效、串联产业链，帮助企业解决实际问题，提高工作效率，当问题未得到解决或未得到高效解决的时候，就会产生需求。项目需求背景分析：需求背景是指需求产生的原因及想达到的目标，通常我们接到客户的需求的时候，需要通过一些工具进行分析，常用的方法就是5W2H，但是这里可以简略分析，谁(who)需要通过怎样的途径(how)去达到什么目标(what)，总结下来就是what、who、how三个核心元素。what：是指本次项目目标，在进行背景分析时，我们需要明确项目目标，在明确项目目标的前提下，可更清晰的确定需求的边界。who：是指本次项目的干系人，包括直接干系人和间接干系人，我们需要尽可能的确定需求干系人并对其进行用户访谈，通过用户访谈确定干系人目前的问题及其关注点以及需求的重要程度，并以此进行后期的功能设计。how：是指该项目的策略级实施方案，通过对需求进行背景分析，我们需要确定项目的策略级实施方案，并根据干系人关注点、项目目标、项目资源确定当前最优解决方案。总结来说就是三步，第一步确定项目目标，第二步，确定干系人，第三步，解决方案。下面我将为大家详细讲解一下该怎么做。第一，确定项目目标项目目标是贯穿整个项目周期的产品方向，B端项目的目标通常是基于当前的业务形态制定的，且每个版本均需明确该版本的项目目标。那么，该如何确定项目目标呢？确定项目目标的关键是明确【业务场景+当前情况+目标】。具体的业务场景是需求分析的基础，业务场景具有故事化的功效，可帮助进行产品设计，也可帮助技术部门理解需求，明确当前情况，可确定当前的问题，而目标即是需求人对产品设计的期望，通过明确现状期望即可提炼出产品需求。第二，确定干系人确定干系人是需求分析必不可少的一个环节，与C端产品需求分析过程中的用户分析不同，B端产品的干系人分析不仅包括产品的用户(直接使用人)，也包括产品的直接和间接相关人。干系人可从目标和风险两个维度进行识别：1. 根据目标识别关键干系人，例如直接部门负责人、间接部门负责人、核心用户等。2. 根据风险识别关键干系人，例如：该功能的直接使用人、具有一票否决权的评价者、技术部门负责人等，引用一张图可以更清晰的看出来。确定干系人后，需对干系人进行用户访谈，收集干系人当前遇到的问题以及问题发生的频率及影响，再对问题进行归纳整理，进而产出策略级的解决方案。第三，解决问题首先应记录原始问题在进行干系人访谈时，我们需要记录用户对遇到的问题及问题产生的影响的原始描述，原始描述有助于后期对原始需求的追溯。 接下来需要整理问题并分析影响第二步我们需要对干系人提出的问题进行归纳整理，并分析其影响，问题的影响包括直接影响和间接影响。最后产出策略级解决方案，明确问题影响后，则可产出策略级的解决方案，并对比不同的解决方案的优缺点，在权衡干系人关注点、问题影响、当前资源等情况后，产品负责人和关键干系人对当前需解决问题的优先级及问题的解决方案达成共识。总结：由上可知，对于需求做背景调研可按照第一步确定项目目标，第二步，确定干系人，第三步，解决方案。根据项目规模大小，此阶段可能需要项目团队投入2-4周进行精细化调研分析。下一篇我们将讲一讲需求调研的调研方式和提纲及访谈技巧等内容，请持续关注。(本文为原创，如需转载请联系作者）

产品功能调研应该是每个产品经理的必备技能，本篇文章中，笔者从自身工作实践出发，分享了关于产品调研的相关知识，供大家参考学习。市面上很多产品看起来不同，但追究到产品底层逻辑，其实有着本质的共性。这些共性是市场教育、用户反馈和竞争要求的结果，因为我们面临的是同样的市场格局和同样大环境下的互联网用户。01 为什么做产品功能调研基于上述的共性，做产品设计时，观察其他竞品就非常有必要。尤其对于初级产品经理来说，当自身产品经验不足以支撑你构思出足够完善的功能架构、业务流程和交互设计，最有效的方法就是做产品调研，快速找到和了解竞品。因为已经经过市场验证的产品功能，就有其存在的合理性。我们就没有必要花费大量时间去做大幅度的创新，主要是帮助产品经理缩短产品设计的过程，提高性价比。可以在模仿竞品功能的基础上，结合自身产品业务做适度的创新。做产品调研的时候，不要只注重竞品表现层元素和交互设计的分析，这是新人比较容易走进的误区，更重要的是分析其底层逻辑和业务流程。就如一句老话：不要以貌取人。这是十分片面的角度。产品调研分为针对一个功能点的调研和一个独立产品的调研，那么这两种调研方式有什么区别呢？产品调研：会集中于相对比较新的，独立完整的产品，没有很多交错的产品。例如：不适用于支付宝，太庞大繁杂，会导致调研周期太长；功能调研：集中于业务逻辑、功能逻辑的细节示意图：功能调研与产品调研的异同02 怎么做功能点的调研首先要明确调研的目的，一定要带着目的去做调研，否则没有调研结果也是无用功。（此篇文章只展开谈论功能调研）明确了调研背景，我们具体该如何做功能调研呢？我就以下面三种调研类型展开来说。背景一：竞争对手上新功能了，对竞品新功能的调研目的：能抄么，有没有竞争壁垒？要抄么？首先考虑核心问题：目标用户：都有会谁用这个功能？罗列出可能的所有类型用户。用户需求：用户为什么要用这个功能？能满足用户什么样的需求？功能逻辑：不同类型的用户使用该功能的行为路径。梳理出功能流程和底层逻辑，应当先理清业务，再谈交互；观察该功能相关的数据表现（如果有条件的话）；输出结论，让老板做决策：要不要抄：和自己产品的用户群、整体业务框架是否符合？数据情况是否可观？能不能抄：是否有技术壁垒或特殊门槛得出结论，并给出结论的分析理由1/2/3条等，最后汇报给老板，让其做决策背景二：自己产品要上新功能，对竞品相似功能进行调研搞清自己的目标用户是谁，先确定目标用户。产品功能的现状如何？要调研哪些产品？尽量去找行业领先、产品口碑领先的软件。先梳理出功能流程和底层逻辑，再谈交互设计；竞品和自身产品有关此功能的差异点是什么。背景三：从学习的角度去做功能调研准备调研的那个产品的新功能有哪些？整理最近2/3个版本的新功能；产品设计三要素（用户、场景、需求）是否都会满足了？先梳理出功能流程和底层逻辑，再谈交互设计；产品的亮点是什么（功能逻辑或交互设计）？观察其数据表现。03 功能点调研实战以下是我对“快看漫画”和“腾讯漫画”详情页的简单调研。梳理并分析了两者的异同点。1. 两者阅读页的功能模块分解1）快看漫画阅读页V5.47.02）腾讯漫画阅读页V5.24.52. 两者功能模块异同点1）相同点两者的阅读页均分为导航栏和标签栏2大模块。功能点：章节名称 、漫画详情页入口、弹幕开关、发弹幕、查看目录、夜间模式、阅读模式、设置2）不同点分享的位置：快看把分享放在标签栏里，弱化了分享，导航栏突出了详情页入口；腾讯把分享和详情页入口放在一起，突出了分享，并且这两个功能均是在用户结束阅读时可能进行的操作，简单说是对漫画的设置，而不是阅读设置，属于同一性质。因此这两个功能放在同一区域更合理。收藏：快看将收藏按钮放在标签栏区域，引导用户在阅读页可以直接收藏，突出收藏功能；腾讯在阅读页没有收藏功能，可能是出于不打扰用户的目的，若用户喜欢该漫画，会在结束阅读后去详情页收藏（克制 ，毕竟微信是它的老大哥，hahaha）发弹幕、发评论：快看将发弹幕和发评论放在一起，可切换，引导用户快捷发评论，可增加评论转化率，既多了一个功能却又不影响整体排版设计，与标签栏的评论入口相呼应；腾讯只有发弹幕，且在初始状态下隐藏了弹幕的“发送”按钮，既保证了标签栏排版的简洁和美观，又没有牺牲发送功能操作的便捷性。因为两者发送弹幕的步骤数是一样的。因此快看在初始状态下的“发射”按钮显示多余。切换章节：快看可以在一级页面直接切换上一话、下一话，增加切换章节便捷性。也与快看在阅读下一话时必须手动切换页面的交互有关。评论入口：快看在标签栏上放置了评论入口，引导用户评论互动，促进活跃。亮度调节：鉴于腾讯标签栏已经有“夜间模式”，设置里的“亮度调节”是画蛇添足，有点多余（不信看埋点数据，它的点击应该没有标签栏的夜间模式高）。我能想到的唯一合理解释就是设置弹窗若去掉了它，降低了弹窗高度，影响美观翻页模式：由于历史背景问题，腾讯的漫画库中，左右翻页阅读模式的日漫、国漫较多，所以存在日漫模式；快看的大部分漫画都是近几年流行的条漫形式，均是上下翻页。翻页开关：快看提供了点击阅读页底部区域进行翻页的开关，顾全到了某些用户的操作行为路径，用户可跟随自己的漫画阅读喜好调节。横竖屏：切换阅读的模式，可是手机的重力感应也可以做到同样的效果，这个功能可以去掉了单章节评论开关：用户可跟随自己的漫画阅读喜好调节。弹幕自动播放：快看的亮点功能，快看的弹幕展示区别于传统的左右滚动弹幕，但是让用户可以在漫画内容上的任意位置放置弹幕，固定不动，给予用户极大的主动控制感。由此弹幕的交互设计衍生出了许多有趣的互动形式。例如：编辑一个箭头的弹幕，放在漫画人物旁边，就意在指向它。言归正传，弹幕自动播放开关，可以调节弹幕聚在一起，不影响纯阅读体验；可以把弹幕扩散开，在原定的位置显示，增加弹幕互动性。更多弹幕设置：由弹幕特殊的交互设计衍生的设置功能。增加趣味性3. 结论综合快看漫画和腾讯漫画的漫画阅读页而言，快看做的更胜一筹。前者突出弹幕趣味性和评论，更注重读者之间的互动交流，促进活跃和粘性，但又不牺牲阅读体验。另外阅读页的交互设计也呼应了快看的产品战略方向——内容+社区。这是拓展用户增长点的一个战略方向。后者突出阅读的沉浸式体验，更注重阅读相关操作的便捷性和阅读体验。产品整体的用户体验和交互设计更好一点。如果有不同意见，请多多指点哟~本文由 @Zss 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。

对产品经理来说，绝大多数工作时间都是围绕需求展开的——需求分析、需求调研、跟进实现需求等。那么关于需求调研这部分，一般都有几种调研方法呢？我们又该如何使用这些方法呢？需求调研是需求实现的前提。需求调研主要内容有：了解需求背景、明确需求目标、过滤不当需求、确定大致方案。需求的用户是谁？需求解决的核心问题是什么？使用场景有哪些？哪些是主要和次要场景？业务的流程是什么？除了主要业务还有哪些流程可能使用这个功能？除了本系统还有哪些系统会关联到这个功能……这就是需求调研的“十万个为什么“。本篇结合《后端产品经理宝典》书中的内容，单从需求调研案例出发，看几种常用的调研方法。一、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。1. 用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。2. 功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。二、拆分和聚合的方法1. 拆分需求法业务用户提出一个需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。这里不一一展开。2. 聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。三、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。四、“拔萝卜带出泥”的方式调研需求调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。举例说明：背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。分析：第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。五、需求得分权重法该方法的思路就是将需求质量的维度进行权重，然后对需求进行打分，根据最终得分的多少排列顺序。如表所示，采用五个维度：先`先`重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为30%、30%、20%、10%、10%。那么一旦对需求打了分，就可以用分数*权重，得到最终得分。注意：负分的要减。并且为了方便计算，分值最好设置0.5-5.0之间，或者0-10之间。这样避免打分的跨度过大出现较大偏差。如表所示，需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分为-0.1。由此可以判断需求的价值顺序为：需求1>需求2>需求3。对于需求3，可以予以淘汰。以上的维度、分值和权重可以根据实际情况自行设计，但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从，而只是把它当做一个辅助工具。六、其他需求调研工具需求调研适合核心环节，该过程就会涉及到很多工具或分析方法，以确保需求调研高效、高质量。比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。以上整理自《后端产品经理宝典》。#专栏作家#书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交App。本文原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议

需求调研是一门非常深的学问，不仅仅要掌握专业知识，更要具备沟通、引导客户的能力。特别是项目调研过程中，遇到一些比较难沟通的客户，还需要我们具备相当高的情商，总之，项目经理或者需求经理，既要会“写”更要会“说”。今天小编和大家分享一些需求调研的经验，希望能够帮助到大家。1、见客户之前，先了解项目情况首先，项目已经到了需求调研阶段，必然经过了立项、投标等过程，所以需求人员要通过咨询立项人员、投标人员了解项目的前期情况，同时，认真阅读投标文件，保证见客户之前，已经有一定的项目基础。其次，通过官方网站，了解一些客户的基本信息及组织机构，确保我们能够对不同级别的用户有不同方向的引导。最后，见客户之前，需求小组内部最后进行一次沟通会议，保证所有掌握的知识是准确的、有用的，尽量不要在客户面前犯错误或者内部意见不一致。2、制定项目的调研计划制定调研计划的好处非常多，比如需求调研能够有序进行、需求人员能够合理安排工作计划、能够提出提出对客户的咨询问题等等，这些都不是我要列出这一章节的目的。个人认为，调研计划的目的就是让用户清楚我们的工作计划，根据工作计划来安排他们的工作时间。做过需求调研的人都清楚，客户的时间是需求调研最大的风险，所以，我们必须给客户强调我们的工作计划，确保客户有时间和我们沟通需求。3、调研过程中收集的内容调研过程中，需求人员会向客户收集一些资料，具体收集什么资料，不同的项目、不同的客户收集的内容是不同的，不再进行说明。这里要强调两个方面的内容：客户资料隐私内容的处理，需求人员向客户收集资料时，一定不要收集客户有隐私数据的资料或者保密数据的资料，一旦收集，后续如果有数据丢失或者泄露的事情，你是脱不了关系的。客户资料的保管，收集到公司的用户资料，在保管的时候，一定要分权限，比如资料通过SVN管理，一定要进行权限的分配，其次，如果收集的资质材料，一定不要乱扔，放到指定的地点。4、挖掘客户需求的方式制作demo，需求人员应该去客户现场前，制作相关的原型（不一定非常完完善，能够说清楚业务过程即可），在客户现场给演示原型，调研的效果会非常好。参与客户的实际工作，需求人员到达现场后，可以通过观察客户的实际工作流程，根据客户的实际工作流程整理客户的需求和问题，，调研的效果会非常好。小编认为，这两种方式是最有效的调研方式，也是常常使用的两种方式。5、换个角度，站在用户的角度考虑问题交流过程中，尽量用专业的词语和用户进行交流一定要考虑到用户的使用便捷性总结以往的实施经验，提出建议总结以往的实施经验，引导需求6、调研过程中，工具的使用功能结构建议使用：XMIND软件流程图建议使用：VISO软件会议纪要和调研报告建议使用：WORD功能矩阵和问题列表建议使用：EXCEL原型设计建议使用：AX图形设计或者界面设计建议使用：PS数据流程设计建议使用：POWERDESIGNER7、调研过程中，需要注意的事项如果客户允许，建议整个沟通过程中使用手机进行录音。沟通过程中，一定要一边沟通一边记录不同的客户，调研不同的需求，避免理解上的差错客户永远是对的（学会聆听，态度决定一切），不要一棒子打死异己的观点，尝试站在他人的立场思考问题，这样会更容易找到满意的答案。拒绝不合理的需求，但是要注意方法定期汇总的成果：什么情况下？什么人？做了什么决定？产出了什么？所有过程文档，能让用户签字的，必须要签字，这个是双方的一个保障。

产品经理要为产品负责，并且以产品为手段，推动业务发展。以产品为手段，就是把产品当做产品经理自己的延伸，用产品经理的思维和方法去解决问题推动业务发展，而产品就是思维、方法和解决方案的载体。产品经理要通过产品表达想法，就像作家通过书表达想法，建筑师通过建筑表达想法。与书、建筑相比，互联网产品拥有敏捷迭代这一大优势，书和建筑没办法两周更新一次，但是互联网产品可以。总览产品的整个生命周期，其最小粒度就是版本，产品的版本迭代，就是推动业务的方法之一。产品迭代，就是要基于需求进行产品设计以解决问题，一般包含需求调研和产品设计两块内容。（PS：需求挖掘和产品设计只是产品经理的工作内容之一，其他还包括项目管理、沟通交流、竞品分析、进度排期、产品培训等，实质上都是为产品迭代服务的，而产品迭代是为业务服务的。）需求调研是为了明确版本迭代的内容，产品设计是基于需求出详细解决方案，需求调研和产品设计阶段都要灵活，某个已经确定下来的需求因为产品设计方案实现不了也只能被砍掉。什么是需求调研和产品设计？举个例子：有一天，产品经理在论坛上溜达，发现有个用户说他想吃鸭子。产品经理去沟通后发现，其实他是饿了，自己又喜欢吃鸭子。要不要解决这个需求呢？假设要，产品经理怎么解决呢？没条件就给个包子，有条件的给个秘制烤鸭，一碟小菜和一碗饭。秘制烤鸭（来自百度图片）需求调研阶段：“发现有个用户说他想吃鸭子”→需求收集“产品经理去沟通后发现，其实他是饿了，自己又喜欢吃鸭子”→需求挖掘“要不要解决这个问题”→需求评估产品设计阶段：“没条件就给个包子，有条件的给个秘制烤鸭，一碟小菜和一碗饭。”→产品设计下面将从需求调研和产品设计两个篇章分析。需求调研的四个步骤需求调研既然是为了明确版本迭代的内容，就要经过需求收集、需求挖掘、需求评估和需求评估的四个步骤。需求收集，建立需求反馈通道和需求池，随时收集需求。需求挖掘，洞察本质需求和场景，理解需求方。需求评估，紧急度和重要性，尽量做即重要又紧急的。需求分析，需求分解和边界确定，做到什么程度。需求调研需求收集：需求反馈通道和需求池需求的来源包括公司、产品经理自己、运营、市场、用户等等。平常要注意建设良好的需求反馈通道，需求反馈通道可以分公司内部和公司外部。公司内部是指内部的运营、市场、财务等部门提交的需求，随着业务发展公司每个部门都会提出各种各样的需求以便于数据增长、提升效率、减少成本、风控等。如果每个部门都每个人都想产品经理提需求，这就会出现A说要做B说不要做的信息偏差问题。所以要有一套需求提交规范，每个部门可以有个需求收集员，需求收集员向内对接部门成员统一部门想法，向外对接产品经理沟通业务需求。如果遇到部门间冲突/合作的需求，还要拉来各部门的相关人员进行讨论确定。公司外部是指来源于用户、竞对、行业专家等人的需求。可以通过用户群、用户反馈、回访调研、微博吐槽等了解用户的需求和关注点，寻找用户的痛点，能从用户中脱引而出。可以通过使用竞对产品，查看竞对更新/帮助文档等了解竞对的发展情况和产品策略，寻找自己的差异化。可以通过行业会议、文章、当面交流等了解行业的趋势和行业未解决的痛点，创造企业从行业中突围的机会。需求反馈通道建设起来以后，就要建设自己的需求池，把每个需求分门别类放好。关于需求池的文章有很多，我在就不再赘述了，注意记录两点：要解决什么问题和建议的解决方案。需求挖掘：归因和同理心每个人提的需求都是基于他自己的理解，而他自己的理解通常都是片面的，因为不了解具体情况或者只了解他那一端的产品。一个系统，暴露在人们眼前的永远只是冰山一角，没有海面下部分的承载，也不会有海面上的炫目冰山。普通用户所提出的解决方案和需求都是有局限的，其价值不在于直接使用，而在于产品经理基于它去挖掘更深层次的需求。如果用户让你给他鸭子，你就给他一只鸭子，这就是产品经理的失职。产品经理需要用自己的同理心，化身为用户，在他的场景下面思考需求。我一般用以下两种方法。1.问题归因，需求的本质是什么？当一个系统比较复杂的时候，绝大部分问题已经无法一眼看穿了，需要产品经理自己去挖掘。就像一个婴儿哇哇大哭，喂了奶不喝，摸摸额头不烫，抱起来一看原来是尿床了。这就是归因。怎么进行问题归因？首先，要了解问题的表现，婴儿的哇哇大哭就是不舒服表现出来的样子。其次，了解导致问题出现的可能情况，婴儿不舒服的原因有饿了、渴了、生病了、尿床了、发现妈妈不在身边等几种。最后，定位问题的本质所在，抱起来一看尿床了。2.用同理心，为什么提出这种解决方案？如果需求方只提出了解决方案却没有提出问题，也可以从解决方案中倒推问题本质，有条件的话还是向需求方求证比较靠谱。（1）解决方案是了解需求方的一种途径，因为是建立于需求方自身对问题、产品和操作习惯等基础之上的。通过解决方案倒推需求方对产品、问题的理解和操作习惯，能够让我们更好的揣摩和理解需求方所处的角色和产品在需求方心目中的画像，以小见大，无论对后续需求评估和日常用户理解都很有帮助。（2）解决方案也是个衡量标准。需求方提出的解决方案一般只有60分，只是能解决问题，处于需求金字塔的下方。产品经理以其为衡量标准，去判断自己的解决方案是解决了哪个层次的需求。理想状况下自然是超出需求方期望，触动需求方的G点。实际情况并不是谁的需求都要满足，因此要进行需求评估。需求评估：重要性和紧急度需求评估主要评估的是优先级，常用的方法有KANO模型、四象限模型、波士顿矩阵模型等。我比较常用的就是四象限模型，优先级：象限一 重要且紧急 ＞ 象限二 重要且非紧急 ＞ 象限三 非重要且紧急 ＞ 象限四 非重要且非紧急。四象限模型如何判断需求的重要性和紧急度？1.重要性的判断标准，几个比较重要的情况公司战略：产品经理是为产品服务，产品是为业务服务，业务为公司服务，公司战略落地的需求是从顶层下来，是需要优先考虑的。利润相关：公司是要赚钱和生存的，通常客户＞用户，大客户＞小客户。基础结构：产品是一座楼，基础结构就是地基，稍盖几层没有太大关系，如果地基没搭好就会有坍塌的风险。包括角色、实体、主业务逻辑、系统架构、账号体系等。2.紧急性的判断标准摸清实际情况：业务方、用户等通常会提出很多非常紧急的需求，产品经理不要被打蒙了，要先摸清实际情况，影响了多少业务，影响了多少用户，什么原因造成的等等。根据影响评估：摸清实际情况后，根据需求的影响进行评估。核心业务高于边缘业务，影响用户多高于影响用户少，造成损失高于未造成损失等等3.四象限模型重要且紧急的比较少，如果多了就需要反思是评估问题还是产品基础没打好；重要且不紧急的要多做，这些代表了产品的未来，而且要慎重，决策要慎重迭代也要慎重，要花时间去打磨他，不要急于求成，也不要一上一整个；不重要且紧急的要少做，做多了产品容易被牵着鼻子走，还会造成资源浪费，如果多了就需要反思是不是以前产品迭代没做到位；不重要且不紧急的要不做。需求分析：需求分解和边界确定需求评估后，就要对第一第二第三象限的需求进行需求分析，需求分析的目的是得出要做到什么程度，60分和90分效果和所需资源都不一样。我通常会在需求分析时，先进行需求分解，后进行边界确定。1.需求分解需求分解，指思维发散，思考需求未来的发展，思考需求所触及的功能模块。无论是业务、产品、功能或是需求，都有自己的生命周期，都是不断发展的。产品经理要基于现在判断未来。把需求比喻成木桶，做产品就是造木桶，木桶的木板就是产品模块，木桶越大承载力越强成本也越高。需求分解的时候，产品经理要思考木桶以后要多大，木桶的木板要有几根。2.边界确定边界确定，指根据当前需求/业务状态、需求方心理预期确定需求的边界。俗话说，最合适的才是最好的。如果你现在功能远远超出当前需求，可能到产品死了都还没用上，这就是对资源的浪费。如果你现在功能还不能满足当前需求，这也是对资源的浪费，下次迭代前需求方还会来找你。理想情况下，是超越当前需求一小段。具体这一段有多长，就需要根据需求重要性、业务发展情况等进行合理评估了。边界确定就是确定木桶的高度，很高不合适很低也不合适，木桶的高度取决于要装多少水。决定了木桶高度之后，就可以去造木板了，造木板这就是产品设计的事了。本文由 @Vency 原创发布于人人都是产品经理。未经许可，禁止转载。题图来自unsplash，基于CC0协议