新媒易动态
NEWS CENTER
NEWS CENTER
2020-03-23
需求调研是需求实现的前提。
需求调研主要内容有：了解需求背景、明确需求目标、过滤不当需求、确定大致方案。
需求的用户是谁？需求解决的核心问题是什么？使用场景有哪些？哪些是主要和次要场景？业务的流程是什么？除了主要业务还有哪些流程可能使用这个功能？除了本系统还有哪些系统会关联到这个功能……
这就是需求调研的“十万个为什么“。
本篇结合《后端产品经理宝典》书中的内容，单从需求调研案例出发，看几种常用的调研方法。
做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。
这不是一个贬义词，反而是体现后端产品价值判断的基础。
过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。
后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。
如果不能帮助用户，那么这个需求就可能是伪需求。
以下面的案例说明：
背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。
需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。
分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。
因此，该需求是个伪需求，应该被过滤掉。
专门的系统做专职功能，有助于合理的产品体系建设。
因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。
如果不属于该系统范畴，那么直接说服需求方更换方案。以
下面的案例说明：
背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。
需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。
分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。
所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。
之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；
其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。
结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。
否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。
业务用户提出一个需求，很可能只是短短的一段话。
但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：
先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。
每个需求点再当做一个子需求进行调研，最后再聚合在一起。
以下面的案例说明：
背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。
需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。
该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：
自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。
这里不一一展开。
拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：
由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。
然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。
调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。
比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。
最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：
背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。