（干货）G端产品的需求调研避坑指南

介绍

作为一款G端产品，没遇到这样的剧情也是一种幸运。 遇到了才知道有多坑。 写这篇文章的初衷是帮助提前识别和规避。

这里有一份G端产品需求调研和避坑指南。 每个项目遇到的问题不一样，经验总结仅供参考。 也希望和踩过同样坑的产品交流。

让我们共同努力，让坑少一些，路更顺一些。

预计阅读时间：15 分钟。

1. 首先，你是否研究过所有的需求？

比如产品接到临时紧急需求，却被告知没有时间深入研究，只知道以下信息。

产品一听，做起来也不是不可能。 为满足客户的需求，获得认可，控制成本，决定利用公司资源获得一套周边配套完善的保障性商品房。 但是，客户的家人一直在国外度假，没有时间确认。 眼看工期将至，产品组赶紧带领团队夜以继日地加班装修需求分析，满足客户提出的各项功能，为房屋验收做准备。

客户回到家后很失望，觉得这和他理想中的房子完全不一样。

再次沟通后，才发现自己只抓住了需求的冰山一角，实际的财务大权掌握在爷爷手中，而不是一直沟通需求的男主。 然而，爷爷的实际期望是带游泳池的大别墅，他不肯接受。 但是能怎么办呢，客户并没有错，错的只是被指责的产品。

这是一个根据真实案例抽象改编的故事。 客户期望与实际执行之间存在差距。 核心原因是：

前期需求调研不稳定，后期实施不准。 未捕获所有关键利益相关者的客户需求。 步步为营，不检查发货。

因此，为了避免需求的执行出现巨大的偏差，减少这种偏差，需要明确每个阶段需要调查的信息，以保证程序输出的质量。

2.各阶段研究内容及产出

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

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

1、预备阶段：背景调查

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

项目立项前期与客户沟通时，产品经理需要充分了解项目背景、客户需求、用户单位环境情况、业务数据情况，避免后期调研出现信息断层。

这个阶段需要了解项目背景、客户、用户环境、业务数据源信息。 详情如下。

1）了解项目背景

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

其次，在项目启动之前，必须明确项目最终不变的目标是什么，并且要与所有相关方，尤其是大领导保持一致。 明明为什么要做这个项目？ 该项目的长期愿景是什么？ 短期目标是什么？

2）了解你的客户

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

需求变更、需求重复、需求扩散在G端项目中是不可避免的。 核心是让产品符合顾客心理预期的“蓝图”。 如何实现客户的“蓝图”，甚至超越客户的想象，从而获得较高的客户满意度 因此，在前期调研中明确客户“蓝图”就显得尤为重要。

3）了解使用单位的环境

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

4）了解业务数据来源

数据获取的程度由数据基础决定。 需要逐步理清数据情况需求分析，在充分了解数据基础后进行系统设计和产品设计。

2. 创业阶段：整体业务调研

项目启动及合同签订前后，将进行整体业务考察。 要预留准备时间，做好充分的研究准备。

这个阶段需要关注用户角色、业务流程、业务数据、功能架构信息，详见下文。

1）角色研究的第二大坑：未能抓住高层客户的底层需求。

每个层级对角色的形成都有自己的期望，掌握每个层级的期望值，将有助于计划设计和结果汇报更加顺畅。

2）业务流程整理的第三大坑：业务研究的深度和广度都不够。

客户并不了解每一个流程和业务，所以我们需要留出时间让客户去了解和研究，引导客户深度参与。

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

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

3）业务数据源

此阶段明确业务数据源的来源和内容，掌握需要对接的第三方平台和单位，确认需要协同的资源，规避不确定性风险，为方案选择和实施带来更大便利. 并且可以保证项目开发的进度。 例如，由于计划外的数据连接、延迟推送、数据质量差等原因，我们的项目交付会受到影响。

4）功能框架确认

当整体业务调研基本完成后，需要同时对整体功能框架进行梳理和确认。 在确认阶段，尽量避免沟通中的理解偏差。 最可怕的是，双方都认为对方理解对方。

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

3、交付阶段：阶段性考察确认

当交付阶段遇到技术清晰，需求不明确的阶段，增量交付方式返工概率很高。 产品原型设计需要预留足够的时间进行多次确认。 设计采用敏捷方式多次沟通确认，开发采用瀑布流方式。 在确认需求和验证方案后，制定降低推翻和重启的风险。

这个阶段需要关注需求列表、整体功能架构、业务数据、系统设计信息，详见下文。

1）需求维护

大坑4：从不懂业务/没有决定权的角色那里获取需求，90%会返工。 有时候方案确认就像闯关一样，不同层次有不同的规则。 明明没有输出是因为方案还没有确定，甲方却只觉得你没有工作。

需要针对不同层级的领导沟通和落实想法，了解真实的期望，与项目经理分析领导信息化的认知阶段和重点，准备不同的材料。 客户是否想早点上线？ 还是您更关心界面的美观性？ 还是功能齐全？ 还是成本控制？

其实人生是有捷径的。 对于重要的决策，可以想办法通过业务和项目方获得决策者和入围者的意见。

2）维护整体功能框架

3）业务数据源

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

4）确认系统设计的第五大坑：忽略高层决策者与用户需求的差异。

具有决策权的高层需求与系统用户的使用需求同等重要。 从宏观到整体结构，从微观到领域，都需要分层梳理。

项目有计划，研发有过程。 重新确认环节是为了不影响项目的整体进度。 要想方设法征求决策方和入围方的意见，向客户说明现状和利弊，必要时通过市场和项目方进行宣传。 严重影响工期和团队积极性。

在逐渐确认设计的过程中，甲方可以逐渐理清自己的思路，偶尔也需要一些沟通“技巧”。

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

对比G端和C端调研的不同，两者都需要通过调研来构建用户画像，说的不等于想的，但是有很多不同。

对于用户而言，G端产品的更换成本大于C端产品，因此需要关注用户已经形成的习惯和认知。 另外，更重要的是考察现有的系统和环境，比如硬件设备的分辨率，这些都会严重影响设计方案。

在业务需求研究方面，C端属于用户，是客户，用户是第一位的； G端用户和决策者往往是两组人，需求提出者和建设者也往往是两组人，决策者更为重要。 .

四。 概括

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

有足够的输入才有好的输出，所以明确需求调研每个阶段需要的内容，做好需求调研，才能保证解决方案的输出质量，从而为客户带来价值，获得客户对我们的认可服务。

希望互相鼓励。