需求调研的方法及过程

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

编辑导语：一个产品的开始阶段就是产品调研，因此产品调研质量的好坏对产品来说至关重要。对产品经理来说，B端产品和C端产品的需求调研是很不同的，那么B端产品的需求调研该怎么去做呢？本文作者就结合工作经验，总结出了B端产品需求调研应该注重哪四个方面。需求调研对于一个应用产品来说，是一个产品的开始阶段。它的输出“产品需求分析报告”是设计阶段的输入，需求调研的质量对于一个产品来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个产品的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。作为PM，我们都知道C端产品和B端产品的需求调研方式是有很大的不同，但是想把产品做好，需求调研却是每个产品经理不得不去学习和了解的。那么，如何才能高效有用的去做好B端产品的需求调研呢？本文将从以下四个层次来分析：业务架构、业务流程、工作细节、信息结构图。这里需要注意的是，需求调研的四个层次，在前一个层次没有搞清楚前一般不会开始第二个层次的了解。一、业务架构业务架构的核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境以及梳理高阶需求和非功能性需求。关键词：组织管理结构图1. 业务背景产品痛点诞生的背景：明确产品的业务场景是什么？明确产品的目标客户是谁？明确目标用户为什么要使用这个产品？2. 业务目标业务目标是指针对企业特定的战略项目和其目标的文件，并在规定的时间必须完成或达到。业务目标应基于公司宗旨制定战略，对战略进行目标分析并制定具体措施的部门中长期规划。3. 业务目标人员投资人、老板、总经理等，囊括了业务参与人员。4. 业务参与参与人员使用产品的人。5. 组织架构例：电商组织架构二、业务流程业务流程为达到特定的价值目标而由不同的人分别共同完成的一系列活动，活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也都必须有明确的安排和界定，以使不同活动在不同岗位角色之间进行转手交接成为可能。关键词：绘制业务流程图那么，在进行需求调研时，该怎样去梳理业务流程呢？梳理业务流程是一个挺复杂的过程，这个过程主要是以实际的业务场景为基础获取业务信息，然后抽象出一个以参与对象为节点的业务流程。我们以电商为例：此流程应当包括5W2H内容：Who、What、Why、Where、When、How to、How much，最终可以通过泳道图等工具一目了然的展现方式展现出来。1. Who——用户整个业务流程中所有涉及到的所有相关人员。需要注意的是针对B端产品，用户不但包括客户、商家，可能还会涉及到多个角色以及平台侧的服务人员，如：客服、财务、商品管理员等。2. What——目标即用户需要完成哪些事儿。针对B端类产品，比如：发布需求、对接需求、签署合同、支付货款、履约交付等。这些都是用户在业务进行到一定的阶段需要完成的一些相对大一点的阶段性的目标。这些目标在后续需要进行进一步的细分处理拆解子目标，作为后期切分页面的依据。3. Why——原因了解用户为什么需要完成目标。这涉及到设计的流程及页面是否可以进行优化和调整，是否可以从流程上进行节点删除。梳理业务流程不是简单的照搬，需要分析现有实际场景中各节点的必要性，现有流程是否可以进行优化或者调整，知道原因能够有效的帮你判断。例如：订单生成后的调整价格，其源头在于用户与商家间的议价行为。4. Where——地点主要说明用户会在什么地点完成目标，地点会影响到你提供给用户完成目标的入口。如：订单处理人员的办公地点多在办公室内，工作环境多数对着PC端，如果仅提供移动端页面就是不符合场景的。5. When——时间主要说明用户会在什么时间完成目标，时间影响到你提供给用户完成目标的交互设计内容等。如：工作时间，用户完成目标可能由于本职工作，需要信息尽可能的详细，甚至对于信息的真实性来源等都有所考虑。但如果是业余时间，则用户可能没有意愿完成细致工作，简单的移交或者搁置、审批等则是更好的选择。另外在视觉设计环节，夜晚使用的页面设计和白天使用的页面设计是不同的，例如微博的夜间模式。6. How——如何完成目标这个过程真正体现了当前场景下用户是如何操作、处理的，这个环节需要特别在意用户习惯，需要深刻挖掘用户习惯。7. How much——完成其目标所需要花费的成本代价这点是可以打动用户的一个很重要的方面，如果可以把收费升级为免费，把货真价实变成物超所值，或者在等价值的基础上给用户更多的体验，这将是产品的杀手锏。当根据5W2H梳理完B端产品的业务流程之后，就可以输出产品的业务流程泳道图。三、工作细节工作细节次针对每一个参与上述业务流程的参与者展开，描述他的工作细节，做什么、怎么做、有哪些规则（权限）、结果是什么。关键字：用例模型1. 获取用例渠道岗位手册——对企业管理人员和各业务部门工作人员所在岗位的工作职责、管理权限以及企业各项业务工A作提出的具体规则与要求。业务流程指南——描述管理系统内各单位、人员之间的业务关系，作业顺序和管理信息流向的图表。它用一些规定的符号及连线表示某个具体业务的处理过程,帮助分析人员找出业务流程中的不合理流向。职务说明——通过职位描述的工作把直接的实践经验归纳总结上升为理论形式，使之成为指导性的管理文件。2. 业务主角访问引导方法您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事的目的是很么？您做完这件事希望有一个什么样的结果注释：通过以上的4个问题可以引导业务主角代表说出他们的业务需求。3. 用户主动提出需求的时候可以，多问几个什么为什么要提这个需求？目前有什么困难？现在是怎么样做的？如果涉及到业务数量的，还可以问下量大不大？当搞清楚工作细节字后，就可以输出用例图。以电商为例：四、绘制信息结构图绘制信息结构图就是脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。关键字：信息结构图作用：当根据步骤完成信息结构图之后，B端产品的需求调研就结束了，整理好所有内容后，就可以进行需求分析，调整细节后，下一步就可以进入到设计阶段。本文由 @星河 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于CC0协议

在生活中，我们会经常听到别人谈各种需求，作为产品、研发等人员更是离不开需求，所以这篇文章重点谈谈产品的需求和解决方案。文章的框架：产品需求的内涵、分类及层次内涵人们生理和心理上的欲望产品是为了满足人们的需求而被生产出来的,因为需求的驱动,才会使得用户需要产品。互联网产品就是通过互联网技术来满足人类的需求。互联网产品的形态有: App、Web网页、PC客户端、 各种硬件内的软件、AR、VR等等。产品经理所做的工作就是如何设计用互联网产品去满足用户的各种需求。分类用户需求满足用户所想，用户就是上帝马斯洛需要层次理论商业需求商业化变现为主不管企业如何变现，一切基于是否满足用户需求，才会带来商业价值。层次需求层次理论将人类需求从低到高按层次划分为五类,只有较低层次的需求得到满足之后,较高层次的需求才会成为新的动力。产品需求层次的规律、拆解用户需求需求层次的规律这些需求都是与生俱来的,不会随着社会的变革而变化,即需求是不变的,变得是满足需求的产品。越靠近底层需求越是刚需越靠近高层需求，则新鲜感驱动越明显拆解用户需求一条用户需求可看做是“目标用户”在“合理场景”下的"用户目标’其实就是解决"谁”在“什么环境下”想要"解决什么问题”。举例：用户问题：我有个朋友酷爱运动,他跑步的时候一定要听音乐,而且要听特别动感的音乐。我就想知道最近流行什么音乐、不然K歌时总觉得自己很落后。不知道大家有没有这个烦恼,不知道该听什么a推荐的自己又总不喜欢。拆解：目标用户:休闲型/小资型/达人型使用场景:.上班路上/工作时睡觉前....用户目标:快速找到最流行的音乐/需要音质最好/只听某类型的音乐需求获取的方式外部用户竞品市场合作伙伴腾讯内部有一个需求研究法则: 10/100/1000法则。它的意思是说产品经理每个月必须做10个用户调查,关注100个用户博客,收集反馈1000个用户体验。虽然我们很可能没办法做到,但我们应该记住这个法则传递出的理念:去了解你的用户, 尽最大可能去了解你的用户! ( 这很大程度上依赖于三件事:用户调研、用户反馈、数据分析)内部产品数据分析通常情况下,有两种东西会直观地反映出一一个人的心理,一个是他所说的话,另一个是他所做的事。用户调研和用户反馈,就是去听用户"说话”。而数据分析,则是去看用户"做事"。所谓“做事”就是用户在使用产品过程中所产生的行为。而用户产生的这些行为,会以数据的形式被记录下来。对这些用户行为数据进行分析,可以帮助PM更好地理解用户的真实需求。老板同事头脑风暴自己使用产品热爱生活如何记录需求获取需求之后,还需要对数据进行一个初步的记录,以便于后面对需求进行分析、管理与实现。需求挖掘的场景场景心理场景通过研究用户在特定环境下的心理,然后针对每个心理状态进行分析和提出对应解决方案标签场景通过研究用户在特定环境下的心理,然后针对每个心理状态进行分析和提出对应解决方案案例：需求分析的方法和如何筛选需求分析这一步,具体又可以分解成三个部分:需求筛选、需求透视、需求排序。这三者的逻辑是这样的:首先筛掉不做的需求其次对要做的需求进行进一步提炼,最后对提炼过的需求进行优先级排序。需求分析的方法真实性一致性价值性可行性透视需求表面需求轻而易举可以找出，但实际意义不大本质需求用户想解决的根本问题。获得用户的本质需求更可能找出更合理的方案来解决用户的问题。需求优先级KANO模型基本型需求期望型需求兴奋性需求用户自己并没有意识到的隐性需求。这类需求的满足可以给用户带来极大的惊喜。当这类需求得到满足后,用户对产品的满意度和品牌忠诚度将会有显著提高。因为用户没有意识到的缘故,所以这类需求即使没有被满足,也不会引|起用户不满。比如微信聊天中的红包功能。( 也就是我们说的兴奋点)这三类需求的重要性判断原则是这样的:基本型需求最重要,期望型需求和兴奋型需求在不好判断时通过需求重要性公式确定。期望型需求和兴奋型需求的重要性公式:重要性=功能使用用户百分比(用户使用率) x功能使用次数百分比(功能使用率) x类别重要性百分比。( 通常情况下,我们可以将期望型需求百分比定为50%兴奋型需求百分比定为25% ).当需求收集到后,紧接着就需要对收集来的需求进行分析、筛选、排优先级,这项工作是最考验产品能力的,互联网行业瞬息万变,只有利用好手中的资源合理安排需求,才能抓住市场机遇，优先满足用户需求,才能获取市场流量。

在需求采集过程中，我们需要与客户进行需求调研，如何高效的组织一场需求调研会，达到需求调研会议的目的，这是非常考验产品经理的hold现场的能力。一、需求调研会议的常见问题在与客户进行需求调研会的时候，若事先没有组织好会议，常常出现各种情况，最终没有收集到想要的信息，没有敲定下需求，还带回来更多新的需求。例如：没有认真准备，现场调研工作很随意，参会人员没有到场没有识别出关键干系人，造成很多需求意见太多，不知道听谁的会议节凑没有控制好：会议没有节凑、跑题、超时客户提出一些不合理或难以实现的需求需求调研重在收集用户的需求，而不是提供解决方案好记性不如烂笔头，会议纪要不要忘需求调研就像外交一样，实际上是一种策略艺术，它是在与客户相互尊重、平等互利的基础上，不卑不亢地去交流沟通，守住我方底线，尽可能的争取有利于我方条件。并在完成任务的同时，还能赢得客户的理解和尊重。1. 没有认真准备调研工作很多人在开始进行需求调研之前，并不清楚调研的目的，没有做准备工作，没有制定项目的调研计划，也不清楚调研目的，到了现场很可能对各种突发情况措手不及。在制定计划时考虑到分析时间。计划在公司内部评审通过后，及时提交给客户，让客户对调研计划有充分的了解。调研要认真准备，但说来容易做来难，很多人调研前的准备工作其实都是很随意的，好的调研准备工作可以包括以下几个方面：首先进行项目背景了解，可参考之前的文章《需求调研的第一步：项目背景调研》。和项目前期人员(咨询顾问、客户经理和平台主管)充分沟通，听取他们的建议，使自己调研更有针对性。此处有一个很重要的工作一定要向前期参加工作人员了解是否已经收集了一些资料，并想办法获得，已经搜集的资料和问题尽量避免重复询问，这对用户会造成巨大不满。如果万一前期资料不能获得，也要另外提前准备好说法避免这种情况出现。制定调研计划，计划制定后最好先在公司内部沟通评审，与相关领导、项目经理、业务部门一起，确定客户方的配合人（唯一联系人）、领导（唯一协调人），介绍需求调研计划。计划需要提前告知给客户，以免客户方突然接到调研通知，没有会议室或者关键人物临时有其他事情不能到场。这些细节也是非常重要的，在明确需求调研会的安排指挥，我们需要正式通知参会人员：邀请参会人员，明确告诉他们此次会议的目的和重要性与干系人确定会议时间和会议地点在开会前30分钟，通过QQ、微信等方式信提醒参会人员2. 不清楚调研涉及到的干系人做需求调研的时候，必须要找对干系人。如何忽略了重要的干系人，遗漏了他的需求和意见，最后很要推翻之前的工作。可能项目往往死在被忽略的干洗人手里！了解客户的组织机构、涉及软件使用的部门、参与调研的部门和人员、客户关键人是谁等等，尽可能获得客户上层的支持，自上而下的开展需求调研会使调研工作更容易推动。客户需求小组成员要尽可能多的代表客户不同的用户层次。那么如何识别干系人呢？第一步：了解客户的组织架构，谁是产品“决策链”中最核心有效的人，该听谁的。第二步：了解产品的面向用户，涉及哪些部门和人员岗位会使用本系统。第三步：从产品获益的人员， 对产品产生影响或者感兴趣的人。3. 会议跑题、超时，没有节凑控制因为调研工作实际就是和客户聊天谈话，很可能就会经常跑题，越扯越远，另外客户的精力一般也容易不集中、跑神，这时候，调研人员要能够掌控整个进程——什么时候及时把客户的思路拉回到正题上，什么时候适当的聊聊其他的话题调节气氛，都需要调研人员灵活掌握。总之一个目的，尽快的推动调研工作朝前进行。同时，要有人数控制，人数太少，可能调研结果不够全面，人数过多，决策统一周期可能过长，一般情况下3-5人的焦点小组会议比较合适。而且不要立马进行调研状态，有时候需要做一个简单的开场白：首先是自我介绍，有时候还包括公司介绍；其次是说明会议的目的、调研的内容和计划安排；最后了解被调用的对象，对其配合调研表示感谢，顺便奉承一 下，例如说能得到您这样有经验人员配合是我们非常高兴的事情，让其有一个好心情开始配合调研工作。在会议结束的时候，需要对会议进行总结，并说明下一步的工作安排，例如今天会把讨论的结论整理出会议纪要。最后需要再次感谢大家的参与。4. 规避客户不合理的要求和较难实现的要求客户需要的不一定的是客户真正所需要想要的。客户永远没有错，错的只有我们没有真正理解客户的需要。调研时要把握主题的能力，分清有用功能、可选功能用、无用功能及不可实现功能，及时表达我们的观点，让谈话接近主题。调研的过程中，不可避免的会出现客户提出一些我们现有条件下根本无法实现或者即使实现也非常困难的要求。这种情况就需要需求调研人员的聪明的头脑和快速反应能力，同时也需要调研人员的良好的沟通技巧，要能巧妙地说服客户放弃这种方式并且还要客户能够理解，而不致认为你在逃避问题不想解决。一般可以采取这些方式：客户提出这些要求后能马上了解客户提出这个要求的真实目的，然后快速思考出另外的简单的方式同样能实现客户的这个目的。这是最好的方式；必要时直接告诉客户无法实现并且给出合理的理由，特别是在客户说某某系统已经实现了这个方式时，比如他们用的是什么什么平台支持，这个平台支持需要另外付费等等；直接告诉客户虽然能实现，但是需要很大的精力和成本，而这个可能是客户无法承受的，当然你一定要能说出客户听起来合理的理由。5. 过多讨论解决方案我们在和客户沟通的过程中，需求多注意以下几点：关注用户的需求，需要探索需求背后的原因，多问用户几个为什么避免讨论技术问题，特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式鼓励用户讲故事，故事是帮助我们理解用户的想法，也帮助用户理解我们的想法访谈中避免用户过去强势，把我们带到沟里；同样避免我们过于强势，把用户带到沟里客户跟你说的内容只是他的一个理解，他的理解可能也有偏差，而且现在有的客户因为对软件比较了解，往往告诉你的不是需求，而是他的设计思路。对我们来说，就需要多问几个问什么，“你为什么会这样做呢？”“你想看的结果是什么呢？目的是什么呢”等等，一定要想办法了解到客户没有经过转化的最原始的需求。因为往往很多时候客户告诉你的他的想法并不能实现他原本的目的，而他以为能实现，所以就直接告诉你想法。需求调研人员如果没有了解到最原始的需求而只是把客户的想法记录下来，那么就会出现做出来的东西解决不了客户实际的问题。提供解决方案往往是临时思考没有经过全面分析，难免偏颇，为了表现能力而承诺一定可行的内容发现实际上并不是那么容易，导致后期实施骑虎难下。做项目不是一个人在做，而是一个团队在做，如果没有沟通就向用户提供了自己的思路，可能会给整个团队的思路带来干扰，解决方案一定要在内部达成一致才能提供给用户。6. 会议信息的记录和确认及时记录涉及客户业务、实际工作、客户想法的内容，不能以为当时听明白了就不去记录。一定要有记录的习惯，谈上几个小时，很多细节是记不住的。这个时候，如果没有专门记录会议的人员，也可以提前准备录音设备，以防信息遗漏。我们需要在会议结束之后，及时把白天调研的内容及时整理出来，当时没来的急记的内容及时补记，同时再深入的分析、过一遍，确保有没有遗漏的问题，列出所有的疑问待到第二天调研时询问客户。立马发布调研的会议纪要，及时总结成果，让客户听听你的理解是否他们提的需求一致。一方面以防大家时间长了，忘记了会议中的重要信息，造成信息丢失。另一方面也是变相地留下证据，以便后续的需求变更和成本核算，提供信息依据。二、总结客户业务调研和需求分析注定是一个不断细化的过程，从粗到细，从宏观到微观循序渐进。需求调研需要必须先从宏观上了解客户业务的全貌，再逐步深入细节。因为对于客户的业务而言，我们是外行，如果从业务细节着手，很容易迷失方向，失去对业务核心的把握。不要指望一次访谈/调研就能穷尽。因为事实上很多需求是隐性的，连用户都不清楚自己的需求。只有经过多次循环细化才可能把更多隐性的不断挖掘、暴露出来。虽然说调研工作质量和调研个人业务能力是直接相关的，有丰富经验的人在很短时间内就可以完成高质量的调研，取得被调研用户的认可，没经验的人花费大量时间在现场了解情况可能还是给用户一个不懂行的印象。他们是否按照正确的过程组织调研工作，按照正确的方式做事自然会更容易取得成功，有无其它行业经验只是成功调研的一个积极因素而已。第一个阶段叫调研准备阶段，这个阶段要完成调研计划的确认，调研背景资料的准备两方面的工作。这个阶段工作质量将对能否顺利开展调研工作起到关键保障作用。第二个阶段就是现场调研阶段，根据调研计划完成各项调研工作，并取得用户认同。第三个阶段就是调研后续工作落实阶段，调研结束后往往要准备会议纪要，信息确认跟进等工作，所以调研结束后一定要趁热打铁，把后续工作落实到一定程度才能再做其它工作，此时调研工作才能算结束。本文由 @瓜子 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。

编辑导语：对于B端产品来说，需求调研是经常做而且很重要的一件事，只有对需求足够了解，才能设计出大众所喜欢的、市场所需要的好的产品。那么，应该如何开始你的需求调研呢？需求调研的执行过程又是怎样的？如何对结果进行汇总和反馈？带着这些问题，我们一起来看本文作者的分析吧。一、什么是需求需求=预期-现状。二、需求调研的意义C端产品和B端产品在调研方式上，存在差异。C端产品往往并不是通过用户需求调研获取产品需求，而是基于对用户群体的深度认知分析、并通过一系列策略方案设计等得出产品改进方向。B端产品需要解决很多实际应用场景问题，往往需要对行业非常了解，深入行业，了解行业现状和诉求，才能设计出更为符合市场需要的产品。1. 了解实际情况通过调研了解客户目前实际的工作情况，管理情况，制度流程等。2. 找出系统偏差了解实际情况同产品之间的差异：哪些是可以系统化的、哪些线上管理会更复杂、哪些在线上能够得到优化。3. 分析问题并确定核心问题对收集到的需求内容进行分析，归类整理，确定与目前产品有偏离的需求点，提炼共性核心问题。4. 用户更愿意使用产品针对共性要点问题，结合当前产品现状，进行迭代优化，让产品更适应客户的实际管理工作，切实提高产品效率，让客户更愿意使用并依赖系统。三、需求调研的过程需求调研，包括目标制定——确定调研计划——选择调研对象——确定调研方式——设计调研问题——规划行程安排——调研过程执行——调研结果汇总分析——调研反馈等几个阶段。接下来我们对几个重要过程进行详细分析：四、如何开始你的需求调研（调研计划）1. 确定调研目标要做需求调研，首先需要明确调研的目的，要达到一个什么样的效果。大方向确定了，才能进行后续规划。2. 选择调研对象目标确定后，接下来对目标进行拆解，确定调研对象，调研对象是调研分析过程中最重要干系人之一，需要仔细做好管理。确定调研对象的范围、职位、数量、访谈时长、地点、沟通方式等。3. 确定调研方式调研方式一般包括行业研究（典型客户研究、竞品分析等）、深度访谈、调研会议（客户反馈会议等）等几种方式，本文后续主要针对深度访谈进行分析。4. 设计调研问题1）如何设计调研问题合理设计调研问题，能够起到很好的引导和提示作用，通过5W2H等方法，对调研问题进行相对完整的梳理分析。Who：由谁来完成Where：在哪完成What：完成什么事情When：什么时间完成Why：为什么要完成How：怎么完成How much：涉及哪些费用2）分层设计调研问题我们在确定需求调研目标时，可能会涉及多个不同的岗位，而调研对象也往往具备不同的职位。我们在调研时，要考虑调研对象所处的层次，针对不同层次的人群，设计不同层次的问题。调研问题可简单分为战略层、战术层、执行层问题。战略层问题：一般需要被调研者具备较高的视野或者职位，能够对总体目标有比较清晰的认知和规划，清楚最终需要达到的方向。我们了解战略目标后，方向基本更加明确，可以指导调研人员少走弯路。战术层问题：一般集中在各类策略制定上，比如管理流程、营销策略、定价策略等等。一般是对公司总目标的分解，被调研对象集中在中高层管理人员，处理管理类工作较多。管理类需求的实现很可能是决定客户是否采购的重要评判依据。执行层问题：一般集中在具体执行层面，此类调研一般是在总体目标基本明确，流程基本清晰的情况下进行，大多集中在人员安排、工作细节等类工作上。对于具体的工作任务分配及工作效率的提升，有较强烈的需求，执行层问题可以多关注具体业务细节，找出需要进行增效提速的痛点需求。3）设计调研问题注意事项适当删减：适当针对某项工作，设计调研问题时，可以进行裁剪，有些背景情况已经比较明确的，没有必要多次强调，减少沟通成本。设计开放性问题：需求调研问题，可以设计一些开放性问题。我们并不能考虑所有的情况，设置开放性问题，有时会收获意想不到的惊喜。尽量不做假定性设定：设置问题，以了解客户的实际操作为主，尽量不设置假定性问题（方案设计环节可以使用）等。不设计引导性问题：比如您觉得我们XXX功能是不是很好用等等，让客户说出自己想说的答案，不要引导，不要误导，这样容易得不到客观的答案。调研问题设计可参考下表（内容可自行设计）：5. 规划行程安排调研启动前，先沟通好行程，让配合调研的客户或伙伴有相应的准备。能够抽出时间及精力，配合我们的调研。提前建立联系，有助于拉进跟调研对象之间的距离。五、需求调研的执行过程1. 切入需求调研方式确定后，根据行程安排，见面后简单介绍来意、目的；可根据环境聊一些简单的问题，夸赞对方好的地方（注意诚心，不要浮夸），拉进跟被调研对象之间的距离。2. 观察观察力是产品经理必须要具备的能力，我们在观察时，要注意人、场、事、流。其中，人、场、事是比较容易观察的，流程想通过观察获得，有时会有一些困难。可以结合提问来了解情况。1）人观察人的年龄、性别、穿着、情绪、说话风格等，迅速了解这个人的一些基本特点，以调整应对方式。比如：这个人比较专业，就尽量少问一些基础问题；如果这个人比较严肃，就尽量少用一些玩笑的口气；如果比较乐意沟通，就尽量多问。2）场多观察办公场景，场景是线上和线下结合的重要参考因素。有时候，你看了他们的办公环境，就知道有些功能他们一定不会用。观察整体办公环境，可能会发现一些协同的地方，如共同区域、管理流程等；观察个人办公环境，可以分岗位去查看，每个不同岗位，桌面上或桌面下以及办公桌周边，配置的物品会有所不同。可根据不同物品的摆放，找到一些不便捷地方或者很好的地方（考虑线上化实现）。3）事观察被访谈者的办公状态，主要工作处理时的情况，在沟通时，可让被访谈者模拟办公场景。关注其他人的办公状态，我们访谈时，往往会把注意力被访谈对象身上，而那些没有参与访谈的，他的工作状态往往更加真实，可以多留心观察。4）流对于一些工作流要额外关心，工作流往往属于比较复杂的协同工作，这些工作流对于线上化的需求，可能会更加强烈，线上系统对流程协同容易找到更好的解决办法，提升协同和沟通效率。3. 提问熟悉环境时，我们就可以开始提问，提问题不一定要非常正式的一对一谈话，可以边聊天边进行，在访谈对象的办公桌前也是一个比较好的选择，可以边聊边观察访谈对象的日常工作。提问题时把握好时机，并不需要根据访谈列表一一提问，访谈列表可以事后整理。提问过程中，如果有些回答没有说清楚，或者有些问题之前没有考虑到，及时进一步提问，以便弄清楚事实。整个访谈过程，可以进行录音，以便事后整理。4. 倾听在访谈过程中，一定要注意倾听，时不时予以肯定，交谈过程中，不要出现否定客户的行为或者语音。鼓励访谈对象多说，我们多听。需求调研的过程，并不是解决客户问题的过程，我们对于客户在访谈中提出的一些问题，可以适当解答，但尽量不偏离调研主题。对于用户的一些操作或者系统使用方法，我们看起来不合理的，不一定要纠正，要及时弄清楚，客户这么使用的原因是什么，这也是产品改进的重要参考因素。5. 感受（同理心）感受实际是在沟通过程中的一种心理过程，我们应该要具有同理心，尽可能同客户站在同一个的角度看待问题，每个人所处的环境不同、认知不同、层次不同，客户的回答也许没有价值，但这本身就是一种价值，他代表了一类客户的认知或者问题。这类人也是我们的客户，如果我们能很好的解决并满足这类人的需求，对产品的发展同样大有益处，同理心是一个人能够持续成长的很重要的特征。6. 记录访谈过程中，有时候很多问题来不及记录。如果条件具备，可以记录一些提纲性内容，事后再来整理，最好是可以准备一个录音笔或者使用手机录音，事后进行整理。7. 合理帮助（可说可不说时，则不说）针对一些客户明显有违常识或者知识内容错误的，可适当提醒，如果把握不好尺度，可以不用提出，避免沟通氛围出现问题（有些人性格外向，乐于学习，比较容易接受，有些本身有一定的身份，为人严肃，现场直接指出错误，可能会出现其他问题）。访谈最后，确认是否有其他问题，感谢别人的帮助。六、需求调研的结果汇总1. 调研样本归类需求调研完成后，对调研内容进行归类整理，对不同客户的特性，也进行归类整理，了解客户群体，问题类型等。2. 问题汇总对问题进行汇总，同样的问题，同样的回答、不同的回答，各占比多少，如有不确定内容（如一人一个回答），可以增加调研的样本量，或者记录后分析原因。3. 统计个性与共性问题问题汇总后，统计个性问题及共性问题。对于共性问题，一般是我们需要进行重点处理的内容，对于部分个性问题，保持敏感性，特别是用户在回答问题涉及到一些本能（比如涉及到贪、懒等）需求，这类问题可能具备价值点。4. 合理推理对于一些调研结果，需要进行一些合理的推理，以便弄清楚调研结果出现的原因；对一些调研结果进行推理，得出更为合适的结论。有些用户所答问题，并不是实际情况，很可能是用户自己也不清楚想要什么，或者为什么。这时，合理的推理能够解决一些问题。七、需求调研的反馈1. 感谢对参与访谈的人表达感谢，无论是调研结束，还是下一次沟通的起始，感谢别人的配合和帮助。2. 反馈调研结果调研结束后，部分客户或者协调人会期望得到反馈，我们对内容收集整理后，可跟客户保持沟通，及时反馈调研结果（比如后续会进行排期等等）。3. 补充收集内容对于一些问题没有一次性沟通清楚的，可以事后再次联系该被访谈人，了解情况，注意不要时不时问一个问题，可以将问题汇总后，集中沟通，效果会更好（看客户情况，如果双方建立了不错的关系，方式自便）。4. 产品上线反馈（需根据调研沟通情况反馈）对于一些客户在访谈过程中所提问题，已纳入排期计划并上线，可以跟客户保持沟通，并跟进用户使用情况，以便后续的产品优化调整。在总结这篇文章的过程中，结合自身工作中的一些实践，也参考了一些行业前辈的工作经验，比如本站“周伯通”老师的一些文章，对于我学习掌握需求调研方法论很有益处。感谢行业前辈的分享和指导。期望能跟大家一起多多交流，企业服务不是一件容易的事情，希望中国的企业服务能够和国外一样蓬勃发展。本文由 @原始森林 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议

本文梳理了什么是做需求分析与需求管理，以及为什么要做与如何去做。01 概述本文是梳理需求分析与需求管理方法-产品经理工作职责&工作核心技能之一，笔者写本文的目的一是把自己的知识体系做个输出，包含来自己的经验总结和最近学习到的知识总结，其二顺便分享。知识方法无定论，任何内容先看思路，实战为主。在分析一个问题时，可以用一个通用的框架方法论，WWH法：是什么？为什么？怎么做？这样可以把思路理清晰。因此引出了本文的主要内容：什么是需求？为什么要做需求分析？什么时候做需求分析？怎么做需求分析？说明：时间有限，本文的案例不代表实战解决方法案例，更为了快速说明和应用方法而举例。02 需求定义1. 什么是需求？需是是用户在某种场景下的未被满足的期望。为什么要明确需求的定义，需求很容易被误解，这里我们要区分下用户需求和产品需求。我们的产品在未被定义之前，我们研究的需求是用户需求，我们通常也会叫作问题（没有明确的解决方案），当我们定义产品时，我们就要把用户需求转化为产品需求，提供具体的可落地的解决发难，才能实现产品。我要吃饭睡觉打豆豆，这不是需求，这种需求对于产品没有任何价值。看定义，用户需求是用户基于某种场景下的未被满足的期望，在这里提炼出需求的基本结构：用户+场景+期望。强调：需求不是独立存在的，是依附于用户+场景一起存在的。用户需求案例： 小明（用户），每天早上起床后就要赶着去上班，没有也不想在家吃早餐，但是到了公司就要工作，所以常常没有早餐吃，又饿又不健康（场景），小明又想多睡会儿又想在上班前吃上早餐（期望）2. 什么是需求分析？需求分析，就是挖掘和提炼用户需求，解决用户痛点问题，即找到用户需求，并把用户需求转为产品需求（解决方案）的过程。这里强调两点：找到用户需求解决用户问题案例： 还是小明吃早餐的案例，目前小明希望在上班前能吃上早餐这个是用户需求，只找到用户需求，没有解决方案，等于0，我们还要帮小明解决问题。如，提供早餐外卖，小明可以提前在手机上预定早餐外卖，一起床就有早餐可以吃。这是一个较完整的产品需求。03 为什么要做需求分析产品首先要满足的就是用户需求，为用户产生价值，才能创造商业价值。满足用户需求是产生商业价值的本源。04 在什么阶段做需求分析需求分析贯穿在产品整个生命周期。1. 产品概念期这个阶段做需求分析，更强调需求调研，目的是定位目标用户群，做产品定位，市场研究并确认细分产品市场。提炼产品核心功能，解决目标用户群痛点问题。 交付物：BRD需求文档。（或类似的相关的文档，如需求调研报告、市场调研报告等）2. 产品设计开发期这个阶段的需求分析，目的是要设计一个可落地的解决用户痛点，满足用户需求的产品。设计一个目标用户可用好用的产品。深层次的挖掘和分析用户，描述需求，解决问题。实现用户如何通过一步步的使用产品满足其需求。该阶段交付物：产品原型+PRD操作文档。3. 上线后-成长期上线后的需求分析，目的是验证真实产品满足真实用户需求的结果，收集用户需求，优化产品。4. 成熟运营期本阶段需求分析，目的在为产品提供更好的运营方案，制定竞争策略。让产品持续更好的更多的为企业创造商业价值。5. 产品衰退期当产品进入衰退期时，需求分析重在研究市场发展趋势，以帮助决策是调整发展战略。05 需求分析方法需求分析可以分为三大步：明确问题–拆解需求–提供解决方案。1. 明确问题明确问题之前，我们首先要从各方搜集需求，然后经过分析，提出真正的需求。需求获取渠道以下是我们常用的一手需求获取渠道：收集到的一手需求还不是真正的需求，要先进行一个清洗过程，把一些无用的无根据的站不住脚的异常的等等都过滤掉。具体过程不做介绍啦。明确问题（提出要解决的问题）这里一定要注意，提问题的标准：提出的问题要聚焦，明确、开放。不能泛，模糊。要又用户、场景、问题。还要明确该需求带来的价值。需求最终是要交换成价值的。正确的问题VS错误的问题：明确需求的价值：2. 拆解问题（需求）拆解需求指的是把已经明确的问题，从多个维度进行拆解，目的就是为了找到更合适的解决方案。 该方法是某课程老师总结的拆解方法，笔者认为非常好，非常清晰和明确的一个方法，这里直接引用。（该方法也是老师对《六顶思考帽》里的解决问题方法做的灵活应用，同时书也推荐给大家）拆解问题的5个维度：积极层面：通常可以拆解出怎么做对用户来讲可以产生更积极的情感。否定层面：通常可以拆解，即使不做什么，依然可以产生好的结果。转移层面：转移指的是不直接单独解决当前用户的问题，通过转移法，用户转移、问题转移等。拆解：把当前问题刨根问底的拆，挖掘更多的可能性、找到问题本质。脑洞：这个更多的靠灵感、经验等进行头脑风暴，补充其他维度考虑不到的地方。案例： 问题：某视频APP，用户次日留存率低于30%，需要提高次日留存率 拆解过程如下图：注意在拆解问题的时候，不要去考虑能不能实现，先去拆解一切想到的问题，最后在分析解决方案的时候再来进一步筛选。3. 提供解决方案问题拆解完后，对所有提出的问题列出解决方案，这里注意，一开始思考解决方案的时候也不要去考虑实现的可行性，尽管去提供。等所有的解决方案都列出来之后，再进行方案分析、评估、排序。06 需求管理需求管理指的是如何安排已经明确产生的需求，工作中我们通常会遇到四面八方包括产品经理自己给的需求，但是资源和精力无法让做到有求必应，我们需要去把需求做一个分类和排序，尽可能的去做性价比高的需求开发。 这里我们介绍几种方法，帮助我们做需求分类和排序。1. Kano 模型KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。Kano模型把需求分为5类：基本型需求该类需求代表的用户的核心痛点，是产品的必备功能，如果没有该功能，用户会极度不满，甚至不用你的产品。但是如果有了该功能，用户并不会对你的产品的满意度增加。如微博的发布微博功能、社交APP的聊天功能、共享单车的开锁功能等。期望型需求这类需求代表的是用户的痒点，代表的是品质，对用户来讲是最好有的功能。好比我们的生活，我们都期望我的生活是有一定品质的。拥有此功能，用户满意度会明显提升（过的还可以），没有此功能，用户满意度会明显下降，但是凑合可以用户（过得下去）。这种需求一定要去努力挖掘和分析，并做好。代表了产品的竞争优势。如社交软件的语音聊天视频功能。兴奋型需求这类需求所在暗处，用户自己都想不到的需求。拥有此功能，即便表现的并不完善或完美，用户满意度也显著提升，但即便没有此功能，用户也并不会对产品对满意度降低。如，在微信刚刚推出红包功能的时候，这是一个非常典型的兴奋型需求。无差异型需求该功能对用户来讲，是不痛不痒的需求。可用可不用，有或者没有都不会影响用户的满意度。如，我们在设计某个按钮，是20px，还是22px，是第一个还是第二个位置。无论怎么做，对用户并无明显影响。我们就尽量不要去花精力在这上面，只需要执行任意一种即可。反向型需求该类需求提供对应的功能后，用户会对产品的满意度降低。该类需求，最好不做。如，前段时间上热搜的一款监测学生上课是否集中注意力的智能科技“紧箍咒”，得到的是网友几乎一边倒的差评和抵制。Kano模型实施方法：如何评估需求属于Kano模型中的哪一类需求，我们可以实施以下方法：Kano模型问卷调研法 可以直接设计问卷调研，通过定量问卷调研得出需求属于哪一种：按照上表的格式，对每一个功能做一个的调研，充分收集用户的数据并得出结果。2. 时间管理四象限法本方法可以快速帮助我们评估需求开发的时间优先级。从紧急重要程度两个维度比较合理的帮助产品有条理的安排开发秩序，避免盲目排序。3. ICE排序法ICE排序法也是一种比较严谨科学的需求排序方法，通过从几个维度考虑给需求打分，以总分高低去排序。I（Impact）：影响范围C（confidence）：对上线效果的自信程度评估E（ease）：开发难易程度（工作量+技术难易程度）评估应用实例：本文由 @娟姐 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

一个新项目往往只有几个月的交付周期，往往给予到需求调研的时间非常少，尤其是尤其是to G类，需求调研的机会是非常难得。那么在做需求调研之前，我们可以多做些准备工作，提升需求调研的成功率，获取客户更多的信任。一、情景再现早上刚到公司，Boss发来消息——“公司现在有个新项目，客户需要做一个涉案财物管理系统，项目的资料信息发到你的邮箱，你赶紧把需求搞清楚，尽快提供一版原型去和客户确认。”这个场景是不是很熟悉，很多时候，领导就这样几句话就分配一个项目，然后催着赶紧开工。领导分配任务之后，那么我们就赶紧进入邮箱，把项目的资料下载下来，细细研究。即使提供了一些资料，我们就可以开工画原型了吗？肯定不行，在接到一个新项目之后，我们需要先做项目背景调研。切莫着急开工做原型。二、为什么要做项目背景调研在做To C端产品，首先需要做商业需求分析BRD，然后是市场分析MRD，才会进入到产品分析PRD。那么在B端产品和G端产品，业务需求复杂，如同茂密的森林，一不小心就会迷失在业务细节中，难以看到业务的全貌。导致这种情况的根本原因在于：一个行业花费了几年甚至几十年时间建立起来的业务流程与规范，我们很难用一两个星期完全消化。面对这样一个错综复杂的场景，产品经理最好的做法是循序渐进，从最粗略的项目背景，业务目标开始，然后分析业务流程，再到界面展示。所以我们首页需要对产品所服务的业务领域有一个概括性的了解。我们可以从行业背景、业务目标、问题痛点等方面进行调研。现实中，对于项目背景的调研，往往是我们产品人员容易忽略的，忽略的一个最大的风险是：我们不能很清晰准确的把握客户的期望值和建设目标，从而给项目交付带来风险。比如我之前参加的一个项目，客户的旧系统由于系统臃肿，业务配置不灵活等原型，准备淘汰他们的旧系统，并且明确指定了一个他很欣赏的新系统，这套新系统，无论是在页面风格、业务灵活性、用户体验确实都非常好，希望能够尽量复用这个新系统，在上面进行功能调整，以适配他们的业务。那当时我以为的客户期望和建设目标就是复用这套新系统已替换旧系统。当时我撸起袖子深入研究了客户推荐的系统，进入分析之后，立马就开始画原型。但是等我们提供了改造的原型设计之后，客户改变了策略，他们既没有淘汰旧系统，也没有使用指定的新系统，而是在他们的旧系统上面进行改造升级。此时我才明白，客户的公司由于业务运转目前都是通过旧系统完成的，若使用新系统，一方面短期会影响现在业务的正常运行，一方面还涉及到业务上下游的调整，所以客户真正的期望和目标是参考这个新系统，来优化他们的旧系统，而不是真的把业务切到新系统中。由于没有清晰准确的把握客户的期望值和建设目标，前期过早的做了很多无用功。所以，在开展工作之前，进入项目背景调研是非常重要的环节。项目背景，是了解用户建设该项目的动机和背后存在的痛点的关键环节，基于不同的动机，客户对系统的要求也是很大差别的。三、怎么做项目背景调研针对项目背景的调研，我们梳理的提纲如下：1. 这个项目是做什么系统首先我们需要弄清楚这个项目涉案财物管理系统是做什么，这个问题我们可以先自己在网上搜索资料，或者通过现有的资料，搞清楚这个“涉案财物管理系统”是个啥东西，有啥用。很多时候我们以为我们理解的东西就是正确的，这个时候还需要与调研对象进行一个信息的确认，以便及早的纠正方向。2. 这个项目是为谁做的什么样的目标客户会产生这种需求？每个产品都有特定的用户群体，B端产品也不例外。首先我们要搞清楚，产品到底是卖给谁？在B端和G端，花钱购买系统的人称为客户，而真正使用系统的人是最终用户，客户和最终用户可能是同一个人也可能不是同一个人。客户和用户对系统的要求是由很大差别的。一般都什么样的企业会去建设这种系统，这个该怎么了解了。如果是to B 产品，可以通过搜集的产品的竞品企业，去看这个竞品的成功案例，往往就能发现他的产品应用到了哪些企业，以及应用的大致情况如何；通过这种侧面的了解，就能让你知道，大致那些客户群存在类似的需求。如果是to G产品，那么这个信息可以通过寻找项目接口人直接明确项目的服务机构。比如这个“涉案财物管理系统”是什么样的机构会使用，经过了解，目前这个项目主要是政法委投资建设的，但是公安、检察院、法院都会使用。像to G的项目，我们还需要了解客户的组织结构。比如涉案财物管理系统，是公检法在刑事案件过程中会对涉案财物进行维护管理，而政法委是一个监管公检法的机构，由政法委投资建设这个系统，督促公检法按照工作要求进行涉案财物管理工作。3. 客户为什么要建设这个项目做C端产品时，我们习惯用“用户故事”帮助我们定义用户类型，做B端产品，同样我们可以用一个“企业/机构故事”帮助我们理清目标群体的需要。“目标客群是一家____公司，没有我们产品之前，他们是这样工作的：____，当前的工作方式出现了____的问题，因此想要借助我们的产品解决____需要，期望达到____的效果。”那么涉案财物管理系统的机构故事可以这样写：产品的目标客户是公安机关，在没有我们的产品之前，他们主要是靠人工进行登记、管理，工作繁琐、业务量大，导致容易出现管理漏洞，涉案财物被截留、挪用、调换、遗失等问题的发生，不利于管理。因此想借助我们的产品解决涉案财物管理中存在的各种问题，规范流程，提高工作效率，确保执法规范化建设工作顺利进行。通过这个企业/机构故事，我们可以定位到产品针对什么行业、什么规模的企业，然后明确这类公司的核心诉求，将来在做功能与设计的时候可以围绕着这个核心诉求展开，也是产品不断更新迭代的方向。针对to G类项目启动的背景，还需要特别考虑法律、法规的要求，以及政策的指导方针。4. 业务目标分析业务的痛点。希望通过这个系统达成的目标。短短一个企业故事，为我们后续的需求分析有很大的帮助。接下来我们还要做一道选择题帮助我们理解产品的定位。我们的产品对客户的重要性如何？生存需要：这个产品关系到公司的生存问题；核心发展需要：这个产品有利于公司提高核心生产力与竞争力；次要发展需要：这个产品对公司的生产或发展不产生重大影响，但有利于公司解决一些具体的问题，帮助公司改善非核心领域的工作，或改善核心领域的工作；锦上添花需要：有这个产品更好，没有也没太大关系，可以有其他替代解决方案；5. 项目的建设内容通过现有资料：投标书，竞品分析，得出：这个项目有哪些功能。然后，我们还在看在网上搜索，看看是否已经有别人做好的现成的“涉案财物管理系统”，很幸运，很多时候你也能搜到一大堆类似的软件，虽然只是简单的介绍，但至少让你知道了这么一个访客系统的大致包含了什么功能；——你可以理解为这是一个简单的竞品分析的过程；通过建设内容，我们大致可以锁定项目的边界范围。以便下一步围绕这些功能展示调研。6. 公司内部商业价值分析同时我们还需要明白公司为什么要承接这个项目，比如：项目是和公司最近某个战略相关吗，需要把这个项目当做标杆拓展公司业务吗？公司做这个项目的优势有哪些，是有核心技术能力，或者是这个项目是之前建设过的后期项目。新项目的建设周期要求，项目往往都是时间紧迫的，了解项目建设周期，便于提前识别风险，对项目整体把控。四、项目背景调研结果项目背景的调研，首先要找准对象，一定要想办法和对方项目发起人，主管领导进行短暂的沟通，即使只是半个小时的沟通都行，了解清楚项目建设的动机、对项目的期望值，要达成的目标，非常的关键和重要。即使是一个全新项目，当我们完成了上面这些调研之后，我们能够：在概念层面有一个认识了解，并且科普了行业的专业名词解释，不再是个业务小白。了解我们的目标客户和用户了解客户的期望和诉求了解业务的痛点，客户希望能成的目标项目的范围边界我们的优势，能够调用的资源信息本文由 @瓜子 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。

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

1 今日话题：1 今日话题：今天与大家分享的是培训需求调查的8种方法。我的小徒弟是今年的应届毕业生，目前我带着他做培训。前几天我们一起在做培训需求调查，他突然问我：“师傅，培训需求调查有那么多种方式，每次用什么方式，你是怎么选择的啊？”我反问他，是否了解这几种常用的方法和他们优缺点，他摇摇头。那么今天就让我们一起来看看这7种培训需求调查的方法。2 问卷法：问卷法是最普遍也最有效的收集资料方法，我们在使用app的时候，经常有提示框询问我们使用这个app的建议，前几年的时候，路边经常有填写调研问卷给小礼物的场景。调研问卷的成本很低，现在的企业只需要通过网络便可以开展大规模的调查。问卷法一个问题只涉及一件事，且多为打分的方式，所以种调查很难收回具体的信息，如果调查的事项过多，篇幅会很长。大规模发放的情况下，回收率也很难把握。一般问卷调查法有5个实施步骤：（1）制定调研计划。明确调研目标及任务，实施周期。（2）编制问卷。通常采用选择题和问答题的方式。比如你对本行业对新知识是否熟悉，有3个选项：非常熟悉、一般、很不熟悉；你需要何种程度的专业知识培训，有3个选项：高、种、低。（3）收集数据。这里包括发放调研问卷（表），并组织回收、整理。在这一步需要剔除无效对问卷，比如你设计的是单选，但是有人多选；或者问卷回答的不全面，一共有10个问题，他只回答了8个。（4）数据处理。我们将统计的数据、问题进行汇总、分析，客观的分析出每个类型的培训需求都有多少人需要。（5）得出结论。在这一步我们会编写出需求调研报告，并把调查结果提交给直接上级。我们的报告中要包含分发问卷的份数，回收的份数以及有效的份数。并且根据调查结果，列出哪几项培训需求比较强烈。3 访谈法：访谈法是通过与被访谈对象直接的对话，我们可以获得大量的信息。访谈法一般是在有一定培训需求方向的情况下才会使用，我们通过与培训对象的上级或者培训对象沟通，希望通过访谈进一步的对我们已有的培训需求进行确定。比如通过调查我们了解到，被培训者希望参加沟通方面的培训，但是沟通的培训有很多种类型，于是我们通过访谈法来确定，他们是需要辅导的沟通培训，还是向上级汇报为的培训。访谈法的优点是比较灵活，但他的缺点是主观性较强，需要我们的访谈者有很高的访谈技巧。如果采用访谈法，一般有以下7个操作步骤：（1）制定访谈计划。在这里我们需要确定访谈目的、准备相关资料，确定相关人员名单。被访谈者的人选直接关系到访谈的结果，所以如果是给有一定工作经验的员工进行培训，被访谈者要选择工作经验丰富的员工，或者这些员工的上级。（2）进行内部的访谈演练。在访谈练习的过程中，我们可以总结经验，发现问题后及时更正。在这一步需要确认访谈的问题，以及判断标准。（3）访谈开始。在这里我们需要介绍访谈对目的，并且营造适合交流的访谈氛围。这一部分的自我介绍和目的介绍很重要，如果员工以为你是为了对某人进行背景调查来进行访谈，或许就不会告知内心的想法。另外，如果员工很忙对时候，也不会有时间与你访谈。（4）收集数据。通过访谈我们获取了很多信息，我用到的基本工具是访谈记录表。其中的问题多为主观题为主，比如：员工特别出色的知识、技能表现在什么方面；员工特别需要学习的知识和技能有哪些。（5）访谈结束。我们与访谈对象确认我们的记录是否有问题。（6）访谈总结。整理访谈记录表，并收集归档。由于都是主观的记录，所以我们整理的时候需要小组成员一起去做。（7）访谈综合。对访谈资料进行总结，综合访谈中的发现及结论。4 现场取样法：现场取样法一般较多使用于服务性行业、生产型企业的培训需求调查（如饭店、操作工等），是通过选取培训对象现场实际工作的部分片段进行分析，以确定培训需求的一种分析方法。这种方法获取的资料十分的直观，但是成本较高，由于采样的时间有限，获取的信息也可能片面，采用的情况不是很普遍。我们一般采用的是通过拍摄或者现场的观察两种形式。在现场取样之前，我们一般会确认我们取样的维度，比如服务态度、必备工作实施情况等。然后根据录音、录像或者观察来确定被观察者的培训需求。5 观察法：观察法多用于生产型或服务性行业，是指到培训对象的实际工作岗位上去了解其工作技能、态度、表现，以及在工作中遇到的主要问题等具体情况的一种方法。通过观察法，我们可以了解到员工的实际工作环境，所取得的资料与培训需求的关联性更高。但是这种方法有可能影响到员工的正常工作，一个人在旁边看着你工作，总会感觉别扭。而且这种方法只能看到员工做了些什么，其中的逻辑并不能确定。观察法一般会有一个详细的记录，这个记录一般是以时间为轴线。比如10:00员工做了哪些工作；10:20员工又做了哪些工作。我们通过多份观察记录，由经验丰富的人员与我们一起去分析哪些方面需要进行培训。