B端产品需求调研（确定需求背景）

B端产品需求调研（确定需求背景）

作为产品经理，当你接到需求时，是直接摩拳擦掌开始梳理需求流程呢还是首先进行需求调研呢？作者从经验出发，对B端产品的需求调研进行了梳理总结，与大家分享。

需求调研的第一步是确定需求背景，那么应该如何确定需求背景呢？

一、何为需求？需求=预期-现状

需求是用户在产品使用过程中对产品的预期和使用现状的差距；B端产品的使用者为个人，但实际服务对象是企业或组织，企业使用B端产品的目的是为了降本增效，帮助企业解决实际问题提高工作效率，当问题未得到解决或未得到高效解决的时候，就会产生需求。

以商家管理系统中的订单筛选功能为例，在商家管理系统中，平台会为商家提供订单筛选功能，筛选字段包括订单状态、物流状态等；订单筛选功能作为搜索框架的一部分，核心要解决的问题是帮店主快速精准的定位到他要找的某类订单，并将同一类型的订单聚类展示；映射到实际的应用场景中，店主A昨天直播卖货俩小时，产生1000条新订单，一觉醒来发现新增500条退货申请，他速速打开商家管理后台要统一查看哪些商品被退货了，但是平台没有按照订单分类筛选的功能，他只能导出订单在excel表格中进行筛选，在excel表格中要看到完整信息还需要调整表格格式，让他格外头疼，这时候就产生了在订单列表中新增按照订单类型筛选的需求。

二、何为需求的背景？

B端产品需求背景是指需求产生的原因及想达到的目标，也就是需要分析谁(who)需要通过怎样的途径(how)去达到什么目标(what)，可以提炼为what、who、how三个核心元素：

what:是指本次项目目标，在进行背景分析时，我们需要明确项目目标，在明确项目目标的前提下，可更清晰的确定需求的边界;

Who：是指本次项目的干系人，包括直接干系人和间接干系人，我们需要尽可能穷尽的确定需求干系人并对其进行用户访谈，通过用户访谈确定干系人目前的问题及其关注点以及需求的重要程度，并以此进行后期的功能设计；

How：是指该项目的策略级实施方案，通过对需求进行背景分析，我们需要确定项目的策略级实施方案，并根据干系人关注点、项目目标、项目资源确定当前最优解决方案。

三、如何进行需求的背景分析？

接下来我将以告警系统为例，从目标的确定、干系人分析、问题分析三个层面来梳理怎样对需求进行背景分析。

1. 确定项目目标

项目目标是贯穿整个项目周期的产品方向，B端项目的目标通常是基于当前的业务形态制定的，且每个版本均需明确该版本的项目目标。

明确的项目目标可帮助我们确定产品的核心功能，一方面产品经理可专注于产品核心功能进行产品设计，在满足核心功能的基础上尽量做功能减法，以确保每个功能每一步操作都是必须的；另外一方面，明确的目标也可以减少时间和开发资源的投入，在项目各参与方都明确项目目标的前提下，需求沟通、产品设计、项目开发、项目验收都会更高效的进行，且明确的目标可减少项目中的需求变更。

而在项目目标不明确的情况下，产品经理对产品核心功能把控不到位，无法明确的判断哪个功能必须要，哪个功能可以不要，最终导致产品中有很多非必须功能，一则影响用户实际使用，二则增加项目成本。

那么，该如何确定项目目标呢？确定项目目标的关键是明确【业务场景+当前情况+目标】；具体的业务场景是需求分析的基础，业务场景具有故事化的功效，可帮助产品经理进行产品设计，也可帮助技术同学理解需求；明确当前情况可确定当前的问题，而目标即是需求人对产品的期望，通过明确现状期望即可提炼出产品需求。

比如在上面所列举的订单列表中增加按照订单类型筛选功能的需求，明确的项目目标是：在商家需要批量查看某种类型商品比如下单但是未付款或者申请退款的商品时，商家无法直接在系统中进行筛选，而是要导出到excel表格中进行筛选，所以本次项目目标是解决商家无法快速精准的批量查看某种同类订单的问题。

2. 确定干系人

确定干系人是需求分析必不可少的一个环节；与C端产品需求分析过程中的用户分析不同，B端产品的干系人分析不仅包括产品的用户(直接使用人)，也包括产品的直接和间接相关人。

确定干系人是为了尽可能穷尽的确定项目相关人员，以进行用户访谈，充分了解项目干系人的关注点以及担心点，更充分的了解业务以便进行产品设计。

如果不明确项目干系人，导致需求调研不充分，可能会在项目开发过程中临时更换需求而导致项目延期；在业务复杂，机构内人员组织架构复杂的情况下，用户调研不充分也可能导致项目上线后才发现项目在符合一方使用需求的情况下影响了另一方的直接利益。

那么我们应该如何判断项目干系人呢？干系人可从目标和风险两个维度进行识别：

（1）根据目标识别关键干系人

1. 直接相关部门负责人：因为直接相关部门通常是该产品的使用部门，通过对该部门负责人进行用户访谈，可以明确该部门员工在产品使用过程中的工作流程，并了解该项目是否会涉及员工kpi考核等问题；
2. 间接相关部门负责人：因为映射到实际业务流程中，间接相关部门会为直接相关部门提供业务支持，在产品设计过程中，也需要考虑他们之间的信息交互等问题；
3. 资深负责人：还需要确认该项目是否存在资深负责人，资产负责人通常对项目有更深层次的认知和期望，所以也要将他们列为访谈对象。

（2）根据风险识别关键干系人

1. 该功能的直接使用人：直接使用人是我们的重点访谈对象，因为直接使用人最熟悉业务流程，明确了解在实际业务场景中哪些是重点，哪里可能会有坑，通过对他们进行用户访谈，可以帮助产品经理更好的理解业务流程且可以规避流程中的风险；
2. 具有一票否决权的评价者：具有一票否决权的评价者通常不是业务的直接或间接相关者，但是为大部门领导，他们对项目可能有产品矩阵或整体生态建设层面的规划，所以也需要认真分析他们的意见。
3. 技术部门负责人：需要和技术部门负责人沟通项目是否存在技术风险，项目前的沟通可以避免项目中的风险，也可以避免出现产品经理已经完成产品设计方案，但是由于技术风险问题不得不推倒重来的情况；明确干系人后我们需要对干系人做基础了解，如干系人在组织架构中的职位、负责的工作、联络方式及合适的联络时间，以便可以在合适的时间点进行用户访谈。

比如在某高端艺术品交易平台的拍卖项目中，我们识别到的关键干系人包括：

1. 负责线上拍卖的团队负责人：需要和直接负责人确定拍卖的具体流程和规则，比如用户参与竞拍是否需要缴纳押金，拍卖的商品金额大致区间，确定能否满足线上支付的要求等问题；
2. 负责仓储和订单的团队负责人：确定商品竞拍成功后大致的发货时间等问题；
3. 负责线上拍卖的运营同学：确定运营同学主持竞拍的具体流程，以及在竞拍过程中系统需要怎样进行支持；
4. 整个拍卖项目的总负责人：确定他对整个项目的项目预期以及规划，以便进行产品规划。

3. 访谈干系人、确定问题并产出策略级解决方案

确定干系人后，需对干系人进行用户访谈，收集干系人当前遇到的问题以及问题发生的频率及影响，再对问题进行归纳整理，进而产出策略级的解决方案。

（1）记录原始问题在进行干系人访谈时，我们需要记录用户对遇到的问题及问题产生的影响的原始描述，原始描述有助于后期对原始需求的追溯。

（2）整理问题并分析影响第二步我们需要对干系人提出的问题进行归纳整理，并分析其影响；问题的影响包括直接影响和间接影响，在分析影响时，需要注意以下两点：

1. 问题的影响需要具体到明确的用户；
2. 阐述影响时需加入合理的推理，合理的推理更令人信服。

（3）产出策略级解决方案明确问题影响后，则可产出策略级的解决方案，并对比不同的解决方案的优缺点，在权衡干系人关注点、问题影响、当前资源等情况后，产品负责人和关键干系人对当前需解决问题的优先级及问题的解决方案达成共识。

以下是B端产品需求背景分析的产物：

写在最后

通过对需求进行背景分析，我们可以深入的了解需求，并通过对相关干系人进行访谈，也可剖析用户深层次的需求以及确定每个子任务的重要程度。