在产品开发过程中，需求调研是至关重要的第一步。然而，面对变化多端的需求方，产品经理常常会遇到各种问题，比如需求不清晰、业务背景不明确、数据统计不准确等。本文将结合实际案例，分享如何通过科学的调研维度、合理的需求分类、精准的业务水平评估以及有效的沟通策略，避免需求调研中的常见坑点，确保项目顺利推进。

“刚上线的这个功能，能不能在这里再加个xxx”

“这个需求不是这样的呀，是xxx那样的”

“你就按照我说的这里加个xx按键”

“……”

作为一名6年的产品小趴菜，想给大家分享一下我面对变化多端的需求方，一般都是怎么应对的？

调研维度

业务背景/场景 要解决的问题️ 相关人员 需求影响范围（业务主体、时间等） 现有业务流程 相关业务逻辑 历史逻辑如何兼容 数据验证逻辑

需求分类

一个需求过来，我首先会快速分辨一下这个需求的类型。比如属于全新业务需求、已有业务拓展需求，还是已有功能优化需求等等？

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

分辨后调研的思路会有点差异：拿以上三类举例来说

1.全新业务需求：

调研时，会首先了解这个业务整个的核心流程、主要场景、相关角色，明确清楚这个业务是为了给谁解决什么场景下的什么问题。小Tips，建议不要仅了解需求涉及到的全流程中的一小部分环节，这样很可能导致最后做出来的需求不是业务方想要的，或者影响到了其他上下游业务；

这一步理清楚后，再去了解本次需求是什么，开始到详细需求的调研阶段；

2.已有业务拓展需求：

往往这类需求在我日常工作中比较居多。调研时，因为已知业务的全流程，需要有针对性的了解目前业务遇到了什么问题，为了达到什么样的目的，考虑本次需求是否会影响整体流程，是否整体流程需要改造等等。

3.已有功能优化需求：

业务迭代一段时间后，总会出现各种各样无论政策原因还是其他原因导致的业务变更，有变更就会有新需求出现，需要将现有功能持续迭代，轻者正常叠加功能、重者也可能存在重构整个功能（这个也比较考验产品同学在一开始对所在行业的认知，会影响对产品的整体规划；不过也会存在因为客观原因确确实实需要重构的情况）。调研时，我常常会提醒自己本次迭代后与原来相比，优势是什么、有什么明显的价值提升，有了明确的对比，在项目整体推进的过程中也更有说服力。

业务水平

除了对需求的分类分析外，也比较考验提出需求的同学业务水平与产品同学的业务水平。

调研前，我一般会先去了解下，业务方部门的人员结构，每个人都是负责什么的，负责了多久，之前的业务效果怎么样，再结合之前合作过的经验综合评估下，本次需求调研除了提需求的同学，是否有必要再叫上其他相关联/对相关业务了解更深入的同学，这样多方协作，会尽量多的避免一些因业务侧重点不同导致的考虑不全，或影响其他支线业务的情况。

当然了，如果本次需求有涉及到其他业务的产品功能，也是需要将负责另外一个业务的产品同学叫上，大家一同沟通，可以尽量避免因不了解其他业务的逻辑，去猜测一个逻辑往下推演新需求的方案，最后导致白沟通一场。

踩过的坑

拿数据相关需求举例来说，以下是做广告投放相关业务时所遇情况：

1.运营数据统计：

需要统计运营的一些社交媒体效果数据，如统计社交媒体多个账号带来的转化效果。

业务方会常用一些专有名词（假设还没有普遍到人人都知道的程度），比如社媒频道，说实话，一开始我是真的不知道是个什么东西，就自以为的带入了一个实物去对接，并没梳理清楚主体，就去问需要从哪个维度监控数据等等，导致需求出了2次都不对

原因也很明显，对业务方描述的主体名词不懂，没有及时询问，导致最终设计的也是大相径庭。

社媒频道：在广告投放业务中运营同学是指媒体上的推广账号（如：博主的抖音账号）

2.新老逻辑交叉时间点前后的数据统计：

统计投放相关的数据时，业务方3月10日前使用A逻辑进行数据统计，3月10日后期望改成B逻辑统计，新老逻辑都要保留，并且是按照3月10日这个卡点（原因也是业务上的一些客观变动导致），因为过于信任下游同学，上线后出现了隐藏bug，导致反复修正2、3次，3天左右才全部正确。时间节点没有严格记录并同步给业务方，导致结算时出现数据偏差，这种问题需前期及时同步到位，业务方处理时也心里有数。

处理方案：单独做了清单表，记录每次影响数据的修改时间点及每次修改后的新逻辑。

3.历史数据：

除了需求的新逻辑外，一定记得和业务方沟通好历史数据如何处理、如何兼容、是否需要按照新逻辑补充历史时间的数据等等。

这里注意下：若需补充历史数据，从什么时间开始补、能补充到的是否为当时时间的准确数据、若不准确，拿从什么时间开始是准确数据。

注意事项

1.调研需求时：一个不小心就先入为主了

比如：广告投放业务中，每个广告都有推广文案，已有功能支持查看每条广告的数据，没有把广告里的文案拿出来展示，业务方提出需求，要把文案显示出来，看广告文案的效果

我自以为原有的广告数据就代表了文案数据，也就没有多问，直接把文案展示出来了而已，但文案数据和已有的广告数据是两回事，也就是说这个需求我其实没有做完。

思考后，无论是一句话还是以为知道了的需求，我后面都会尽量把该问的都问一遍，防止出现需求理解层面，存在有出入的情况，也避免了返工情况的出现。

2.新业务范围：只做了1/2的需求

刚做广告投放业务时，公司本业务其实有A、B两个主体在运营，侧重于推广A主体，我在一次需求中，遗漏了业务中B的部分，因为日常总说A业务，会不小心遗忘掉B，在后续每次调研时，我都提醒自己，业务的范围先确认好，再去进行后续的交流；也需要注意下A、B业务的逻辑是否不同、是否要每个单独处理。

今天就分享到这里了，欢迎大家一起交流学习。