对产品经理来说，大部分工作时间是以需求为中心展开的——需求分析、需求调查、跟进实现需求等。 那么，关于需求调查这个部分，一般有几种调查方法吗？ 我们怎么用这些方法呢？

需求调查是实现需求的前提。

需求调查的主要内容是了解需求背景、明确需求目标、筛选不适当的需求、决定大致的计划。

有需求的用户是谁？ 解决需求的中心问题是什么？ 使用场景是什么？ 主要场景和次要场景是哪个？ 业务流程是什么？ 除了主要业务以外，可以使用此功能的流程是什么？ 除了这个系统以外，还有哪些系统与这个功能相关……

这就是需求调查的“十万个理由”。

结合本篇《后端产品经理宝典》书中的内容，我们仅从需求调查的案例来看看几种常用的调查方法。

一、过滤需求的方法

为了制作后端系统，学习的第一个技能是切断需求。 也就是过滤需求。

这不是贬义，反而是体现后端产品价值判断的基础。

过滤需求的方法应该通过一定的手段判断需求是否为虚拟需求，然后进行过滤。

1. 用户场景模拟法

后端产品的出发点是帮助商业用户，因此在调查需求时模拟商业场景，分析商业用户提到的需求是否能够解决他的问题。

如果不能帮助用户，这个需求可能是虚假的需求。

以下情况说明。

背景：“货到付款”类型的订单因缺货而无法发行。 超过一定时间后，与顾客取得联系，取消订单。

需求：需要在“缺货订单”列表页中添加“批量订单”按钮，因为这样的订单数量非常多，取消单个订单需要太长的时间。

分析：在调查业务操作场景时，首先发现此类缺货订单，然后与客户取得联系，等客户同意删除后，再进行删除。 也就是说，要逐一沟通确认，逐个取消订单，所以“批量取消”无法有效使用。

因此，这种需求是虚假的需求，应该被过滤掉。

2. 功能归属分析

专业系统执行专职功能，有助于合理的产品体系建设。

因此，在需求调查时，通过系统的定位，可以判断需求是否应该在该系统中实现。

如果不属于这个系统的范畴，说服用户直接更换方案。 以此来

以下情况的说明：

背景： CRM系统(顾客关系管理系统)具有根据顾客的消费行为数据，自动对应并关联标签的顾客标签生成功能，如优质顾客、高潜力顾客、欺诈顾客等。

需求：商务人士提出需求时，除了上述基础标签外，还会制作英文版的标签。 这是把标签复印件翻译成英语。 这样，欧美员工就可以在英文版的系统中使用了。

分析：调查翻译的标签不是在CRM系统中使用的，而是在短信(SMS )中使用的。

所以SMS应该基于CMS提供的基础标签数据，自己进行二次派生。

因此，首先是为了避免未来更多的语言版本的扩展需求和更多的系统提出同样的需求；

第二，CRM系统已经完成了“继电器”的第一棒，创造了基础数据，其他系统可以专门化使用，完全可以自己进行专门化处理，无需结合回CRM系统。

结论：案例的需求本身是真实的需求，也不难实现，但该功能的定位超出了本系统的范畴，应由专业系统执行专职功能，并下游执行派生需求。

否则，耦合性过高只会增加系统的复杂性，难以维护和扩展。

二、拆分和聚合的方法

1. 拆分需求法

商务人士提出一个需求，可能是简短的话。

但是，不要太早高兴。 这句话可能包含很多线索，请好好分割。

先找他要解决的核心问题，然后以核心点为中心，整理前、后、左、右、上、下的旁系需求点。

按需求点作为子需求进行调查，最后汇总为一个。

以下情况说明。

背景：订单业务类型多，订单退货后需要制作售后服务发票，但由于数量大，需要人工制作，手动制作有出错的风险。

需求：有“添加通过退货订单自动创建售后服务订单的功能”的业务需求，但这只是一句话。

这一句话的需求实际上包括几个具体的订单类型和场景，所以我们必须分割调查。 分割的维度例如是：

自营订单、第三方订单、货到付款订单、预付商品订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，各个维度都相当于小需求。

这里不会一一扩展。

2. 聚合需求法

分割法是将单一需求分割成几个小需求进行调查，聚合法则相反，是找出许多相关小需求的共性，统一成一个大需求来完成。 例如：

由于业务用户分散在不同的部门，各自独立，无限月光、饱满的篮球可能对一个业务流程有相同的需求，或者对相同的功能有相同的优化期望，结果两人分别提出了需求。 产品经理需要找出两者背后的关联性和交叉领域。

然后，统一规划，汇总在一起作为需求进行调查，最终输出整体的需求调查结果。

可以用于调查

三、利用辅助功能调研需求

产品的现有功能，确认现有功能的逻辑

，或者确定新需求方案是否可行。

比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。

最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：

背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。

需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。

分析：需求是很明白的，也有它的意义，但有风险。

因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。

因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。

于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。

测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。

四、“拔萝卜带出泥”的方式调研需求

调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。

举例说明：

背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。

需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。

分析：

第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……

第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……

通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。

坦率的西牛出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。

五、需求得分权重法

该方法的思路就是将需求质量的维度进行权重，然后对需求进行打分，根据最终得分的多少排列顺序。

如表所示，采用五个维度：先`先`重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为30%、30%、20%、10%、10%。

那么一旦对需求打了分，就可以用分数*权重，得到最终得分。

注意：负分的要减。并且为了方便计算，分值最好设置0.5-5.0之间，或者0-10之间。这样避免打分的跨度过大出现较大偏差。

如表所示，需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分为-0.1。

由此可以判断需求的价值顺序为：需求1>需求2>需求3。对于需求3，可以予以淘汰。

以上的维度、分值和权重可以根据实际情况自行设计，但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从，而只是把它当做一个辅助工具。

六、其他需求调研工具

需求调研适合核心环节，该过程就会涉及到很多工具或分析方法，以确保需求调研高效、高质量。

比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。

以上整理自《后端产品经理宝典》。

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交App。

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

题图来自Unsplash，基于CC0协议