调研是什么意思(G端需求调研避坑指南)
编辑导语：有效的需求调研可以帮助产品经理更好地了解用户需求，提高开发效率，降低无效成本。与C端不同，G端的需求调研也需要考虑决策者的需求。在本文中，作者根据实践经验总结和分享了G端需求调研中可能遇到的问题和解决方案。让我们来看看。
前言导读
有没有遇到过甲方需求变化频繁，导致项目需求扩散严重的情况？你见过甲方说& quot我不想让你感觉到，我想让我感觉到& quot？你遇到过顾客说& quot这不是我们想要的& quot上线后？作为G端产品，没有遇到这样的剧情是一种幸运。遇到了才知道有多少坑。本文的最初意图是帮助提前识别和避免它们。
在G端产品的需求调研避坑指南，各个项目遇到的问题在这里不一样，经验总结仅供参考。也希望和踩过同一个坑的产品交流。
让我们一起努力，让坑少一点，路更顺畅一点。
预计阅读时间：15分钟。
首先，你调查过所有的需求吗？比如产品接到了一个临时紧急的需求，却被告知没时间做深入调研，只了解到以下信息。
老板说：这个客户很核心，可以不赚钱，但是客户必须要得到。委托人说：我需要一套完整的住房，一家五口，三代同堂。我需要满足所有的日常功能和完整的配套设施，但我的预算有限。产品一旦被听到，做起来也不是不可以。为了满足客户的需求，同时获得认可，控制成本，我们决定利用公司资源，获得一套周边配套完善的经济适用房，但是客户一家一直在国外度假，没有时间确认。眼看工期将至，产品迅速带团队夜以继日加班装修，满足客户提出的所有功能，准备交付验收。
当客户回到中国时，他们感到失望，觉得与他们理想的住房完全不同。
再次沟通后，发现自己只掌握了需求的冰山一角，实际的财权在爷爷手里，而不是一直在和需求沟通的那个人。爷爷的实际期望是泳池别墅不服。但是我们能做什么呢？客户有什么问题？唯一的错误就是背锅侠的产物。
这是一个由真实案例抽象改编的故事，客户预期和实际落地有差距。核心原因是：
前期的需求调查不稳定，后期的实施不允许。没有掌握所有关键利益相关者的客户需求。埋在工作中，没有分阶段接受交付。因此，为了避免需求落地的巨大偏差，缩小这种偏差，需要明确每个阶段要考察的信息，以保证节目输出的质量。
第二，每个阶段的研究内容和产出对需求的研究可以分为三个阶段，前期背景调研、启动阶段的整体业务调研、交付阶段的需求调研和设计确认.
信息来源不限，可以来自市场、售前、项目经理、客户、用户、客户官网、招投标等各种渠道。
1.前期：大坑之一：不重视前期调研，将增加客户期望与实际功能偏差的可能性。.背景研究
在项目前期与客户的沟通中，产品经理需要充分了解项目背景、客户诉求、用人单位环境和业务数据，避免后期调研中出现信息缺口。
在这个阶段，需要了解项目背景、客户、用人单位环境、业务数据源信息。具体如下。
1）了解项目背景
首先要对项目产品所服务的业务领域有一个大致的了解。
其次，在项目开始之前，要明确项目最终不可改变的目标是什么，并与所有利益相关者，尤其是大领导，进行目标的对齐。你为什么做这个项目？项目的长期愿景是什么？短期目标是什么？
项目做什么:了解项目核心解决的问题，通过招标信息、市场和售前人员的介绍、网上相关信息的收集，了解建造方的诉求，把握希望达到的目标；项目是什么:掌握项目的现状是从0-1开始构建，或迭代现有版本，或推翻并重做现有版本。目前的现状存在哪些问题？项目怎么做:了解项目预算、项目建设周期、相关政策指引、制度要求、行业标准和行业规范。2）了解客户
了解客户想要什么的过程需要贯穿G端项目的始末。
需求变化、需求重复、需求扩散在G端项目中是不可避免的。核心是使产品符合& quot蓝图& quot顾客的心理预期。如何实现& quot蓝图& quot甚至超出顾客的想象，获得更高的顾客满意度尤为重要。
项目客户的组织结构:确认项目的用户组织，以便在后期掌握不同角色对系统的需求；客户期望:由于TOG项目的特殊性，使用者和决策者不是同一批人。因此，需要区分决策者、利益相关者和用户的不同期望，尤其是高层次客户的需求。客户性格:它方便更好的沟通。3）了解使用单位环境
调查使用单位的环境，主要是掌握使用单位机房的情况。大部分政府项目都是涉密数据，内网多，存在外网和内网数据如何打通等问题，需要提前了解系统的运行环境。
网络环境:掌握网络系统的操作和部署。
络环境，是内网还是互联网？对数据传输和功能实现可能有较大影响。部署服务器配置：所需内存？cup配置是否满足需求？G端软件项目中，项目经理参与程度不一，产品常承担部分项目经理工作，为避免硬件不符合要求，延误需求上线，需提前掌握该部分信息，及时申请或采购。用户：用户量多少？并发量多少？4）了解业务数据源
数据获取程度由数据基础决定，需逐步明确数据情况，在足够了解数据基础后进行系统设计与产品方案设计。
有什么：该阶段的数据调研，掌握需要什么业务数据；为什么：为什么要有该类数据，核心解决了什么问题；怎么做：怎么获取该部分数据，以明确数据对接方式、网络环境。在项目启动签订合同前后，会对整体的业务进行调研，需预留准备时间，做充足的调研准备。
在该阶段，需关注用户角色、业务流程、业务数据、功能架构信息，详情如下。
1）角色调研大坑之二：未掌握高层客户底层需求。
各层级都有各自角色形成的期望，掌握各层级期望，有助于方案设计和成果汇报更加顺利。
需求分析：站在用户角度分析高层决策者、干系人、使用者各角色的需求，分别存在的痛点，以及是更关注尽早上线、功能完善程度还是界面美观程度；用户习惯：通过提前了解用户已有系统，掌握用户的整体风格与交互习惯，了解用户对已有系统的不满，及时规避不足；掌握上层平台，提前规划数据对接及应用对接方案。2）业务流程梳理大坑之三：业务调研深度广度不够。
客户不是每个流程和业务都知道，需要留时间给客户去了解和调研，引导客户深度参与。
若是以部门为单位的集中式调研，调研清单要设计合理，给客户足够的考虑时间，最好提供相应的建议和案例，让相关部门提前思考和准备，能提前拉群沟通和提前获取业务相关资料更好。
在业务调研环节，主要调研和输出业务流程、场景、核心需解决的问题、业务流程中的输入输出。
绘制业务流程图：了解业务场景，梳理每个流程节点内容与负责人；业务涉及使用角色说明；业务流程中的表格、报告，最好都有真实样例数据；业务数据源：涉及到哪些数据源；数据来源网络环境；数据更新时间；数据量多大；字段标准等；业务流程中的表格、报告，最好都有真实样例数据；业务流程优化建议：存在什么痛点，有什么建议与想法。3）业务数据源
该阶段明确业务数据源的来源和内容，掌握需对接的第三方平台及单位，确认需要协调的资源，避免不确定的风险，为方案选择和实施能带来较大便利。并能保证项目开发进度，比如由于数据无法如期对接、推送延迟、数据质量较差等原因，将影响我方项目交付。
系统对接类：提前明确和什么系统对接；网络环境及数据传输方式如何；接口规范如何，需明确输入输出，最好提前获取对接文档，梳理数据流图；明确系统对接人单位、姓名、联系号码、岗位，和研发人员建群提前沟通；明确接口提供时间，是否影响项目进度；数据填报类：需掌握填报内容和填报业务流程，如填报角色是谁，是否需要审批，更新要求是什么；数据情况：获取样例数据、数据更新时间、数据量、字段标准。4）功能框架确认
在整体业务调研基本完成时，需同时梳理整体功能框架，并进行确认。在确认阶段，尽可能避免在沟通中出现理解偏差。最可怕的是，双方都认为对方理解了彼此的意思。
面对信息化建设经验较少的甲方，建议准备首页、能体现平台架构的主页面的视觉稿，确认架构和整体风格，更能被理解；面对决策层级较多的甲方，并需要针对不同客户角色关注点，准备不同颗粒度的方案。
项目整体框架：项目的整体模块功能层级，确定子系统和功能模块；梳理模块功能清单；梳理各个模块之间的关联；确认和上级系统的关联；确定阶段目标：确认业务功能优先级；制定阶段性功能目标；梳理里程碑目标。交付阶段遇到技术明确，需求不明确阶段，增量交付方式返工概率大。产品原型设计需预留足够时间进行多次确认，设计采用敏捷方式多沟通确认，开发使用瀑布流方式，确认需求并验证方案后再开发，去降低推翻重来的风险。
在该阶段，需关注需求列表、整体功能架构、业务数据、系统设计信息，详情如下。
1）需求维护
大坑之四：从不了解业务/没有决定权的角色获取需求，九成返工。有时方案确认像闯关，层层规则不一样。明明因为方案未确认而无产出，但甲方只觉得你没干活。
需针对不同层级领导沟通实现想法，了解真实期望，和项目经理一同分析领导信息化认知阶段和关注点，准备不同材料，客户是想早点上线？还是更关注界面美观？还是功能完善？还是成本控制？
其实人生有捷径。重要决策可想办法，通过商务、项目侧各方面拿到决策方、拍板人的意见。
可建立需求初步筛查规则，在需求首次被提及时，需求获取人可对需求进行初筛和答复客户；和甲方针对各需求获取渠道建立统一需求对接人，将承接的需求汇总；建立共享需求反馈池，根据需求类型及迭代状态进行分类管理，让需求采集及时记录，需求规划及进度一目了然；对已上线的需求、已提测的需求、挂起的需求、当前迭代已确认的需求，单独建表管理；需求变更很常见，也需长期和甲方“博弈”，需分析客户关注哪个需求，聚焦于核心需求，在变更时及时调整优先级，和甲方沟通确认；分析客户关注哪个层级信息。2）维护整体功能框架
项目整体框架：交付阶段及时维护子系统和功能模块；维护功能清单；维护各模块功能关系；跟进阶段性目标：根据项目变化，及时调整需求优先级，阶段性验证功能目标的完成情况。3）业务数据源
该阶段需在项目经理和技术人员协助下获取信息。
了解和第三方系统对接处于什么阶段；已对接的数据进行数据验证，判断是否满足系统设计要求；短期无法对接、对接后有数据问题的模块准备预备方案。4）确认系统设计大坑之五：忽视决策高层与使用者需求之间存在的差异。
有决策权的高层需求与系统用户的使用需求，同等重要。宏观到整体架构，微观到字段，需分层明确。
项目有计划，研发有流程。再确认环节为不影响项目整体进度，需想尽办法拿到决策方、拍板人的意见，向客户阐述现状及利弊，必要时通过市场、项目侧推动，否则因需求反复造成的返工情况，会严重影响工期和团队积极性。
客户需求：区分业务使用者和高层的关注点；决策干系人关注业务场景；使用者关注是否能满足日常使用；业务流程：调研现有的业务；规划系统使用之后的业务流程；确认通过系统完成的流程优化；产品页面设计：需对系统输入输出、页面布局、涉及字段进行细节确认。在这设计逐步确认过程中，甲方才能逐步明确自身想法，偶尔也需要一些沟通“技巧”。
比较G端与C端调研的差异，两者都需要通过调研构建用户画像，也同样说的不等于想要的，但也有很多不同点。
对用户而言，G端产品的替换成本大于C端，因此需关注用户已形成的习惯和认知。另外需对已有系统和环境的调研更为重要，如硬件设备的分辨率情况，将严重影响设计方案。
在业务需求调研方面，C端属于用户就是客户，使用者至上；G端的使用者和决策者往往是两批人，需求提出方和建设方也往往是两批人，更多的是决策者至上。
总之，需求调研是需求分析的前提，需求分析是产品方案决策的依据，需求确认是对需求调研准确性的验证。
只有足够的输入才有好的输出，所以明晰各阶段需求调研所需内容，做好需求调研，才能保障方案的产出质量，从而为客户带来价值，获得客户对我们服务的认可。
望共勉之。
本文由@wenda原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。