如何规范有效的通过业务场景做好产品调研

产品包工头 2023-07-27 10:22:53

“你把业务场景说一下？”这是产品经理会经常说的一句话，的确，业务场景是产品经理用于需求调研的一种策略，但是大部分情况下我们得到的反馈却是一句话业务场景，我遇到过需求方就会说：“我需要退货，让门店快速退货”。

对于B端产品经理，如何规范而有效的通过业务场景做好产品调研工作呢？

产品设计成功的关键因素是它与业务需求的关联程度，以及能否有效的支持用户实现其业务目标，在这里业务场景就非常重要，可用于帮助识别和理解业务需求，从而得出产品方案必须解决的业务需求。

业务场景是用业务术语与产品术语一起对业务需求的完整描述，将单个需求和其他需求关联在一起，放在整个问题的背景环境中审视和讨论。

一般业务场景有以下几个组成元素：背景环境、业务流程、执行该场景的人员（或者系统组件）、期望产出结果。

这里的背景环境很重要，如果缺失了背景环境，业务需求就是不完整的，产品设计价值不明确，就会导致潜在的产品设计方案存在一定的风险性；一个好的业务场景能够表达出重要的业务需求或问题，并使产品经理及开发者充分了解产品解决方案对用户的价值体现。

通常情况下，良好的业务场景是“smart”的：

具体的（Specific）：定义业务中需要完成什么？
可衡量的（Measurable）：通过成功的明确衡量指标。
可付诸行动的（Attainable）：明确的划分问题，为确定的产品方案的计划提供基础资源。
切实可行的（Relevant）：可在物理实现、时间、技术和成本约束的范围内解决。
有时限的（Time-bound）：产品解决方案的生命周期有明确的说明。

业务场景

想要得到正确且完整的业务场景并非易事，首先，你的用户知道他们想要什么，但是无法表达出来或者准确的传达。

作为产品经理，你仍然必须了解业务，了解业务场景中最重要的参与者：

花时间，观察并记录他们是怎么工作的；
从关键负责人那里了解关键业务规则；
专注于需要完成的事情以及熟悉它是如何被完成的。

这样做，会给业务需求到产品实现提供锚点，应该有勤奋且批判的态度，对后续的工作大有益处。

下面我们看一下如何实现一个业务场景的构建？这有一套业务场景方法矩阵，包括整体流程和每个分解步骤：

业务场景

1）识别，记录驱动场景的问题

用户调研问题尽可能表达成类似于流程步骤的描述：“需要做什么”，而不是“如何做”；提出有助于确定问题存在于何处和合适发生的问题：“您会在哪里遇到这个问题，在哪个业务流程中？是流程开始前还是过程中”等一些问题，同时，可以了解下问题的成本：问题本身的成本有哪些，是否存在其他隐形的成本；

2）识别该场景下的业务环境并将其记录

把问题放在整体的大环境去看，可以参照PESTEL分析模型，虽小题大做，但思路却相仿：

环境：识别这些问题困扰的关键过程及主要步骤，比如上述场景中的退场审核环节导致整体流程较慢
政治：存在这个问题的内部业务部门，比如门店店长
社会：相关联的外部合作伙伴，比如供应商运输司机
法律：存在该情况的具体的业务规则和章程，比如退货操作指导
技术：技术约束及应用到的技术原则，比如订单必须产生作业指令，才能操作退厂
经济：该场景下的资金支持程度，比如投入研发资源不足

3）确定并记录预期的目标结果：符合“SMART”原则

和用户确定预期的目标，目标依据要足以支撑目标，比如：投资收益、合规性、易用性及可伸缩性，这就是我们说的需求价值维度，要细化和量化目标价值；

那需求方的一句话需求，我们就可以通过引导需求方进行细化：“现在退货比较慢，阻碍了业务发展，我希望到2020年3月份，在门店的店长，需要在2天内快速完成和供应商的退货交接，从退货发起到商品供应商带走，并完成退货单；退货效率提升60%，人工成本降低80%，我们可以给你100人天的资源预算去完成这项产品研发工作”这样听下来，比一句话需求是不是就明确很多了！

4）确定主要参与者及其在业务场景中的位置

主要参与者代表与系统交互或在系统内部交互的人员。主要参与者通过触点与产品交互，例如：计算机用户与计算机、采购员与采购系统

但是，主要参与者在产品使用过程中代表用户扮演的角色；他们是一个用户，也是一个角色。每个主要参与者以不同的方式使用系统（否则他们应该是同一参与者）。从不同的角度询问将涉及的人员，例如：审批领导、运维专员、操作员、管理员

5）识别系统参与者及其在业务场景中的位置

参与者可以是人，也可以是一个计算机系统，甚至一段代码逻辑，确定了人的角色，也要把无声的系统参与者识别出来，确定他们必须做什么？比如自动补货自主下单、自动接单平台自动分发单据等

6）识别并记录每个参与者的角色，职责和工作的衡量指标；

定义好产品中的角色后，需要确认他们的职责、任务及衡量的指标，在什么节点和条件下需要作出什么样的动作等，都要进行确认；

7）检查业务场景的适用性，并在必要的节点进行细化；

最后，检查一下是否具有足够的信息去识别什么可以满足该需求，若没有，则在必要的节点和关键流程进行更深入的调研，让用户给予更多的业务输入，直到可以评估业务场景及解决方案；

在上述每个流程中，为了确保每一步稳定输出，还需要将每一个阶段的流程进行分解，分三步走：收集、分析最后进行确认：

第一步：收集

收集阶段是为了收集各方面的信息，可以使用多种方法，例如情报研究、定性分析、定量分析、调查、信息资料等；在面对面交流之前，应收集尽可能多的信息并提前尽可能处理多的信息；例如，信息资料可以提供例如战略计划和运营方案，这样的文件资料通常可以提供更加深入的见解，但是其中包含的信息通常需要进行大量的预处理；如果可能，该信息可用于在研讨会之前生成业务场景的初始草稿；这将增加产品经理的理解力和信心力，以及研讨会对参与者的价值。

收集信息的一种非常有用的方法是组织业务场景沟通会，通过该会议，产品经理通过一系列问题引导一组精选业务代表，以获取有关产品工作所要解决的问题的信息，沟通会参与者必须从组织的业务中精心挑选。

重要的是——能够挑选一批对业务熟悉且愿意表达的需求方；沟通过程中，尽可能引用真实的案例，增加与会沟通的需求方的代入感，极大的强化了业务场景。

第二步：分析

在分析阶段，其实完成了许多实际产品工作；处理和记录收集的信息，并创建相关业务场景模型（流程图、矩阵图、业务逻辑），以形象化的方式表达出来。

分析阶段利用产品经理工作的知识和经验来产出所捕获信息所必需的模型，根据调研沟通记录，去做一个筛选和翻译，翻译成产品和业务的语言表达出来；这个过程中，一定要保持业务场景关键元素之间的联系。

有助于创建将业务流程与以下各项联系起来的矩阵：

主要支持者
主要参与者
系统参与者
议题
目的

这样，业务流程就成为非常有意义且有约束力的聚焦点，因为在大多数情况下，每个人都在寻求对业务流程的优化和提升。

第三步：确认

在确认阶段，将结果反馈给需求方及项目牵头人，以确保对业务场景的整个范围及影响深度有共同的理解，建议与项目牵头人和需求方举行多个业务场景确认会；通过公开且互动的方式，并在会议上进行场景演练，以便大家对业务场景达到一致的理解，并能检验产品经理自己的对业务场景的理解是否正确；这个阶段非常重要，因为在许多情况下，期望和目的的偏差是产品失败的根本原因。

完成以上所有的业务场景调研活动后，会收获一些业务场景的结论和定稿，建议输出一份业务场景的文档制品，将上述所有的信息进行书面化；业务场景文档要求在确保体现场景细节，这样可以防止存在遗漏的关键点，同时，也有利于相关者进行后续的沟通和确认。

最后，附带一个业务场景的结构文档供参考和使用：

业务场景