需求调研公司

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

不管是公司安排的软件项目，还是合同项目。我们拿到一个新的软件项目，首先要做的事情就是根据现有的人力资源、技术能力、项目工期合理地制定项目管理计划。如果现有的人力资源或技术能力不能满足项目工期要求，则需要增加人员或提高人员的技术能力。项目管理计划内容可多可少，主要以自己能够管控项目开发为原则。一般说来，项目管理计划包括项目组织架构、工作分解结构、进度管理计划、需求调研计划、配置管理计划、质量管理计划。小规模的软件项目可以只有进度管理计划，进度管理计划将整个软件项目工作分解为不同的阶段，每个阶段的工作又分解为多个子工作，分解的子工作以1周以内完成为宜。进度管理计划的第一个工作任务一般是需求调研工作，需求调研工作的主要任务是调查系统需求、绘制需求模型、编写需求规格说明书。下面这张图给出了需求调研的基本过程和步骤。图 1需求调研的基本步骤需求调研的基本步骤是调查系统需求、编制事件列表、发现系统角色、编制用例模型、编制类图模型、编制界面模型、编制部署模型、最后形成需求规格说明书。需求调研的第一步是调查系统需求，调查系统需求的方法，在前面的课程我们已经讨论过了。在这里主要采用与用户的面谈方式，通过与用户的面谈，找出系统的相关事件，并写出事件列表。需求调研的第二步是依据前面给出的事件列表，归纳和抽象出系统相关角色，建立角色列表。归纳和抽象系统相关角色，要注意角色不是指具体的人和事务，而是表示人或事物在系统中所扮演的角色。需求调研的第三步是建立角色用例图，角色用例图是系统需求的功能模型，描述了角色的行为及角色间的关系。每个用例需要给出用例规约，用例规约描述了用例的用例名称、参与角色、与其它用例间的关系、前置条件、后置条件、操作流程、输入与输出数据项等内容。需求调研的第四步是根据角色和用例模型建立类图模型。一般说来，前面分析的系统角色就是系统中的对象，也称为类。类图模型描述了类的名称、属性及行为，以及类与类之间的关系。需求调研的第五步是依据角色用例和用例规约建立界面模型，需求阶段的界面模型只要给出原型就可以了，不需要考虑界面的美观性。需求界面模型可以使用PowerPoint、Axure RP等工具进行绘制。需求调研的第六步是确定系统的部署需求。部署需求主要由网络环境、硬件环境、软件环境组成的需求。网络一般采用网络拓扑图等模型，给出部署系统所需的网络环境需求；硬件环境给出部署系统所需的硬件环境需求；软件环境给出系统所需的软件支撑环境需求。最后形成完整的需求规格说明书，将前面的文字表格资料、绘制的模型、图片等内容放置到需求规格说明书中。需求调研的成果物除了需求规格说明书外，还有需求跟踪矩阵，编写需求跟踪矩阵主要目的是可以有效跟踪项目需求变更和需求实现，做到在需求和项目之间维护双向可跟踪性。跟踪需求是因为在系统研发期间，需求会由于各种各样的原因而发生变更，因此有效的管理这些需求和需求变更是很重要的，我们有必要去了解每个需求的来源以及对系统的影响。

编辑导语：对于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 协议

本文以用户研究工作人员为出发点，讲述了这一职业在职场上与专业技能上需要注意的要点。讲一个我前同事的事儿。认识他的时候，他心理学硕士刚刚毕业，开始从事用户研究。名校毕业，科研训练扎实，工作又认真努力，所以他项目上手很快，业务方对他也是赞不绝口。领导信任他，开始让他承担一些更重要、更复杂的项目。然而过了一段时间，业务方开始向他领导吐槽，抱怨他项目进度太慢，报告不能按时产出。领导很纳闷挺靠谱一个人怎么忽然就不行了，于是找他谈话；原来他自己也很痛苦很焦虑，明明已经在拼命加班了事情还是完不成。跟他深聊的时候，我慢慢意识到他遇到这种挑战的原因。虽然离开了高校，但是他仍然在按照科研人员的标准来要求自己：要求研究结论尽可能精确。为了对自己的结论有信心，他花了大量的时间收集更多的数据，做更多的分析，结果导致工作迟迟不能完成，项目最终被迫延期。这个同事的处境让我想起自己的经历。博士毕业刚参加工作，第一次绩效面谈的时候，领导给我的一条评价是“学生气太重”。在我看来，这位同事之所以遇到问题也是“学生气”结果。科学研究与用户研究没错，用户研究岗位对研究能力要求很高。从业者要掌握科学研究的方法论（问题分析-假设检验-研究结论），熟练利用科学的研究方法（问卷、访谈等），对结果做出有说服力的解读。从这个角度讲，用研工作与科学研究是非常相似的。但二者的差别也非常明显，主要是在目标和成功标准上：科学研究的目标是发现客观规律，从而能够对事物进行描述、解释和预测。用户研究也对用户相关现象进行描述、解释和预测，但公司雇佣用户研究人员的最终目的是通过这个过程为业务问题的解决提供输入，或提供最终的解决方案。这构成了用户研究（或公司里其他研究岗位）的核心目标。目标不同，成功的标准、卓越的标准也就不一样：科学研究求真，所以优秀的研究者投入大量时间让自己的理论和发现足够精确无误。而用户研究追求的是解决问题，所以一个优秀用户研究人员的结论应该在有限的时间内做到足够“有效”，也就是提供的建议或方案对于问题的解决有实际的效果。在我看来，优秀的学术训练以及个人性格的特点让同事走入了误区：在用研工作中用“精确”代替了“有效”；用“完美”代替了“效率”。针对“问题解决者”和“有效”，我们已经在别处做了讨论，这里着重说说“完美”和“效率”的问题。追求效率的根本原因：公司在有限的时间内最大化资源的价值The outcome of business operations is the harvesting of value from assets owned by a business.一个博士学位要读三到四年，不顺利的话则要更久；很多研究者可以穷其一生投入在某个研究主题或理论上。人们给予了科学研究更多更充分的时间（如果不考虑科研从业者的晋升压力），尤其是对基础研究日益看重的今天。而在商业环境中，时间是最稀缺的资源。在商业竞争中，速度对成败的重要性不言而喻。在电商行业有阿里、京东、拼多多等大佬；尤其像阿里这样庞大的企业仍能够持续保持超过40%的增速，正所谓会跳舞的大象。网易的电商业务作为后来者，在基础设施和能力上跟竞争对手差很大一截，不管是对电商和零售业务逻辑的理解上，在中后台的建设上，在对消费者的理解和洞察上，还是在产品设计的能力上。在这种竞争环境下，只有保证足够快的发展速度，才能够避免被紧追不舍的大象踩死。对于那些能够在更长期更大范围内产生价值的研究主题，社会的资金投入也是巨大的，国家、省市都会有科研基金的支持。与科研环境相比，商业环境的资金资源就显得非常稀缺。哪怕是头部的大公司，在成本上也是要精打细算的。即使是上市的大型企业也可能因为资金链断裂而被迫退市破产；对于创业企业来说，资金就更为有限，有大量的创业企业因为资金问题而失败。显然，用研需要消耗公司的资源当用研工作陷入对精确性的追求时，更多的时间和金钱就被投入来收集新的数据，做更全面的分析。这些都需要花费公司的人力、资金。发放问卷或执行访谈往往需要支付用户一定的费用；当采用外部公司进行调研时，费用的成本会更高，一份问卷的价格可能会达到近百元，一个访谈的价格更是要几百块。公司的用户资源本身也是一项稀缺资源。比如互联网公司的用研项目常常需要向用户推送或短信发送问卷。每一次对用户的打扰都可能对用户体验带来负面的影响，造成用户关闭push消息或屏蔽短信号码；更验证的情况下甚至可能造成用户的流失。反过来讲，这些触达用户的机会本来可以用来进行营销推广和商业变现。用研人员也是公司的一项稀缺资源。用研团队规模一般都不会很大，通常是几个人负责一个产品，甚至一个人负责多个产品的用研工作。由于用研工作对研究能力的要求高，用研从业者的学历水平一般也相对比较高。这样数量有限、高学历水平又高的人员被分配来解决什么问题就变得极为重要。用户研究项目的各环节往往还要花费其他人的时间，比如需求沟通流程对业务方时间的要求。尤其是在公司流程比较复杂时，从研究策划到开展可能都需要数周的时间。上诉这些不同方面的投入构成了一项研究的成本，它与研究价值的比较也就是衡量一项研究是否值得做的底线。ROI的最大化也是对用研工作的要求由于资源的稀缺性，公司里的各类经营活动都要评估ROI。营销活动是非常典型的例子，一场广告营销活动耗费大量的资金，究竟给公司带来了多大的价值，不管是在实际的成交上，还是在品牌的宣传上？所以在一些公司里会对营销活动的效果做不少调研来进行评估；也诞生了很多公司专门做广告投放效果的监测和评估，而各个广告平台（如腾讯的广点通、阿里的阿里妈妈等）也会提供相应的工具。而Facebook和Google能赚得盆满钵满也部分是因为广告投放优化算法方面的优势。回到用户研究中，用研上的投入虽然在公司的支出中占比可能不高，但也同样需要考虑ROI的问题。上述这些人力和资金本来可以花在其他地方，这也就是所谓的“机会成本”。（这可能是小公司不养用研的原因。）因此，我们会强调一定要让自己的研究结果是有效的，即有足够大的产出，同时也强调我们投入的资源是合理的，即有高的ROI/效率。完美在这里不是必须的，甚至是不提倡的。几点建议在上面提到的用研工作消耗的资源中，用研人员的有效工作时间可能是最宝贵的资源。对于从事这个行业不久的同学，我给出一下两条建议：有效工作的两条建议1. 用投资的视角来思考自己精力的使用方式估计不少同学都懂，精力管理比时间管理更重要，想想自己一脑袋浆糊加班的样子就知道了。因为对工作比较陌生，能力也有待提升，初入职场的同学们常常要工作更长时间。但精力差的时候，人反而容易出错，创造力也受限。所以，首先用精力管理代替时间管理，不鼓励加班。投资强调投入和产出，两个概念特别重要：收益和风险。比如，我会把自己的钱分散到几类投资中：余额宝这类货币基金虽然收益低，但风险也特别小，作为一个保守风格的人，我就多投一些；股票基金的风险高一些，但长期坚持的回报比较高，那也可以多投一些；个股投资需要懂行业懂公司，成为韭菜被人割的风险比较大，那就选几个自己稍懂的公司投一点。这样虽然收益不会特别大，但总体比较稳定。在工作中也可以借鉴这样的思路。对应于投资中的收益和风险，不同用研项目的价值差别很大，而项目输出有效产出的可能性也不同。要判断项目的价值，需要我们懂业务，甚至懂战略。如果自己尚不能判断，则可以多跟领导、前辈来沟通，让他们帮忙判断。有些新同学对前辈或上级有畏惧心理，完全没有必要。从项目价值和难度出发，大概有三类项目：第一类项目是常规的，自己熟悉的，产出比较有保证。这类项目做了能保证自己有持续稳定的成果，但可以慢慢压缩它们占据的时间，比如让这些项目流程化，或者产品化。第二类项目挑战大一些，比如是自己没有遇到过的问题，或者需要在方法上有所创新。这些项目对自己成长有帮助，产出对业务方的价值也可能比较大，可以多投入一些时间在这上面。第三类项目挑战很大，做到让人满意的几率比较小。最好的办法是把这类项目变成第二类项目。比如，你可以找资深的同事请教，或者求助公司外部的业内人士等。这类项目不会太多，因为领导一般也不会分配这类项目给新人。但如果遇到了，那可以多投入精力，抓住机会，有可能“一举成名”。即使做得没那么理想，也不用灰心，都是自己学习积累的过程。随着个人能力的提升，个人在上述三类项目上分配的精力比例也不断变化。好的领导也会主动去调整下属在这三类项目上的比例，帮助大家成长。2. 提升工作的效率，提高自己的professionalism如何成为一个职业的人，不少新同学在这一点上有挑战，尤其我们的教育中都没什么涉及。对于这个大话题，有两点我觉得可以优先做起来：一是要快速掌握起常用工具的高效使用方法。现在的办公软件都比较复杂，但当你掌握了一些基本技巧之后，你的使用效率往往会大幅提升。实习是获得这类技能的一个好途径。如果没有的话，要培养自己学习这类技能的能力，毕竟在工作中遇到这类新东西的情况也很多。第二点是养成良好的工作习惯。这又是一个很大的话题。上面提到积极及时与上级沟通，也是工作习惯的一部分。很多习惯其实是个人能力的一个反映。粗略来说，有几类习惯是可以不断去优化的：让内容系统化的，比如工作文档的命名、格式、存档避免风险的，比如项目过程中与业务方及时沟通风险，沟通结论是书面确认等提高效率的，比如每天早上建立日程安排，工具的设置，邮件的管理规则，工作的流程优化等如果你已经经验比较丰富，开始带人了，可以考虑以下两点学会授权前面提到三类项目在个人精力中的占比，把一些项目或项目的部分内容分配出去，是调整精力分配的一种好方法，自己则更加聚焦在那些对组织和自己更有价值的工作内容上。分配出去不是撒手不管，你需要跟进任务的进度，毕竟你是为项目最终结果负责的人。任务分配出去也不是为了让自己更轻松。相反，在分配的初期可能自己会变得更累，因为对方并不一定完全胜任这些任务，而你需要承担起一部分培养人的工作。我就曾遇到过很多次对方不靠谱，从而导致数据分析需要复核的情况。但这类投入长期来看能降低自己在任务跟进上花的时间，我认为是值得的。在团队层面，做好风险和收益的权衡上面提到的投资视角管理个人精力，我认为在团队层面也一样适用。在此不再赘述。只是作为团队leader，懂业务和懂战略的要求会更高，否则很难对项目的价值做出判断，甚至需求都聊不清楚。如果你职位更高一些，那还有最后一点建议在组织层面，减少对有效工作时长的损耗微软第三任CEO Satya Nadella 在上任之后修改了公司的使命：to empower every person and every organization on the planet to achieve more.通过更先进的工具和更好的流程使企业效率提高，这使得各个行业竞争激烈的美国出现了很多类似于微软的成功的2B企业。在组织的小环境中，员工最大的时间损耗基本是公司内部的“摩擦”。比如在部门间沟通中大家都互相扯皮，面前答应回头反悔。比如超长的超级复杂的流程严重拖慢项目速度。比如宁愿使用自己开发的差工具和系统，也不用更有效的、长期迭代优化的外部工具等等。更高的管理者在组织中也承担了赋能的任务，通过规则、流程、文化等建设和优化减少组织内部的损耗，让大家有更多的有效工作时间。用研和科研人员都使用科学的方法论，而前者可能对投入产出的要求更加迫切，这是商业社会的本质：获得的回报与创造的价值高度相关。围绕价值创造这个话题，每个用研从业者都是一个投资者，精进的路没有尽头。本文由 @益者友多闻 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

做好需求的优先级，合理利用有限的开发资源，是考验产品经理能力的一大指标。只有做好需求调研，才能在立项时从容的应对各种疑问。比如该需求要为谁解决什么问题？为什么你的需求比别人重要？需求要达到什么目的？……需求调研不足将导致产品脱离实际业务需求，造成开发资源的浪费和产品方向的偏差。本人将需求调研整理为三阶段，即需求搜集-需求挖掘-需求评估，并说明每个阶段的工作思路。注：公司产品为c2m服装定制平台，以下将结合实际工作经验及对产品的理解整理，仅供参考。需求搜集定义：无论是全新业务的探索还是已有业务的优化方案，都存在业务述求，因此需求搜集可以理解为向用户搜集业务述求。渠道：用户主动通过某个渠道表达对产品使用的不满及建议。像微博吐槽，APP评价，在线客服，产品反馈入口等方式会更适合C端用户。而B端用户（或公司内部用户），会直接向上级或产品经理反馈业务述求。原则：接近业务。产品经理未收到业务反馈往往不是意味着产品没有缺点并满足用户的所有需求，而是产品未同用户建立良好的需求沟通机制导致。用户由于思维惯性，不会主动提出业务述求。其原因可能包括：不认为当下的操作行为有何不妥；认为即使提出业务述求也得不到有效解决。此时需要产品经理去接近用户，比如说业务轮岗，种子用户访谈，数据漏斗分析等。倾听和理解。理论上所有的业务抱怨都可能提炼成一个需求，不要以自己对产品的熟悉程度去质疑用户的各种操作失误；既然这是你的用户，用户会犯错，用户会抱怨，这即使产品需优化的点。因此首先要端正自己的态度，正视业务问题，才会有去改进的动力。及时反馈。为了提高业务部门反馈的积极性，对于述求方给出回复时间点及回复结果：转化成需求/大致完成时间，需求拒绝/拒绝理由。有针对性。往往用户在描述问题时容易发散，没有方向，导致搜集了很多问题，但同需调研的需求本身有偏差。因此，针对有目的性的需求，产品经理对产品的框架有事先的认知，带有问题去咨询用户。比如，要做进销存的功能，产品经理要事先对进销存有基本的产品框架，集中同用户讨论采购入库，调拨，盘点等业务场景。需求挖掘定义将业务述求整理成需求池，即场景-用户-问题点（目标）-建议解决方案。场景：所有的用户行为都必须具化到场景，需求场景描述要尽可能的详细，这样才有利于产品设计。曾经看到地铁广告，公众号二维码置于海报中下区域，也就是用户要蹲下来才能扫到二维码。如果需求挖掘时有考虑到用户扫描二维码的场景，产品设计就会考虑二维码的位置。用户：你要清楚你为谁设计产品，不同的用户产品设计思路是不一样的。工厂操作员害怕出错，因此产品设计可以侧重强提示，二次复核，傻瓜式操作等避免出错；女生害怕计算，因此产品设计可以将口算的部分转为系统自动计算；特别是C端产品更要考虑用户画像，本文就不再展开。问题点：所有的需求是为了解决业务问题。功能上线后未解决业务问题，等于资源的浪费。解决业务问题即等同于需求目标，有利于确认需求的优先级。因此罗列出问题点，作为产品设计依据。确认需求目标，可作为上线跟踪的依据。建议解决方案：在同业务端沟通时，可能会得出初步的建议解决方案。参考该信息有利于产品设计是符合用户需求的。原则别把解决方案当需求很多时候，用户给我们讲出来的想法和要求，根本不是他们的“需求”，而是他们的一种“想要”。“需求”是用户最根本的待解决的问题，而“想要”只是用户已经帮我们想好的一些解决“需求”的办法而已，在需求调研过程中，务必要挖掘到用户的“需求”，通过我们的设计去实现用户的“需求”，而不是盲目的跟从用户的“想要”，结果被用户带到了沟里出不来。不断问为什么需求挖掘比较考验产品经理专业业务能力和事物抽象化，比如工厂的说想喝可乐，其用户需求1是解渴，需求2表达我很酷。在用户所在环境，喝可乐是财力和酷的表现，而水却被打上廉价标签。挖掘更直观的表达方式是不断的问为什么，为什么想喝可乐；为什么是可乐；每个业务点去问到最后的为什么，也能收集你想挖掘的点。需求评估定义：在判断是真实需求的前提下，需求优先级如何。一般的伪需求在需求挖掘环节不断问为什么，能得到答案。在认定是真实需求时，一般采用重要性和紧急性两个维度考虑。重要：公司战略；增加营收；降低成本；信息泄露；产品基础模块，比如电商的支付，订单，商品，库存，发货等模块等。紧急：投诉风险；资金结算；大面积影响用户等。注：不同阶段，公司对重要和紧急的领域可能会有差异，要视情况而定。比如说，公司初期增加营收，拉新等是重要的，而公司中期，降低成本，隐私泄露又开始被重视。两个维度组合如下：重要&紧急：如果这类需求多，需反思是否产品框架有问题，产品基础建设欠缺。重要&不紧急：要聚焦于这类需求，代表产品的未来，拆分版本逐步迭代，稳扎稳打。不重要&紧急：往往是临时解决方案，往往对产品没有质的提升。需要反思是过去产品迭代的问题。不重要&不紧急：尽可能的不做在大部分情况下，需求和开发资源是呈现狼多肉少的局面。因此做好需求的优先级，合理利用有限的开发资源，是考验产品经理能力的一大指标。本文由 @小余同学 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议

为统筹推进疫情防控和经济社会发展，加快推动一批先进技术成果在地方落地转化，落实科技部、财政部联合下发《关于开展“百城百园”行动的通知》要求，金华市持续深化“揭榜挂帅·全球引才”，举办“百城百园”科技成果直通车生物医药大健康专场活动。10月12日，“百城百园”科技成果直通车承办方博士科技技术转移人员成立项目服务小组，正式开展2020“百城百园”科技成果直通车金华站暨生物医药大健康活动相关工作，根据“百城百园”活动计划，项目组分为三支小分队，前往金华各区域对生物医药，医疗器械企业进行实地走访，从研发机构建立与管理、成果转化、立项与产学研管理、知识产权、科技财务、人才引进六大方面全面诊断摸排企业科技创新需求。此次三支科技小分队接连走访了浙江金华康恩贝生物制药有限公司、浙江美保龙生物技术有限公司、浙江大德药业集团有限公司、义乌市海之纳生物工程有限公司、浙江科惠医疗器械股份有限公司等三十余家企业。与企业负责人、技术人员、研发人员通过面对面座谈的形式，认真倾听企业生产经营中遇到的困难和问题，深入摸底企业现状、行业发展形式、技术工艺、新产品研发过程中存在的困惑及“卡脖子”技术。项目小组第一期共挖掘技术创新需求30余项，人才项目需求5项。浙江科惠医疗器械股份有限公司负责人谈到，企业的发展离不开外部技术力量和高端人才的支持，希望通过博士科技的牵线加强科研资源渠道的搭建，产学研相结合，共同破解发展难题，推动企业做大做强。同时，企业也会积极推进与“大院名校”等相关科研单位的合作，突破发展瓶颈，加大研发投入，增强企业核心竞争力。本次专场活动将集中走访摸排全市企业技术需求100项以上，建立科技成果直通车项目库，征集生物医药大健康领域科技成果100项以上，筛选不少于20项科技成果进行路演。前期实地走访与企业负责人面对面交流，全面系统深入地了解科技企业的生产经营、企业发展规划、生产新工艺、产品开发销售、人才技术需求、遇到的技术瓶颈等情况，掌握企业创新发展的第一手情况，找到问题抓手，为下一步“高精准对接”奠定基础。

编辑导语：一个产品的开始阶段就是产品调研，因此产品调研质量的好坏对产品来说至关重要。对产品经理来说，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协议

2B产品经理要深入了解、挖掘出客户/用户的真实需求，需要先具备一定的企业业务常识+良好的沟通引导技巧。本文作者给大家提供了三个步骤，来做用户访谈，希望能够对你有所帮助。当你打开一款2B产品的工作台时，是不是会有个困惑：工作台上一堆的功能列表，到底是从哪来的？哪个产品大神能突发奇想，设计出这么一大堆功能？这些功能到底解决了用户的哪些需求？上一篇文章《2B产品经理如何快速准确了解一家企业业务》，我们讲了如何对一家企业有个基本的了解，现在我们就可以开始对客户（买单的人）、用户（实际操作系统的人）做需求调研了。小白可能会问，为什么要大费周章地先对企业业务做一番了解？直接做需求调研不就好了吗？如果一名2B产品经理真的这么做，大概率会在调研过程中，被调研对象在心中贴上：外行领导内行的标签。一个2B产品经理不懂业务，却要去做一款2B产品，如果你是用户，是不是会心里发毛？所以，2B产品经理在需求调研前，一定要对调研内容做到心中有数。这完全不同于2C产品是为了满足个人日常生活相关的需求，只要你有点生活常识，人人都是产品经理，张口就能和用户聊需求。今天我们继续2B产品设计的第二个环节：需求调研。2B产品的需求调研方式，我个人首推通过用户访谈。就像之前我们说的2B产品注重流程，2B产品经理要了解企业业务需求，最好的方式就是通过客户/用户访谈，面对面地和用户沟通、倾听、交流。魔鬼藏在细节里。2B产品经理要深入了解、挖掘出客户/用户的真实需求，需要先具备一定的企业业务常识+良好的沟通引导技巧。你可以参考下面的步骤来做客户/用户访谈：1. 向客户（买单人）了解产品定位？为什么特意把客户和用户分开来说？2B产品的选型过程更长、更复杂，往往是先在企业内部有过多番讨论的结果。2B产品的客户和用户常常不是同一类人（这里说的客户指为产品买单的人，用户指未来产品的使用人）。客户的需求一般侧重企业战略如何落地，管理制度如何落地，产品能带来哪些额外价值？因此，2B产品经理在与客户沟通时，要有CEO思维，多从商业（通俗点就是：做生意，你关注什么）的视角去理解对方的意图。与客户访谈，有利于产品经理站在更宏观视角去理解未来产品的定位。郝志忠在《用户力》一书中提出，产品设计要先回答产品定位的问题，而产品定位从通俗上来说，要回答：做什么？做给哪些人用？做成啥样？这3个问题。2. 向用户了解应用需求与客户（买单人）了解清楚产品定义后，就可以带上准备好的调研问卷，结合上一个环节了解的企业业务信息，找到企业通讯录上的核心用户，来和用户沟通具体的应用需求了。注意：事先准备好调研问卷，能让你更从容、有针对性地进行用户访谈。调研问卷，可参照下面的思维导图作为框架：调研对象、业务角色：相当于我们在招聘网站上看到的招聘岗位、岗位职责。背景说明：让调研对象先热热身，可以让TA先比较宽泛地聊聊自己当前工作中遇到了什么问题？哪些问题希望通过产品来解决？之前是不是有使用其他产品？对新产品有什么期望？需求描述、业务过程：引导调研对象结合自己的实际工作场景，描述具体工作细节。产品经理可以初步判断哪些是产品能解决的问题？一般来说，现有单据（如在用的出差申请单）、审批流程（如根据申请人岗位判断需哪些领导审批）、业务规则（如根据申请人岗位对应差旅标准）这类可明确、有逻辑、可结构化的的内容都是产品要解决的范畴。这些都属于功能性需求。非功能性需求：2B产品用于企业生产经营活动，那么产品经理就需要多一步考虑：除了满足用户的功能性需求，是不是有哪些非功能性需求同样非常重要？上图我提到了几个常见的：（1）安全性：有的2B产品的数据就是企业的血液。对于数据泄露、丢失等问题，有的企业是零容忍。产品经理就要重视数据安全的相关方案。（2）易用性：可参考之前写的2B产品经理的用户体验，都值得再做一遍（3）稳定性：2B产品在设计时一定要尽量做到全面规划。前面说到产品定位要回答产品做什么？做给哪些人用？做成啥样？回答清楚这3个问题，2B产品的设计就不会随波逐流。这里插一句：我们日常的2C产品比较喜欢刷存在感，时不时喜欢更新个版本，很多改版只是做些小调整，比如做个页面改版。目的是让用户有新鲜感。相反，2B产品因更注重用户的操作习惯，所以应更注重稳定性，能不改则不改。白鸦之前在内部分享会上说，有赞的产品自从推出第一个版本后，就没对导航、页面布局、交互做过调整。个人认同：2B产品的每一个设计都要想清楚，不要来来回回不断调整。每一个大调整，都增加了用户的学习成本，稳定性是衡量一款2B产品设计好坏的关键指标。（4）性能：这个对一般用户比较抽象，用户一般直观感受是操作时，产品反应速度怎么样（比如打开一个页面不能超过3秒）？翻译成专业术语就是响应时间、吞吐量、并发数这些指标。（5）可扩展性：这个可理解为产品的灵活性。比如，产品是否需要为管理员提供参数配置、业务建模等高阶功能，满足业务变动、发展的需求，而不需要额外增加开发工作量。需求优先级：访谈到最后，用户可能洋洋洒洒和产品经理讲了一大堆需求，这时产品经理应要先对用户的需求做一轮概括复述（目的是确认自己是不是有抓住用户需求的核心），然后可以适当引导用户说出其中哪些需求的优先级最高（这是在为后续的产品需求优先级做准备），适当地收敛、聚焦核心需求。3. 提供、确认需求调研报告前面我们和客户/用户斗智斗勇地展开了一场场的用户访谈，最终还要通过一个产出物-需求调研报告，让客户/用户了解我们对其需求的理解程度。大家互相做到知己知彼，才能在未来的产品设计、开发中不会出现需求理解错误的尴尬局面。需求调研报告的内容需包含前面的2类需求调研内容，需求调研报告的模板可以参照上面的思维导图。需求调研报告这类动则几十、上百页的文档，如果直接发给客户确认，往往会石沉大海。这有两方面原因：一方面，需求调研报告主要就是复述客户的实际业务和期望解决的问题，并无多少新意，难以引起客户仔细阅读的兴趣。另一方面，人们对这种几十页的正式文本，往往拿起来就有恐惧感，文字阅读本身是反人性。建议解决方案：3.1 向调研对象现场讲解主业务流程尽量用一幅流程图讲清楚被调用对象的主业务流程，个别需要特别说明的子流程，可以补充说明。建议通过会议的方式，现场向用户演示、确认，因为这个过程可能会有不少思想碰撞，现场的效果最好。主业务流程图如下：主业务流程是后续产品设计的主轴，我们可以把它视为未来产品的框架，一旦理解有误，直接影响后续的产品设计、开发。3.2 将报告化整为零地确认。在工作中，我们会遇到一个棘手问题：文档到底应该按用户为对象来划分，还是应该按业务流程为对象来划分。我的看法是：按业务流程来划分。因为任何一个用户在一条业务流程中，都只参与其中一部分。以业务流程为对象来划分，一方面可保持业务流程完整性。所有与该业务流程相关的人，可看到整条业务流程的完整信息，不会出现疏漏。另一方面可减少文档内容的冗余。如果以用户为对象，不同用户在一条业务流程中存在上、下游关系，描述业务时既得先说明TA的上游用户需做完什么（类似前置条件），又得说明TA做完后的后续流程是什么？导致描述不同用户的流程内容时，会出现很多重复内容。举例，一条业务流程有A,B 2个用户按顺序来一起完成。在描述A用户负责的业务内容时，需要说明A用户的后续流程内容。这个刚好就是B用户负责内容的前置条件。通过分开确认不同的业务流程，可以降低确认难度。做完上面的3步，2B产品的需求调研就算完成了。到这里，我们已经理解了调研对象的详细需求，接下来，我们就可以进入需求分析环节了。小结今天我们讲了需求调研时，要做的3件事：向客户（买单人）了解产品定位？向用户了解应用需求；提供、确认需求调研报告。你也可以上手去试试，希望可以帮到你。本文由 @追梦人 原创发布于人人都是产品经理，未经许可，禁止转载。题图来自 Unsplash，基于CC0协议

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