需求调研计划

需求调研分析是产品经理人员常常去做的事情，用户调查的方法多种多样。然而，怎样提高用户调查的有效性却是个值得思考的问题，网上有很多提供调查方法的文章和理论似乎并没有系统完整地阐述如何进行用户调查，那么用户调查究竟应该怎么做呢？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、潜意识地通过产品人员对真实工作场景的感同身受而提出更加合理的解决方案，无形需求是指产品人员对业务的深刻理解和用户心理去构思出用户无法想象的解决方案。因此在经过调查研究之后需要归纳和总结并大胆的提出设想，再去不断的进行实践和验证。并且，通过研究用户的想法，可以使产品人员了解用户为什么提出这样的需求，基于什么样的业务和心理前提，这样的需求是否值得响应等等，对需求分析有明确的指导意义。用户研究可以从不同的用户得到不同的观点，但产品不能追求满足所有人的需求，产品有自己的特点和定位。

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

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

本文总结了项目调研的各项环节以及其中的要点，希望能给你带来启发，enjoy~一、调研准备甲方行业情况的了解、原网站的分析、同类网站的浏览。要初步明确项目的重点和难点，以及客户可能关注的地方，为实际调研做好准备。调研准备工作应对现有网站及类似项目案例进行分析。项目启动后3个工作日内，项目经理应编制好《项目调研计划》和《项目初步需求调研表》发送给用户，并与用户沟通确认调研计划。准备好初步栏目结构表，便于现场调研时沟通，可参考招标书、投标书、建设方案等中的栏目结构，或同类网站。产出文档：大型项目《项目启动介绍》PPT、《项目调研计划》、《项目初步需求调研表》、初步《栏目结构表》。二、启动阶段结束产生的结果和标志项目经理调研计划及调研文档准备完成，通知客户调研日程，发送《项目初步需求调研表》给用户做前期准备。三、调研阶段需求调研阶段，主要是为了与用户建立联系，弄清项目建设要求，包括：软硬件环境、页面设计、网站栏目、信息审核流程、互动办理流程、用户权限、数据移植、定制开发、上线时间要求等，并制定、确认项目需求说明书和项目计划，为下一步页面设计和实施工作打下基础。1. 调研的参与人员调研人员，一般是项目经理，有定制开发需求的，项目经理需向开发总监/开发副总协调开发人员参与调研。有些项目根据客户要求，还需要美工参与调研。根据项目规模大小，调研人员数量相对适当增减。到达客户处，项目经理需和客户负责人简单介绍一下调研计划（日程安排）及调研人员。2. 现场（调研）启动会大型项目应在项目现场召开项目（调研）启动会。参会项目组人员配备应尽量齐整（如美工、开发、实施），销售一般需要出席。根据情况可考虑协调公司高管出席。项目经理应准备并介绍《项目启动介绍》PPT（含：项目组人员介绍）。启动会完成后，可根据项目调研实际安排，部分人员逐步撤回公司配合后续工作。产出文档：《项目现场启动会会议纪要》。3. 调研的主要内容（1）摸清客户对项目的大体日程要求。（2）根据《项目需求调研表》，同时结合项目本身的内容，如合同、招标书、网站评测标准、客户的实际要求等进行调研并详细记录，并填写完成《需求调研检查单》，完成后一同提交至“OA-项目跟踪”中。（3）对于已有产品模块，通常不需要调研（一般销售前期会演示过产品）。如果客户不了解产品，可安排给用户演示产品，来获取需求。（4）在调研的过程中，客户方会主持召开主题不同的若干次会议。项目经理需要明白以自己为主，以《项目需求调研表》为基本框架，在若干次会议中涵盖《项目需求调研表》所列要点，同时深刻理解客户意图，抓住客户主要关注什么问题和想解决什么问题。如果客户没有主动开会的迹象，或者不知道如何配合我们进行调研，项目经理要主动建议客户分主题进行开会讨论，如日程安排方面、软硬件网络方面、定制开发需求方面、页面设计和栏目结构方面等。如页面设计需多层领导确认，或无法直接与最终确认人沟通，因建议客户采用“首页设计评审会”的方式来确定页面，并明确会议时间编制到计划中。数据移植工作非常重要，用户应提供原数据备份和数据表字段关系说明文档，便于移植。如用户无法提供，则需要签字确认《移植数据风险确认单》。对于定制开发需求方面，特别是较复杂的需求，希望由开发人员全程参与，此点极为重要。部分需求可能无法一次调研清楚，可安排在页面设计阶段过程中继续。如果是产品销售（实施型）项目，用户提出产品定制开发需求，因采用以下处理方式：第一步：先了解用户需求的真实原因，是否能在产品现有功能上变通实现。第二步：如果不行，委婉告知用户目前产品还不支持此功能，如果本次项目中需要定制开发来实现，会涉及一些开发费用（可以评估工作量后由销售来沟通），或者我们可将需求提交产品开发部门，看是否能加入到下一版本中开发。不影响正常使用、网站上线等需求，尽量沟通放入到下一版本开发实现（一般为3个月），签订需求变更单或需求确认单，并注明此需求不影响上线和验收。第三步：若用户坚持需要在本次项目中免费开发、确实影响系统正常使用或项目验收的，则应公司内部讨论后再答复用户。项目经理在调研结束后填写《项目-组件清单》，项目经理组织《项目-组件清单》沟通会，确认项目中采用的标准和组件。说明：计划编制前至少需明确80%-90%的项目需求，页面设计全部确认前项目需求应全部确定，或双方签备忘约定未定需求不作为本项目验收依据，否则不能开展实施工作，考虑项目暂停并撤离资源。产出文档：《用户项目组人员联系表》、《项目-组件清单》、《项目需求调研表》、《需求调研检查单》、《移植数据风险确认单》可选。4. 项目软件需求说明书和项目计划的编制（1）项目软件需求说明书项目调研结束后，由项目经理根据调研时在《项目需求调研表》中记录的具体需求，分类整理到“项目软件需求说明书”相应版块中,完成“项目软件需求说明书”的撰写，并由部门经理、项目总监审核后发给客户确认。针对部分未明确的需求、待确定的方案、超范围需求、项目风险等、应该在项目开工会上面进行讨论确定后，整理到“项目软件需求说明书”中。（2）项目计划如客户需要，可先给出项目计划的初稿（可按阶段划分的初步计划）。项目正式计划应在调研完成后5个工作日以内，由项目经理编制完成，部门经理、项目总监审核后提交DMS，并发给客户确认（发送给客户的项目计划，应该导出html或打印成PDF格式，便于客户查看）。注意事项：编制计划时，应考虑到多任务的并行，页面设计、系统产品部署、信息移植测试、定制开发应安排并行。编制计划时，应考虑用户确认时可能存在的修改、内部审核流程等工作冗余量。有定制内容的定制开发计划，开发完成时间一般应按项目要求在系统试运行前完成开发测试工作，最迟在网站/系统正式切换前必须开发测试完成。项目计划确认时，应与用户沟通解释计划安排，得到用户签字确认。项目计划的编制使用MS Project Professional2010。原则上，立项后15个工作日内应完成项目计划的编制与评审工作。若未完成项目计划活动就需提前实施项目，则必须提交《特批申请表》经分管领导批准后才能执行。但项目组必须在半个月内按要求补齐相关计划内容。产出文档：《项目软件需求说明书》、《特批申请表》、《项目进度计划.mpp》、《项目进度计划.pdf》、《项目计划和项目需求确认函》5. 项目风险管理报告编制大型项目调研结束后，项目经理应该根据项目调研实际情况，结合“风险管理库”中的风险经验，编制“项目风险管理报告”，并在项目开工会上进行讨论确定，最终与项目软件需求说明书、项目计划一同提交部门经理、项目总监审核。项目经理对项目风险进行管理，采取有效措施化解风险。同时，项目经理每周更新风险管理报告，与项目周报同时提交。产出文档：《项目风险管理报告》6.项目开工会前的准备针对大型项目（或项目经理觉得有必要的中小型项目），应召开项目开工会：调研结束后，项目经理需召开项目开工会。会议时间由项目经理决定。项目经理通知项目组全体成员在某时召开会议，必要时可通知分管领导参加。项目经理准备好调研需求、调研成果等相关文档资料，主持会议并和项目组成员讨论项目计划执行。7. 开工会参加人员项目经理、项目组成员，必要时通知分管领导参加。项目经理可以根据项目情况，邀请拥有同类项目经验的项目、美工、开发、售前、部门主管、其他业务或技术专家等人员参加。8. 开工会的会议内容要点项目调研情况沟通。项目范围讨论并确定。项目进度（计划）讨论并确定。硬件需求情况讨论并确定。软件需求的讨论并确定。外购软硬件的讨论并确定。网站结构及页面设计要求的讨论并确定。明确销售人员的承诺。项目风险及缓解措施的讨论并确定。要做会议记录，并在会后提交到OA的“项目跟踪”库中。产出文档：《项目开工会会议纪要》。9.“项目开工会”的几点说明“项目开工会”和“项目启动会”的区别为：前者时间点为“项目调研后”，目的为项目计划和需求内部讨论和明确，项目工作展开。后者时间点为“项目调研前”，目的为“项目调研”的准备和讨论。“项目开工会”和“项目计划和项目软件需求说明书”的关系：后者需要在前者中进行内部讨论和明确，确定后通过审核，并提交客户。“项目开工会”的形式，不要拘泥于会议形式，也可通过RTX、微信、YY语音等网络方式进行。10. 项目调研/项目开工会结束产生的结果和标志“项目计划”确定。“项目软件需求说明书” 确定。“项目软件需求说明书”、“项目计划”为里程碑文档。以上两个文档完成后需发给客户进行签字确认。文档签字确认后才可进行除“页面设计”以外的工作。本文由 @空杯前行 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

需求调研是产品经理的重要的一项工作内容。而对B端产品经理说，做一款新产品的话，就不可避免接触一个全新业务领域，那么面对全然陌生的业务，产品经理又该怎么捕捉到有效需求呢？做好需求调研呢？需求调研，是产品经理最基本的一项工作。那么需求调研难吗？也许会有声音说：没有那么难吧，就是跟用户访谈，聊聊他们的想法，再站在用户的角度，利用同理心去体会他们的感受，那么多种调研方法总有一种适合你。我想其实也没有想象的那么简单，尤其是面对业务专业性较强B端的产品。作为产品经理，我们不断去挖掘并解决用户的痛点，为他们的方方面面带来便利。然而在我们的日常工作中，是不是也有这样一些痛点呢？用户总是不能清晰的表达自己的想法，不知道自己想要什么，看到成型的产品，到处都要改，我太难了…这块业务，我完全不了解，跟用户沟通的时候，跟他探讨业务流程时，他也只能说一半，我没办法规划产品蓝图，老板还骂我没能力，什么都搞不清楚，我怎么那么难呢…B端产品，通常业务性较强，涉及的用户角色多，其需求调研也更为复杂。做C端产品的调研时，我们可以把自己当成用户去思考；而作为B端产品经理，若缺乏了相应的行业及业务知识，则很难设身处地的去体会用户的真实感受。当初入某全新业务领域时，作为业务小白的我们，要去调研的用户需求，就会难上加难。新进某业务领域，作为业务小白的我们，若遇上能清晰表达业务流程，倾述自己的工作痛点及想法的调研对象，那是难能可贵。遇上不能完整表达，问一句回一句的调研对象，则是常态。（内心OS：否则咱们存在的价值在哪儿？）那么，遇到这种情形，肿么办呢？除了咱们日常会提前百度了解一些基本情况外，咱们还可以尝试做一下这些方法，说不定事半功倍哦：一、调研该公司对应业务领域关联产品01 提前了解该公司所属行业情况提前了解该公司所属行业，通过行业报告等了解行业规模、核心价值链及该公司在该行业的发展情况与龙头企业的差距等信息。通过政策信息，了解行业导向、行业规则、行业发展等信息。若是上市企业，则可通过年报信息等，了解该公司信息化建设投入的比例、及投入高的业务部分。02 提前了解该公司产品矩阵在调研前，我们还可以了解该公司对应业务领域已经使用的关联产品，便于我们分析理解，用户的哪些需求已被满足，哪些尚未满足。在调研时，也可以侧面了解其他关联产品的试用情况体验等，便于挖掘潜在需求及了解用户的一些特性。同时，若涉及与其他产品对接，我们可以大致了解我们需要做些什么方案等。避免用户在沟通过程中，提及一些信息，自己毫不了解，沟通出现障碍，引起用户对咱们专业度的质疑，从而也会影响调研质量。03 提前了解行业同类产品情况提前调研行业相关产品的情况，收集起各自产品的优缺点，用户反馈，使用的企业信息等。可以了解市场通用解决方案，同时加强对业务主流程的理解。做好准备工作，是产品经理专业的表现，让调研对象安心，才能更好的表达真实述求。二、阅读岗位职责说明书及工作作业文件01 岗位职责说明书岗位职责说明书看似很寻常，里面全包含了不少的信息。职责范围：可以清楚该业务领域相关的岗位（角色），明确调研对象及各自角色行政关系：可以了解现有业务流程的审核关系，清楚各调研角色的权限范围及其调研有效性。在调研前，阅读岗位职责说明书，可以帮助我们制定调研计划，明确我们调研的对象（包含哪些岗位及各自权限），了解现有业务流程的流转关系。02 工作作业文件工作作业文件里面含有工作相关的指导。尤其需要注意的是关于工作的具体步骤、工作应达到的标准、工作的注意事项信息。工作的具体步骤：也就是公司现有业务流程，帮助我们现有业务流程有一个了解，清楚业务的各个环节及涉及岗位，便于调研时，找准对的人，调研对的事。也避免因不了解业务而无法完整调研业务流程，收集的信息不完整，不对称性等。工作的标准信息：即是工作完成的判定标准，这也对应了未来产品的最低标准信息。这可以帮助我们在调研过程中，针对性了解达成标准的情况及难点的原因等信息。避免因为不了解业务标准，对产品的需求遗漏。工作的注意事项：也有可能是未来产品的痛点，在调研中也是需要关注的地方，需要细化了解注意事项的一些原因等，在产品设计中是否有更好的方案规避风险。在调研前，阅读工作作业文件，可以初步的了解我们调研的业务大致的工作流程，及工作要求等信息，在调研时，用户信息不完整时，可根据了解的情况引导回忆，补充信息，避免了因自己不了解业务流程，用户回答不完整，而调研不清晰的尴尬。所谓“知己知彼百战百胜”，先了解对方，再运用同理心，更容易获得用户的信赖哦。三、不同角色（岗位）交替调研调研B端产品的时候，业务性较强，而用户往往又很难以将信息全面讲述，我们缺乏很强的业务背景，同理心的方法在初入业务时，使用起来没那么顺畅，我们要避免调研的需求是大众的，而不是独特个性化的。01 同一岗位：求同存异我们可以多调研几个人，提取调研的共性需求，对于差异化需求，我们可以在调研其他人时，不断验证。避免出现听取个别人的个性化需求，而不是大众化需求，那么产品的价值就大打折扣，说不定还有影响其他人正常使用的风险哦。刚好调研到一个经常出差的用户，他希望更多的移动化应用，而同岗位80%以上的用户多为办公室办公。那么重PC端还是移动端显而易见。02 不同岗位：平衡关系我们可以通过调研不同岗位，从各岗位的角度来考量整体工作流程，避免出现只考虑了A角色的快速需求，而忽略了B角色质量需求。产品经理要做好平衡，尤其是B端产品经理，管理者和员工的述求容易出现矛盾的现象——员工希望工作时间灵活，不想考勤打卡，管理者希望上班时间可控，希望考勤打卡。平衡好两者的关系，才能让员工使用，让管理者满意。否则满足管理者诉求，员工不使用，那产品也难以真正存活。若只考虑员工诉求，那么管理者的满意度则会直线下降。（PS：现在那么多无感人脸考勤，他不香吗？）作为产品经理的我们，容易吗？不，我们太难了。2019年，我们太难了。2020年的开始，远程调研，我们难上加难。我相信这些是挑战，也是机遇。作为产品经理，整天解决别人的痛点，偶尔也解决一下自己的痛点吧，希望以上的方法能对同为进入全新业务领域的B端产品经理有些作用。也欢迎大家一些交流探讨一些好的方法，共同成长进步。本文由 @南枫 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自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 协议

本文以车销业务为例，向我们分享了B端项目需求调研的前中后期的工作内容以及注意要点。前言有段时间整个产品团队频繁支撑SFA项目，但需求调研普遍存在一些问题，导致PRD质量不高。团队成员基本是内部转岗过来的，对B端需求调研的方法论多有不足。故结合过往经验，参考《软件需求开发最佳实践-基于模型驱动的需求开发过程》一书，以车销业务为例做此分享。调研前基础捕获既然是去项目进行调研，再不济也知道甲方客户名称。有了客户名称，基本能获取到以下方面的资料：主营业务，以及所属行业在行业中的地位经营的产品，以及对应特性资本构成组织架构（尤其是营销组织）营销渠道下面以益力多为例，讲一下获取信息的途径。通过启信宝、天眼察、企查查等网站，可以找到益力多的信息。经营业务包括进口、乳制品、保健品等。保健品，就可能有溯源的诉求（主要怕伪劣产品吃出人命）。公司的相关信息，还可通过官网得到。从官网首页导航栏中，很容易找到“乳酸局巨头”这个信息。另外，官网显示的产品信息中只有低糖（蓝色装）和正常（红色装）两种。典型的大单品模式，一如红牛定义了牛磺酸功能性饮料。益力多从港台进驻，定义了大陆的乳酸菌饮料。股权穿透图显示株式会社Yakult本社控股50%，香港益力多控股35%，养乐多10%。看起来似乎是日资+港资+中资，但深追一下发现不那么简单。追溯历史，Yakult是日本企业，先后进入港台。香港是粤语音译为益力多，台湾则普通话音译为养乐多。2001年左右从香港进入华南地区，成立广州益力多，覆盖华南及海南。2年后在上海设立养乐多公司，覆盖大陆其他地区。所以，日资无误，控股占比相当高。日资企业的特点不用说了，什么部长、课（科）长之类的岗位是必备了。然后日资注重上下级关系，严格的业务流程&一堆审批流是必须的。组织架构是比较难从网络上获取到，基本上是用“公司名称+组织架构”在百度文库中查找。益力多没有，康师傅这类倒是有。营销渠道也是非常难获取到的，用“公司名称+渠道”可以尝试在百度中查找。益力多找不到，同为乳制品的蒙牛有。进阶捕获这一块因企业、项目而异，因为各个企业的营销玩法不一样，各个项目的立项方式也有区别。整体来说，就是从营销线和实施线获取资料。营销线的资料包括：售前报告合同（细化拆解为部署方式、三方对接系统和SOW，但部分合同SOW几乎等于没有）实施线的资料包括：计划交付版本（Base的标准产品版本）项目计划（细化拆解整体计划排期和调研计划）负责模块（极少单兵作战，需要分工合作）需求规范（交付物以及对应规范，根据项目等级有个内部规范。调研过程中，再和甲方确认）这些资料的捕获，就靠自己发挥才能了。部分信息很敏感（如合同金额），企业内部不让随意传阅，可以要求仅截取部分信息。实在没有办法，可以尝试让上级协助。以售前报告为例，可能从该项目的销售、售前或者PMO（部分项目可能尚未走完立项流程）那边获取。一般售前报告会有Base产品模块的客户诉求描述，并且会突出某部分和现有产品有差距，这就是我们要的关键信息。再以调研计划为例，可能从销售、售前和项目经理处获取。但是初步的调研计划很粗，通常都是项目经理。一方面调研完成时间根本不可能（Deadline倒排法万岁），另一方面调研的顺序等都不符合你的做事方式。建议立刻和项目经理沟通，看看能否调整（只能调调研先后顺序，deadline是红线）。另外，根据调研计划和SOW，提前整理出调研准备物，让甲方项目团队提前启动，参与部分调研工作。举个例子，需要甲方先提供好营销组织架构、角色清单、主数据相关字段&审批、接口文档、关键表单信息和报表样式。高阶捕获准备一份调研问卷（Base交付版本产品能力），让甲方先进行填写，如“考勤是否包含内勤人员的管理”、“内勤人员打卡，是否要基于定位进行检查，如距离办公楼100米内”。准备一份计划交付版本的产品功能清单，项目的功能清单将基于这份，进行裁剪和新增。充分了解产品的内部逻辑，特别是牵一发而动全身的主数据关联。举个例子，终端的某个字段，标准产品里面是必填非空的。但这个项目不需要，那么这个字段不能被删除的，要给个默认值才能正常往下跑，并且后续功能都会受到影响（页面都要隐藏掉这个字段）。充分了解PaaS能力（无PaaS的就多储备点技术吧），能衡量改动的代价。客户提出诉求（一般已经是具体的UI、UE层面），先判断需求是什么。为达到目标，是否有更低成本的方式。又或者，是否有更通用的方式，为后续该功能点产品化做准备。最后，是对竞品进行捕获。现有项目基本是两种：替换已有系统；新上系统。一般1的话，能提前拿到UAT环境，进去看看能知己知彼。2的话，大部分项目公开招标。招标过程中基本试用或POC过，客户一定是想要最优秀的体验。所以会存在某个功能对方有，我们也要。又或者某个功能别人的好用，你改一改这种。如果能借机能拿到竞品的环境，就是很好的竞品分析机会，也能提前准备。举个例子，以下是随便找的车销解决方案，可以看出大体流程和业务支撑能力。调研中整体方法三字诀——问听记。刚接触调研，可能觉得记是最困难的。一般带新人，也是让他从记开始。客户讲了很多，到底记什么。客户讲的很快，记不过来等等。建议开始调研的时候带上纸笔，这种时候写字比反而可能比打字快。然后可以开启录音，记不清的（先记录个时间）可以回去再听。经历个一两次，会知道问是最困难的。调研的过程，基本就是一问一答，基于已有的知识和听到甲方的回答进行提问。整体的节奏被提问人员控制，只有自己感觉获取足够多的信息，能将业务流程串联起来，足够输出需求规格，才会停止发问。建议在问完一个大的问题后，提出归纳类问题“那我说下我目前关于X的理解，看看对不对”。这样才能确保你的信息是足够的，且甲乙双方的认知是统一的。这里要特别强调下——少一点套路。B端调研往往，过于期望“引导”客户。无论你在这行混了多少年，奋斗在企业营销一线的才是专家。即便同行业规模类似的企业，渠道的模式和具体的玩法上都会有差异。所以不要尝试从业务合理性上去否决诉求，最多只能是技术代价比较高（也有先有技术无法实现的，请直接否决掉）。能做的引导，是保证实现目标的前提下，往现有产品靠拢，选择简单的实现方式。总体捕获的方法，是5W1H分析法。这个是很成熟的方法不做展开，简介如下：需求调研过程中，往往会出现甲方问诸如“客户列表页面，投放冰柜的要有标签或Icon区分出来”这种问题。这其实是跨阶段了，需求调研阶段要解决的是业务是什么，为什么这么做，怎么协作完成。怎么设计UI页面，那是后面原型验证&解决方案阶段的事情。遇到这种情况，调研人员不能简单考虑可行性，要先问自己“为什么要区分，不区分有什么影响吗？为什么在这里区分，是不是可以在其他地方区分？”。如果自己无法回答，要问清楚为止，再给出自己的方案进行协商。如果可以回答，倒是可以简单的说“OK，这个我们到时候会有的”。业务捕获业务捕获分为三块，分别是组织架构、业务架构和业务实务。这里面有非常繁杂的逻辑，就列一些要点大纲，不做展开。先讲组织架构，这个基本上最核心的。而绝大部分人员脑海中，组织结构图就是一棵树。导致甲方给的资料是这样，乙方提供的系统也是如此。实际在营销CRM系统中，至少要被拆分为两棵树。一颗是企业的机构树，企业下面分了多少个部门。另一颗是各部门的树，继续分拆。这样能实现，财务部老总看到所有营销部门的销售数据，财务部某个财务主管看到营销部南方战区的销售数据。组织架构基本和权限设计绑定，是CRM系统的基石，要仔细考虑。然后是业务架构，细分为部门业务和岗位设置。关于部门业务，需要注意以下几点：哪些部门和项目相关这些部门各自分管哪一块，怎么考核对照的职责是否都在系统上落实，工作流全部跑通了解推力和阻力，尽量让每个部门都有所获益各组织节点，部门设置是否一致。或者整体职责是否一致，只是有所合并拆分（最怕遗漏了某个部门，而且这个部分流程全部特殊）关于岗位设置，从下述的几个方面提问：岗位的大概目标，考核的大概方法（KPI）岗位间的协作和上下级关系哪些岗位需要对外（区分内外勤人员）哪些岗位会启动新流程各层次岗位是否能统一是否出现一人多岗的情况（业务人员兼主管是很常见的）是否已有内部系统编码，领导是否要显示最前面这里面，强调下岗位的问题。如果一人多岗，会影响整体系统的设计，包括权限那块。技术捕获技术捕获，主要是技术层面的诉求，也存在很大的风险。遗留系统方面，注意以下三点：是否并存，并存到何时，职责切分能否替代，替代节奏和方案数据能否迁移，迁移方案外部系统方面，注意以下4点：是否并存能否替代接口数据剩下的是一些非功能性需求，一般有：可靠性可用性（注意体验）有效性可移植性调研汇报调研节奏普遍较快，密集的1-2周。调研人员每天晚上就是写会议纪要以及跟进问题，很少时间进行需求设计。再加上项目人员一般设计能力有限（大部分项目经理是axure略懂而已），需要请求总部资源，调研结束后一般就回总部。然后1-2周进行需求设计输出原型，项目经理配合产品出解决方案。但是这个阶段有个空窗期，且搜集信息未得到确认。最好联系甲方项目经理，组织部分干系人，进行需求调研汇报。汇报的内容主要包含：组织架构图分部门的岗责清单（Excel）重点业务流程&审批流程梳理（Visio）核心业务原型图（axure）需求开发需求分析需求分析的过程，大部分是客户无感知的，只能体现在最终的输出物中。我个人认为主要分为产品（含PaaS）、业务和报表三块。产品需要考虑：现有的PaaS配置能力标准产品逻辑（标准产品已有能力要补充到需求规格中）公共需求的抽象（分页、导入导出等）业务需要考虑：流程和分支节点事件触发（时间or操作）特殊字段维护（如订单类型，是通用字典维护，还是专用页面维护，或者写入数据库不提供UI界面维护，甚至直接代码写死）报表需要考虑：周期（日报、周报、月报）样式（动态列头？）明细流水统计抽取历史数据处理性能在需求分析过程中，有很重要的一个点，就是给需求排优先级，尝试切分部分需求。这个在立项时候甲乙双方就有约定，但调研过程往往有变数。所以需要基于调研情况，重新排优先级，切分阶段。一般都会分成两期上，一期先上某个渠道，搭建好基础。需求的优先级，基本上对内不对外。即便一期的内容，乙方内部也是要排优先级的。每一期的功能清单，都不包含优先级。最终计划怎么排，哪些功能可以如期上，乙方内部要心里有数。而功能清单是全量的，一般附带在需求规格中。但是会加上标注，区分每一期的内容。这个功能清单基本是页面级别的，颗粒度比较粗。业务解决方案售前阶段已有解决方案，是比较靠近标准产品和行业的。而业务解决方案则是落地，贴近企业实务。基本上，是调研汇报内容的总结和升华。部分项目中，这个由项目经理编写，产品做辅助支撑。产品需要提供各个业务的流程图和设计原型，匹配业务诉求。另外部分重点项目，这个由产品独立解决。这种方案有点偏咨询，除了本次调研的业务还涉及其他的相关系统。要基于行业营销信息化的认知，去构建大营销系统的蓝图。所以什么AI、数据中台，统统都上。原型验证基本上是和业务解决方案同时开始的，业务解决方案中包含重点业务的原型图。一旦业务解决方案得到认可，就开始细致的原型验证阶段。这个阶段客户会开始看UE，原型的改动非常多。举个例子，B端是非常喜欢单据式布局的。一方面是使用习惯，另一方面是单据布局直观紧凑。尤其是APP端，经常出现客户选择表格布局替代卡片布局的情况。需求规格说明书CMMI的定义中，交付物包含用户需求规格说明书和产品需求规格说明书。实际项目中的需求规格说明书，基本上是用户需求规格说明书。这是常态，只有基于业务的描述才能和甲方进行确认。但很多研发是没有业务背景的，看这份用户需求很难直接进行概要设计。基于成本考虑，部分细节会一并在这份用户需求规格上。所以，我们看到的项目的需求规格，大部分时候是四不像的大杂烩。一般包含：用户需求规格说明书+字段细分说明（部分会省略）+接口说明+状态流程说明（审批流、订单业务流等）。却又缺少了关键的需求建模信息（主要是领域建模），研发要频繁的找产品问业务，才能进行概要设计。项目的需求规格，基本上是和原型同步启动的。但我个人建议是原型验证后，再贴原型图。最好文档基本确认完成，再贴原型图。期间原型图可以生成html打包，邮件给甲方查阅。不这么做，就是以下的情况：以会议纪要的形式记录改动点，晚上回去后要先原型。原型改好要截图，贴到PRD。但经常出现，原型图和PRD字段不匹配。以屏幕扩展的方式投屏，客户要修改的，现场标记或者改好。回去匆忙改原型，准备后面的原型验证。后面再补PRD，很容易造成遗漏（因为是密集的原型验证，这期间客户不看PRD，导致PRD和原型脱节）。原型验证完成，开始评审PRD。开启审阅+批注后，打开和保存文档不是一般的卡（4G内存还能怎样）补充说明：产品需求规格中，需求建模主要包含用例图（内部WBS拆解够细，可不出）、类图（可简化为ER图）、序列图（可简化为活动图）、状态图。以订单领域为例：用例图，订单的所有用例，如查看查询、新增、编辑、导入、导出、审核、发货、收货类图，订单类的成员名和字段类型乃至长度，以及审批单、发货单、送货单、收货单等附属单据信息。序列图，订单的全流转过程。状态图，订单的先后状态和触发状态变更的操作PS：将近一年前的PPT，拿出来分享。从输出倒逼输入，真的是很痛苦，各位将就下。作者：道·术 ，邮箱：olivercan.wunban@foxmail.com本文由 @道·术 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash ，基于 CC0 协议

需求调研的重要性，不言而喻。项目成功的关键往往取决于项目需求调研，需求人员如果能够把用户的意图摸清楚，而且能把范围控制下来，项目已经成功一半。不少的项目失败的原因就是需求延伸，最后成本无法控制，也没有让用户满意。结合多年的需求调研经验，给大家分享一些需求调研的技巧，希望对大家有帮助。四要做好调研准备不打无准备的仗，不管是大项目还是小项目，需求调研是我们第一次深入的接触客户，需求调研的目的是为了更好的了解用户需求，同时取得客户的信任，所以我们必须要有充分的准备。准备的内容可以参考如下列表：需求调研计划需求调研大纲需求调研报告模板签到表需求确认单需求规格书模板U盘一个表现专业性要让客户认为调研者有足够的能力和专业性！这个是非常关键的，只有给客户留下深刻的印象，得到用户的认可，客户才会认真对待你。如果你老是抓不到客户的重点，客户和你沟通过几次你都无法理解客户真正想表达的需求，那么，你就是一个失败的需求人员。如果客户认为你是非常有能力而且非常了解他们的业务，而且懂得相关专业知识，他们自然也会相信这个团队提供的软件产品。所以我们应该去客户现场前，我们应该做好如下准备：了解客户的组织架构了解客户的业务需求了解客户领域的知识了解客户常用的专业词汇需求范围要控制需求人员到达现场后，不是收集用户的资料越多越好，如果没有把控好项目范围，对于项目本身而言，一定是灾难性的。所以该拒绝的额外需求一定要讲清楚，给出合理的理由让用户接受，而不是与客户硬碰硬，导致惹恼客户。大家客户从这几方面控制需求范围：依据要充分，一定要把项目的投标文件内容和合同内容给相关人员灌输。你调研的人员不一定清楚项目的前期情况，所以给他们讲清楚前期的项目情况，是需求人员的职责。调研形式要合理，调研的形式多种多样，会议、问卷、访谈、汇报、原型等等形式，针对不同的调研对象，我们要选取最合理的调研形式。调研质量要提高，被调研人员叙说的需求一定要记录好，而且要整理成文档签字确认，如果没有签字确认的材料，可能过段时间，客户可能就提出修改，需求的范围就不好控制。总结汇报要做好，需求调研完成后，一定要组织各方开会，把调研的情况进行总结汇报，各方进行确认，保证需求完成、合理。细化细化再细化需求调研的目的是为后续设计开发做基础，所以需求调研过程中，一定要寻求项目的价值点，尽量把项目边界最小化，流程精细化，操作合理化。如果条件允许，建议一遍调研一遍产出项目原型，保证在项目调研结束后，用户可以看到将来系统80%以上的功能。而且通过原型的展示，用户更能提出有价值的意见，而不是项目完成后，重新返工来保障用户的满意度。三不要不要不间断的问用户问题需求调研是双方沟通的过程，而不是像审问犯人一样，不间断的问客户问题。调研者不停的提出问题，被调研者不断的再回答，好象成了一种审问和被审问的关系，这样的调研状态虽然可以收集大量信息，但从调研角度而言，不是最佳的选择。 真正有经验的调研者首先是先向用户了解整个业务过程，在具体业务过程中顺便了解我们想重点关心的问题。 所以好的调研者要充分的让用户讲话，自己只是在提话题，让用户有兴趣有心情把自己知道的事情完整有序地讲明白。没有挖掘客户真实需求的意识很多需求人员，到达现场后，问问题很积极，沟通也很有技巧，但是就是缺少一些职业敏感，很多很有价值的信息用户已经说出来了，就是不注意挖掘和整理。很多有价值的答案，往往是隐藏在意外事故之中的，如果听到一件和流程不符合的事情，或者和管理预期不符合的事情，这些事实就是异常的事实，值得我们高度重视，深挖穷究。过渡的依赖项目经验需求人员到达现场后，但凡是听到客户提出的一个问题，都有没有经过深度的思考，直接就给用户提出对应的解决方案，很喜欢展示自己的工作经验，这种做法往往是错误的。给客户提供的解决方案往往是临时思考没有经过全面分析，为了表现能力而承诺一定可行的内容发现实际上并不是那么容易，导致后期实施骑虎难下。所以我们应该做一个好的发问者和聆听者，用耳朵去听，用心去想，不要过度的依赖项目经验，导致项目的失败。

企业在制定年度培训计划或者开展一项培训之前，必先需要进行访查员工们的兴趣是什么，他们想要学习的重点等。如果题目设计得不痛不痒，根据无法挖掘出员工真正的兴趣所在，那么这份调研也就失去了其本身的意思。那么，进行企业培训需求调研时，如何设计一份好的调查问卷呢？问卷调查是一项有目的的研究实践活动，从理论指导实践的角度出发进行就是必须的，即设计问卷前必须要做好充足的理论准备，宏观层面上应做到以下两点：明确研究的主题是什么(如用户学习偏好、课程满意度等)，以及明确想通过问卷调查获取哪些信息。值得注意的是，调查问卷的目的必须明确，要在开始设计调查问卷的问题的时候就提前想好，没有目的的问卷调查也是没有实际意义的。其次，就是调查对象。对于企业内部的培训来讲，我们调查的对象就是企业的员工，但是员工各部门不同所想要获得的培训需求也是不同，即对于不同的对象该怎么针对性来对样本对象展开调查，才不会因为样本的偏差而导致输出结果的偏差。此外，在问题的设计方面，我们需要遵循以下几个原则：1、可问可不问的坚决不问：要明白我们的问卷容量是有限的，因为填写者的时间有限。理想的问卷设计应是通过最少的问题获取最大的研究信息。2、无关研究目的的不问：时刻谨记一点：你的问卷是为你的研究目的服务的，千万不要本末倒置。3、创造性的设计问题：你的研究目的是抽象而宏观的，而你要设计的问卷则是通过具体的提问将研究目的进行微观层面上的分解，因此如何通过询问一个个背后有理论支撑与研究目的的问题来获取到你想要的信息，就需要你在问题设置上下功夫了。4、尽量多使用量表题：填空题少用，量表是一种比较规范而且简单容易理解，最为关键的是，其可以匹配非常多的研究方法。对于后期结果的分析也是比较容易。现如今的调查方式总体来说，分为网络调查以及线下调查。关于网络调查，在自己做好调查问卷之后，可以通过个人博客、微博、微信、朋友圈、论坛、贴吧等社交工具来进行调查，线下问卷调查则一般会采用纸质的形式，但是这种方式一方面成本高，另一方面回收率相对来说比较低，对于调研成果的转化也是比较难评估的。当然，也有很多企业利用在线学习平台进行问卷调查。就拿问鼎云学习平台来说，可以直接发布线上调研，方便快捷，调研结束系统可直接进行调研的结果分析，大大地节省了人力，培训师也可根据调研结果第一时间进行培训部署。问鼎云学习成立于1996年，23+年深耕企业培训行业，依托领先的研发技术与专业的运营能力，为企业提供体系化和智能化的在线移动学习解决方案！