G端需求调研避坑指南

编辑导语：有效的需求调研可以让产品经理更好地了解用户需求，提高开发效率，降低无效成本。而不同于C端，G端需求调研还需要考虑决策者需求。本篇文章里，作者结合实际经验，总结、分享了G端需求调研时可能遇到的问题与解决方案，一起来看一下。

前言导读

• 你是否遇到过需求频繁变更的甲方，导致项目需求蔓延严重？
• 你是否遇到过“我不要你觉得，我要我觉得”的甲方？
• 你是否遇到过上线后客户说“和我们想要的不一样”？

作为G端产品，没遇到此类情节是一种幸运，遇到才知有多坑，本文初心是希望能帮忙提前识别和避免。

此处G端产品的需求调研避坑指南，各项目所遇问题不同，经验总结仅供借鉴，也希望和踩过同样坑的产品，一同交流。

大家携手，让坑少一点，路顺一点。

预计阅读时长：15min。

一、首先，你调研到全部需求了吗？

举个例子，产品接到临时又紧急的需求，但被告知没时间做深入调研，只了解以下信息。

• 老板说：这个客户很核心，可以不赚钱，但客户要搞定。
• 客户说：我需要一整套住房，一家五口人住，三世同堂，需要满足所有日常使用功能，配套设施要齐全，但我预算有限。

产品一听，也不是不能做。为满足客户需求，同时获得肯定，还要控制成本，决定利用公司资源，获取一套周边设施完善的经济适用商品房，但客户一家人一直在国外度假，没空确认。眼看工期将至，产品赶紧带团队没日没夜加班装修，将客户所提功能全部满足，准备交房验收。

客户回国一看却大失所望，觉得和自己的理想住房完全不同。

再次沟通才发现，只掌握了需求的冰山一角，且实际财政权在爷爷手里，不在一直沟通需求的男主人这。而爷爷的实际期望，是泳池大别墅，拒绝验收。但能怎样呢，客户哪有错呢，错的只有背锅侠产品。

这是按真实案例抽象改编的故事，属于客户期望与实际落地差距存在一条鸿沟，核心原因是：

1. 前期需求调研不稳，后期实施落地不准。
2. 未掌握全部关键相关方的客户需求。
3. 埋头干活，未阶段性地验收交付。

因此，为避免需求落地的巨大偏差，缩小这种偏差，需明晰各阶段需调研的信息，才能保障方案产出的质量。

二、各阶段调研的内容和产出

ToG需求调研可分为三大阶段，前期背景调研、启动阶段的整体业务调研、交付阶段的需求调研和设计确认。

信息来源不限，可来自市场、售前、项目经理、客户、用户、客户官网、招投标等各类渠道。

1. 前期阶段：背景调研

大坑之一：不重视前期调研，将增加客户期望与实际功能偏差的可能性。

在项目启动前期与客户沟通中，产品经理需要充分了解项目背景、客户诉求、使用单位环境情况、业务数据情况，避免在后期调研时存在信息差。

在该阶段，需了解项目背景、客户、使用单位环境、业务数据源信息，详情如下。

1）了解项目背景

首先，要对项目产品所服务的业务领域有一个概括性的了解。

其次，在项目开始前，一定要明确项目终极不可更改的目标是什么，要跟所有相关性方、特别是和大领导要对齐目标。明确为什么做该项目？该项目的长期愿景是什么？短期目标有什么？

• 项目做什么：清楚项目核心解决的问题，可通过招投标信息、市场和售前人员介绍、网上相关资料搜集了解建设方的诉求，掌握希望达成的目标；
• 项目是什么：掌握项目现状，是从0-1的新建，或已有版本的迭代，或已有版本的推翻重做，目前现状存在什么问题；
• 项目怎么做：了解项目预算、项目建设周期、相关政策指导方针、制度要求、行业标准、行业规范。

2）了解客户

了解客户想要什么的过程，需贯穿G端项目的始末。

需求变更、需求反复、需求蔓延在G端项目中难以避免，究其核心是让产品与客户心理期望的“蓝图”实现一致，怎样实现客户“蓝图”甚至**越客户想象，得到较高客户满意度，前期调研明确客户“蓝图”显得尤为重要。

• 项目客户的组织结构：确认项目的用户机构是哪些，以便后期掌握不同角色对系统的诉求；
• 客户期望：ToG项目的特殊性造成了使用者和决策者不是同一批人，为此，需要区分掌握决策者、干系人、使用者这几类角色的不同期望，尤其是高层级客户需求；
• 客户性格：便于更好的沟通。

3）了解使用单位环境

调研使用单位环境主要为掌握使用单位机房情况。政府项目大多为涉密数据，用内网较多，存在外网和内网数据如何打通等问题，需要提前了解系统运行环境。

• 网络环境：掌握系统运行部署的网络环境，是内网还是互联网？对数据传输和功能实现可能有较大影响。
• 部署服务器配置：所需内存？cup配置是否满足需求？G端软件项目中，项目经理参与程度不一，产品常承担部分项目经理工作，为避免硬件不符合要求，延误需求上线，需提前掌握该部分信息，及时申请或采购。
• 用户：用户量多少？并发量多少？

4）了解业务数据源

数据获取程度由数据基础决定，需逐步明确数据情况，在足够了解数据基础后进行系统设计与产品方案设计。

• 有什么：该阶段的数据调研，掌握需要什么业务数据；
• 为什么：为什么要有该类数据，核心解决了什么问题；
• 怎么做：怎么获取该部分数据，以明确数据对接方式、网络环境。

2. 启动阶段：整体业务调研

在项目启动签订合同前后，**对整体的业务进行调研，需预留准备时间，做充足的调研准备。

在该阶段，需关注用户角色、业务流程、业务数据、功能架构信息，详情如下。

1）角色调研大坑之二：未掌握高层客户底层需求。

各层级都有各自角色形成的期望，掌握各层级期望，有助于方案设计和成果汇报更加顺利。

• 需求分析：站在用户角度分析高层决策者、干系人、使用者各角色的需求，分别存在的痛点，以及是更关注尽早上线、功能完善程度还是界面美观程度；
• 用户习惯：通过提前了解用户已有系统，掌握用户的整体风格与交互习惯，了解用户对已有系统的不满，及时规避不足；掌握上层平台，提前规划数据对接及应用对接方案。

2）业务流程梳理大坑之三：业务调研深度广度不够。

客户不是每个流程和业务都知道，需要留时间给客户去了解和调研，引导客户深度参与。

若是以部门为单位的集中式调研，调研清单要设计合理，给客户足够的考虑时间，最好提供相应的建议和案例，让相关部门提前思考和准备，能提前拉群沟通和提前获取业务相关资料更好。

在业务调研环节，主要调研和输出业务流程、场景、核心需解决的问题、业务流程中的输入输出。

• 绘制业务流程图：了解业务场景，梳理每个流程节点内容与负责人；业务涉及使用角色说明；业务流程中的表格、报告，最好都有真实样例数据；
• 业务数据源：涉及到哪些数据源；数据来源网络环境；数据更新时间；数据量多大；字段标准等；业务流程中的表格、报告，最好都有真实样例数据；
• 业务流程优化建议：存在什么痛点，有什么建议与想法。

3）业务数据源

该阶段明确业务数据源的来源和内容，掌握需对接的第三方平台及单位，确认需要协调的资源，避免不确定的风险，为方案选择和实施能带来较大便利。并能保证项目开发进度，比如由于数据无法如期对接、推送延迟、数据质量较差等原因，将影响我方项目交付。

• 系统对接类：提前明确和什么系统对接；网络环境及数据传输方式如何；接口规范如何，需明确输入输出，最好提前获取对接文档，梳理数据流图；明确系统对接人单位、姓名、联系号码、岗位，和研发人员建群提前沟通；明确接口提供时间，是否影响项目进度；
• 数据填报类：需掌握填报内容和填报业务流程，如填报角色是谁，是否需要审批，更新要求是什么；
• 数据情况：获取样例数据、数据更新时间、数据量、字段标准。

4）功能框架确认

在整体业务调研基本完成时，需同时梳理整体功能框架，并进行确认。在确认阶段，尽可能避免在沟通中出现理解偏差。最可怕的是，双方都认为对方理解了彼此的意思。

面对信息化建设经验较少的甲方，建议准备首页、能体现平台架构的主页面的视觉稿，确认架构和整体风格，更能被理解；面对决策层级较多的甲方，并需要针对不同客户角色关注点，准备不同颗粒度的方案。

• 项目整体框架：项目的整体模块功能层级，确定子系统和功能模块；梳理模块功能清单；梳理各个模块之间的关联；确认和上级系统的关联；
• 确定阶段目标：确认业务功能优先级；制定阶段性功能目标；梳理里程碑目标。

3. 交付阶段：阶段性调研确认

交付阶段遇到技术明确，需求不明确阶段，增量交付方式返工概率大。产品原型设计需预留足够时间进行多次确认，设计采用敏捷方式多沟通确认，开发使用瀑布流方式，确认需求并验证方案后再开发，去降低推翻重来的风险。

在该阶段，需关注需求列表、整体功能架构、业务数据、系统设计信息，详情如下。

1）需求维护

大坑之四：从不了解业务/没有决定权的角色获取需求，九成返工。有时方案确认像闯关，层层规则不一样。明明因为方案未确认而无产出，但甲方只觉得你没干活。

需针对不同层级领导沟通实现想法，了解真实期望，和项目经理一同分析领导信息化认知阶段和关注点，准备不同材料，客户是想早点上线？还是更关注界面美观？还是功能完善？还是成本控制？

其实人生有捷径。重要决策可想办法，通过商务、项目侧各方面拿到决策方、拍板人的意见。

• 可建立需求初步筛查规则，在需求首次被提及时，需求获取人可对需求进行初筛和答复客户；
• 和甲方针对各需求获取渠道建立统一需求对接人，将承接的需求汇总；
• 建立共享需求反馈池，根据需求类型及迭代状态进行分类管理，让需求采集及时记录，需求规划及进度一目了然；
• 对已上线的需求、已提测的需求、挂起的需求、当前迭代已确认的需求，单独建表管理；
• 需求变更很常见，也需长期和甲方“博弈”，需分析客户关注哪个需求，聚焦于核心需求，在变更时及时调整优先级，和甲方沟通确认；
• 分析客户关注哪个层级信息。

2）维护整体功能框架

• 项目整体框架：交付阶段及时维护子系统和功能模块；维护功能清单；维护各模块功能关系；
• 跟进阶段性目标：根据项目变化，及时调整需求优先级，阶段性验证功能目标的完成情况。

3）业务数据源

该阶段需在项目经理和技术人员协助下获取信息。

• 了解和第三方系统对接处于什么阶段；
• 已对接的数据进行数据验证，判断是否满足系统设计要求；
• 短期无法对接、对接后有数据问题的模块准备预备方案。

4）确认系统设计大坑之五：忽视决策高层与使用者需求之间存在的差异。

有决策权的高层需求与系统用户的使用需求，同等重要。宏观到整体架构，微观到字段，需分层明确。

项目有计划，研发有流程。再确认环节为不影响项目整体进度，需想尽办法拿到决策方、拍板人的意见，向客户阐述现状及利弊，必要时通过市场、项目侧推动，否则因需求反复造成的返工情况，**严重影响工期和团队积极性。

• 客户需求：区分业务使用者和高层的关注点；决策干系人关注业务场景；使用者关注是否能满足日常使用；
• 业务流程：调研现有的业务；规划系统使用之后的业务流程；确认通过系统完成的流程优化；
• 产品页面设计：需对系统输入输出、页面布局、涉及字段进行细节确认。

在这设计逐步确认过程中，甲方才能逐步明确自身想法，偶尔也需要一些沟通“技巧”。

三、G端与C端的调研异同

比较G端与C端调研的差异，两者都需要通过调研构建用户画像，也同样说的不等于想要的，但也有很多不同点。

对用户而言，G端产品的替换成本大于C端，因此需关注用户已形成的习惯和认知。另外需对已有系统和环境的调研更为重要，如硬件设备的分辨率情况，将严重影响设计方案。

在业务需求调研方面，C端属于用户就是客户，使用者至上；G端的使用者和决策者往往是两批人，需求提出方和建设方也往往是两批人，更多的是决策者至上。

四、总结

总之，需求调研是需求分析的前提，需求分析是产品方案决策的依据，需求确认是对需求调研准确性的验证。

只有足够的输入才有好的输出，所以明晰各阶段需求调研所需内容，做好需求调研，才能保障方案的产出质量，从而为客户带来价值，获得客户对我们服务的认可。

望共勉之。

本文由 @wenda 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。