编辑导读：B端产品更加依赖于后端部分的支撑，一些公司也习惯于将这些后端提供支撑的部分，称为“后端产品”。由于后端产品部分的复杂性，因此负责这部分的产品经理，需要做更多、更深入的需求调研工作，才能完成方案设计。本文作者对此进行了分析，与你分享。

前后端分离的实现方式，使得每一个完整的产品体系都包含了前端和后端部分。

相对而言，B端产品更依赖于后端部分的支撑。

一些公司也习惯于将这些后端提供支撑的部分，称为“后端产品”。

后端产品甚至不具有视觉化，而仅仅是一些中间件等。

后端产品如冰山之下，却承担相当重要的幕后工作：支撑、运算、监控、调度、分配、统计分析、决策……

由于后端产品部分的复杂性，因此负责这部分的产品经理，需要做更多、更深入的需求调研工作，才能完成方案设计。

一、后端需求调研

需求调研，是需求分析的前题。

需求分析，是产品方案决策的前题。

从需求调研到产品决策，占据了产品经理80%的工作精力。

由于调研和分析往往一起完成，所以在本文中我门统一将二者以“需求调研”代替。

按通用的模型表达方式，我们可以简单画下：

如上图：需求调研是一个过程，其产物是解决方案。

后端需求研调，与前端需求调研很大的区别。比如用户的角色化、业务的全还原、场景的穷举、新旧逻辑兼容等。

我们简单说下期中的用户、业务和兼容性的话题：

1. 用户

后端产品的用户非最终的价值用户，而是服务人员（如客服、运营）。

因此这些用户具有业务垂直性，是格式化的“人”，具有戒色性和行业属性。

不同职位不同权重，关心的价值目标、决策权、使用人数不同。

不同用户的具体使用场景不同。

可以较容易的获取前端产品用户画像，因为我们自身或者所熟悉的人都在扮演着 前端的角色，也就意味着设计过程中也很容易进行角色代入。

而后端用户画像的获取往往艰难得多，最快捷的方式就是和公司的业务层交流，业务部门是最直接与客户打交道的，他们熟知大量的典型客户案例，可以帮助我们快速高效的描绘出用户画像。

由于我们自身与后端用户的相剥离性，用户画像的作用显得尤为关键，可以时刻提醒我们是在为谁做设计，每一个关键诉求都在产品设计中有对应的抓手。

2. 业务

• 业务目标——>诉求——>用户需求。
• 业务手段——>途径——>产品功能。

了解业务最好的方法，是轮岗参与业务环节中去。此外，更加便捷快速的方法，是调研访谈。

调研之前，最好对业务能有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。

调研方式：访谈、数据分析、问卷调查、头脑风暴、德尔菲、观察，完成用户需求的收集；通过亲和图、提示清单等，整合需求信息。

调研目标：

• 了解业务模式和业务特点
• 了解业务目标和业务规划
• 了解当前业务运转方式
• 挖掘当前问题与痛点

对于后端产品，场景往往是很多的，需求的逻辑性大于故事性，需要由远及近规划处业务场景地图，才能勾画出业务架构，最终聚合出产品生态。

在这个过程中，可以借助用户故事地图等等手段。

通过整个业务的架构，厘清整个平台的用户对象、业务关系，也就确定了整个产品的业务边界范围，确定了整个团队内的业务语言。

3. 新旧逻辑兼容

掌握后端产品逻辑真相的密码通常在开发手里，但是开发常常也需要临时查代码。

在这种情况下，所有对旧功能的迭代都充满着风险。

于此同时，无论是集成的大系统，还是拆开的烟囱林立服务，各个体系之间总是有逻辑调用。比如接口、公共数据等。

后端产品大约60%的bug都是来自于这种牵一发而动全身的逻辑耦合。

唯一能确保系统安全的办法就是做深入的可能影响的调研。

为了避免空谈，我们结合《后端产品经理宝典》一书，介绍需求调研落地的常用方法，和需求的类型。

二、需求调研的落地方法

1. 过滤需求的方法

做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。

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

过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。

1）用户场景模拟法

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

如果不能帮助用户，那么这个需求就可能是伪需求。

以下面的案例说明：

• 背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。
• 需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。
• 分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。

因此，该需求是个伪需求，应该被过滤掉。

2）功能归属分析

专门的系统做专职功能，有助于合理的产品体系建设。

因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。

如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：

• 背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。
• 需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。
• 分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。

所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。

之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；

其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。

结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。

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

2. 拆分和聚合的方法

1）拆分需求法

收到的需求，很可能只是短短的一段话。

但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：

先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。

每个需求点再当做一个子需求进行调研，最后再聚合在一起。

以下面的案例说明：

• 背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。
• 需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。
• 分析：该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：

自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。

这里不一一展开。

2）聚合需求法

拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：

由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。

然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。

3. 利用辅助功能调研需求

调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。

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

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

• 背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。
• 需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。
• 分析：需求是很明白的，也有它的意义，但有风险。

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

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

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

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

4. “拔萝卜带出泥”的方式调研需求

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

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

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

分析：

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

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

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

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

5. 需求得分权重法

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

可以采用五个维度：重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为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，可以予以淘汰。

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

6. 其他需求调研工具

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

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

三、需求的类型和态度

笔者对B端或泛后台产品需求的一个定性划分：粗浅需求、噱头需求、踢球需求、过剩需求、建设性需求。

1. 被动的粗浅需求

这类需求，属于想当然的需求，不考虑系统的兼容性和业务兼容性的。

比如：电商场景中，要求：若库存为0，则果断给予下架；库存变为非0，果断自动上架。

这种强制自然是存在极大风险的。并且库存为0也有曝光的价值；非零也有下架的场景。二者不等同。

这种情况下实际是“概念偷换”的错谬，无库存=下架。

对这类需求，产品可以持保留态度，持续观望，收集更多用户的深层次数据反馈。但不能轻举妄动。

2. 战略的噱头需求

这种很好理解，很多公司其实都是这么玩没的。

比如：看到竞争对手有的功能，我们要有；对手无的，我们也要有。这样可以显得产品更强大。

或者是强行“组合创新”：一个做医药电商的，你让他做直播带货，且不说是否合规，你能想象药师在店里当着店长的面做网红吗？

这种情况下实际是“感觉谬误”。理论上，产品经理需要拿数据论证的。

所以产品经理能做的就是慢点做，保留资源。找机会慢慢把意见渗透到高层，试图止损。

3. 隔壁的踢球需求

在多组织的团队中，这种踢来踢去丢需求的情况相当普遍。

比如，对医药商品，配置一段免责声明，展示在商城。

那么让商品后台在商品维度加字段并传给前端，看似从后端到前端，且商品维度的，似乎没错。但是没必要的。

因为，这是共性字段，商品维度几乎不需要重复维护，也没有操作差异性。

这类需求，产品经理需要从分工、系统职能、收益考虑，将事情客观表述出来，完成博弈。

4. 客服的过剩需求

这类需求，往往是客服传达来自用户的需求。通常目的很明确，但是对功能设计进行了干涉，可能影响产品的分析。

比如，客服传达某O2O用户的需求：要在商品的实际销售价旁边，展示线下零售价格。

产品：然后呢？

客服：若对比到差异，则修改线上价？

产品：怎么修改？

客服：在线下零售价的基础上按公式计算，比如上涨1%，得出线上零售价，然后逐个编辑。

产品：是否可以理解为，目的是让线上价格，按自己期望的卖，不取线下零售价？

客服：是

产品：那么为什么不在根源处理呢：创建一组用于线上销售的价格，直接引用不就可以了吗？

这类问题，一定是要挖掘到用户的场景的，从用户的场景下寻求同理心，不受制于现有功能的设定。

只有这样才能不受局限，找到用户的初心。以解决问题为标准。

5. 产品经理的建设需求

所谓建设性需求，可能是每个产品经理心中都有的夙愿。前提是，产品经理的决策正确。

比如：自主优化产品模型，拆分微服务，界面统一等，统筹规划和重构的类的内容。

若前四类需求过多，将会挤压产品的建设性需求。

产品经理能够腾出手来做一些真正正确的事情，往往能对全局带来增益。

#专栏作家#

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

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

题图来自Unsplash，基于CC0协议