B端产品如何进行业务全场景的需求梳理.docx

B端产品如何进行业务全场景的需求梳理.docx

《B端产品如何进行业务全场景的需求梳理.docx》由会员分享，可在线阅读，更多相关《B端产品如何进行业务全场景的需求梳理.docx（9页珍藏版）》请在冰豆网上搜索。

B端产品如何进行业务全场景的需求梳理

Ｂ端产品如何进行业务全场景的需求梳理？

编辑导语：

业务全场景这个词我们总能看见，但是为什么要去做需求梳理呢？

我们又该如何进行业务全场景的需求梳理？

本文作者围绕这两个问题为我们做出了解答，总结出了五个步骤，快来学习和收藏吧。

一、为什么要做业务全场景的梳理？

主要原因有三点：

1.方便沟通

比如：

在产品设计完成，进入开发后，可能会遇到技术问你为什么要开发这个功能，可不可以把几个功能合并成一个功能等等问题。

如果你不能回到业务场景，回到用户使用产品的场景，不能从用户使用场景的角度来回答、沟通问题，那么很多时候会造成沟通的不顺畅，以及产品推进受阻的现象。

2.回到原点思考

我们经常讲，产品经理在具体工作的过程中，往往思考的时间要比画原型图、写文档的时间还要多，才是比较合理的时间分配。

思考什么？

需要思考的内容很多，但其中有一点一定非常重要，那就是：

回到场景，回到原点去思考，思考用户是在什么场景下遇到了什么问题需要解决，没有基于业务场景而得出的需求，都是闭门造车空想出来的需求。

换句话来讲：

业务场景是产品往下设计的原点，这点工作没做好，后面设计出来的产品可能都没什么使用价值。

3.全场景思考，做到需求不遗漏

如果说，我们分析场景、在找需求时，想到哪里是哪里，而不是从整体的框架去思考。

就容易造成需求有遗漏，产品无法形成闭环。

既然业务场景的梳理这么重要，那应该怎么做呢？

这里，我将会从以下5个方面来讲：

场景要素；

梳理出尽可能详细的业务流程；

基于业务流程找到对应的全场景；

基于全场景找到对应的用户需求；

确定边界（也就是确定哪部分场景需求需要系统支持，哪部分场景需求不需要系统支持，哪部分是手工+系统支持）。

接下来，我将一个一个的讲：

二、场景要素

作为一个产品经理，我们经常会讲到场景，要还原场景。

那么，一个完整的场景应该包含哪些要素呢？

不同的书籍、资料给出了不同的答案。

根据我的经验以及相关资料的参考，用场景7要素就可以把一个场景给还原，给讲清楚，场景7要素分别为：

1.用户

也就是用户是谁，使用者是谁，可以是一个人、或者是某一类人，比如：

小王，创业者，产品经理。

2.环境

可以是时间，空间、地点等约束条件。

比如：

星期一晚上下班回家的路上，公司的销售办公室内。

3.时机

也就是触发用户产生目标的事件或者是影响用户行为变化的环境。

比如：

今天上班，明天周末就要放假了；昨天还是大太阳，今天就下雪了。

4.目标

也就是用户产生的目标，比如：

明年年底前写完一本书，今天中午午饭吃火锅。

5.动作

也就是为了实现目标，采取的一系列动作。

比如：

打开电脑，打开文件，开始打字；拿出充电器、插上电，给手机充上电。

6.载体

就是和什么样的载体发生了互动；比如：

手机，电脑，村委会门口的宣传栏。

7.任务

通过一系列动作，完成了任务。

比如：

炒好了一个菜，爬上了山顶。

场景7要素，用一句话来总结就是：

在某一个环境下，出现了某一个时机，然后某人带着某个目标，通过某个载体，采取一系列的动作，最终完成了任务。

1）案例1：

北京某3A景区经理小王今天早上坐在办公室，想到最近上新了一套门票系统，想把景区相关门票上传到系统供游客查看、购买，于是打开了电脑进入后台、门票管理模块，进行了门票信息的添加，门票信息添加完以后，最后点击提交完成门票的上传。

这个案例当中，小王是用户，今天早上在办公室是环境，最近上新了一套门票系统是时机，想把景区相关门票上传到系统供游客查看、购买是目标，电脑是载体，进行了门票相关信息的添加是动作，完成了门票的上传是任务。

以上场景7要素还可以变成4要素，也就是仅需要4个要素，也能把一个场景给描述清楚。

这4个要素分别是：

用户、环境、时机、事件。

用户、环境、时机的相关解释，文中已提到；事件的意思是要推动什么样的事情就是向前发展。

也就是说，场景4要素里的“事件”，把场景7要素里的“目标、动作、载体、任务”给替代了。

2）案例2：

小张是一家做家居装修公司的销售，星期一早上到公司上班后，打开CRM系统后台看到了线索池里多了一条线索，于是小张在线索池里把线索领取了。

这个案例中，看到线索后，把线索领取了，就是事件。

在实际工作过程中，做场景需求分析时，以上提到的场景7要素和场景4要素都可以灵活匹配运用。

讲完一个完整的场景应该包含哪些要素之后，接下来的所有内容都是围绕“业务全场景需求应该如何去梳理？

”。

三、梳理出尽可能详细的业务流程图

讲到业务全场景，那不得不先梳理出来主业务流程图。

因为，业务场景是由某岗位独立完成、相对独立、可汇报的业务活动。

而业务流程是由不同岗位之间通过协作，满足外部服务请求的过程。

因此梳理出完整的流程图，基本上也就覆盖了需求的全部场景。

所以，这个模块，我们先梳理出尽可能详细的业务流程。

业务流程梳理有3个关键步骤：

一听二问三确定。

一听，听客户的介绍，听的过程中不要打断，不要陷入细节，以最简单的方式把业务主流程梳理出来；

二问，沿着主流程发问，把相关的分支、异常情况，相关规则梳理出来，能加入主流程图的就加入，加入不了的可以重新画流程图，或者是用文字来表示；

三确定，最后给相关的客户或者业务专家讲一遍，做最后的流程确定。

这样，就尽可能详细的把业务流程给梳理清楚了。

案例：

这里以一家民宿门店的预订系统作为案例讲解（本篇文章以下的所有案例都会以这家民宿门店为案例讲解）

1.一听

听客户的讲解，梳理出主业务流程图，如下：

2.二问

根据主流程发问，把相关的异常情况、分支流程、相关规则梳理出来，补充进流程图（图中标红部分则是补充），如下：

其中，有1个异常情况，流程图中不好加进去，用文字来表示，如下：

熟客或者店长朋友提前打电话来预订，需要工作人员预留房间。

3.三确定

确定你梳理的民宿预订系统业务流程，是否有补充或者不同意见。

最终，就把住宿预订系统的业务流程给梳理出来了。

四、基于业务流程找到对应的全场景

基于以上民宿门店业务流程图，梳理出对应的全场景如下图：

在梳理业务全场景需求时，我们经常会遇到困惑，到底业务场景的颗粒度多大比较合适。

担心自己做的业务场景分析颗粒度比较大，又或者担心自己做的颗粒度比较小。

场景颗粒度的标准如何界定，我个人认为《有效需求分析》中，有一段话的界定，我比较认同：

一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。

因此从某种角度来讲，粒度是由组织分工决定的，就像我梳理出的全场景图中分的颗粒度一样。

比如：

游客查看下单；经理确认订单；游客收到短信通知。

这3点我把它分为3个不同的场景，因为这3者分别都是独立、可汇报、可暂停的单元。

五、基于全场景找到对应的用户需求

基于以上民宿门店全场景图，梳理出了对应的全场景需求，如下图：

补充：

画出来的全场景需求图中，场景与需求的对应关系是一对多的关系。

也就是一个场景中有多个需求，比如，全场景需求图中的第一个场景，这个场景中就有：

发布房型，管理房型两个需求。

六、确定边界

确定边界，也就是确定哪部分场景需求需要系统支持，哪部分场景需求不需要系统支持，哪部分是手工+系统支持。

为什么要确定？

有一句话不这样讲嘛：

什么是产品？

产品就是有边界的解决方案。

因此我们需要从梳理出的全场景需求图中，确定哪部分场景需求需要系统支持，哪部分场景需求不需要系统支持，哪部分是手工+系统支持。

梳理出的结果如下图：

图中“加红”部分需求，不需要系统支持，也就是通过公众号查看有什么好吃的不需要系统支持。

图中的游客订单12小时之内，商家未进行订单确认，需要自动退款，短信通知，这个需求就需要系统支持。

其它部分场景需求，需要手工+系统支持。

最后做个总结：

在进行全场景需求梳理时，可以从以下5个方面来梳理：

场景要素；

梳理出尽可能详细的业务流程；

基于业务流程找到对应的全场景；

基于全场景找到对应的用户需求；

确定边界（也就是确定哪部分场景需求需要系统支持，哪部分场景需求不需要系统支持，哪部分是手工+系统支持）。