B端产品设计：如何用场景需求清单梳理场景？
B端产品基本上是将「线下已有需求」系统化，所以需要「还原业务」，而非「创造业务」。B端产品首先要考虑到产品使用场景，满足用户需求，实现价值。
1
场景是什么呢？是人物、时间、地点/环境、欲望/目标、手段五要素所组成的特定关系。其实就是什么「人」在什么「时候」在什么「地方」出于什么「目的」做了「什么事」。
案例：小王是某公司的开发工程师，早上上班时，来到公司楼下，为了避免迟到，拿出手机打开考勤软件完成了打卡。
人物元素就是「小王」，时间元素是早上上班， 地点元素是公司楼下，欲望元素是为了避免迟到， 手段元素是拿出手机打开考勤软件完成了打卡。
人物元素考虑使用该产品的用户是谁。比如红米的老人机模式，为了照顾老人的浏览习惯，重置交互，字体图标变大；抖音根据你的浏览数据推荐你喜好的视频。
针对时间元素要考虑用户使用产品的时间，是白天、夜晚、上班时、开车的时候等等，比如微信阅读的夜间模式就是更好的满足用户躲在被窝里看书。
地点因素：考虑用户使用产品的地点，是在家里还是在公司？是在地铁上还是在公交车上？
欲望因素：欲望也就是用户的需求。比如下雨天，走出地铁站，忘记带伞的你有买伞的需求。这个过程需求分析一定要到位，不然产品方案就不靠谱，这也就是我们常说的伪需求。
手段因素：也就是产品需求。上述下雨天没带伞，可以买把伞、也可以买一件雨衣，甚至把外套顶在头上，这些都是属于手段，从产品的角度来说手段就是产品需求。
2
为什么要回归场景呢？
举几个没有回归场景的例子。
案例一，小王是一个HRM方向的产品经理，在基础团队协作模块上，用户反馈想要考勤功能，小王没有多加思索，立刻着手画原型图，然后内部评审，接着推进开发。
功能上线后，却收到了大量的负面反馈，原来小王设计考勤的打卡时间没有考虑具体场景，忽略了时间规则，很多用户在凌晨下班以后可以直接打下一天的考勤，很多客户公司的考勤数据混乱。
案例二，小明在一家电商公司做产品经理，有一天，老板给小明提了一个拼团的需求。小明没有仔细了解、厘清需求背后的场景，马上就答应了下来。为了推进需求，小明先是费了很多口舌和运营、研发同学解释这个需求实现的必要性。然后，在围绕需求细节开始讨论时，团队成员争相用「我觉得」表达自己的观点，大家就拼团持续时间、成团人数、拼团流程等细节争得面红耳赤，无法达成统一意见。为什么团队的沟通总是鸡同鸭讲，形不成统一的认知？
所以做产品的时候一定要梳理并描述业务场景，判断场景中需求的价值。 回归场景有助于对内思考和对外沟通。
产品设计的过程是先发散后收敛，因此在动手画原型、写文档之前，我们需要做大量的思考、调研，逻辑基点是用户面临的实际情况到底是怎样的，即回归场景。产品经理想要完成一项任务，需要和多个部门、多个角色频繁地传递用户需求，因此使用一套易理解、贴近实际的沟通方式，而场景就是通行于不同角色之间解决产品问题的语言。
C端产品可以用发散的方式创造场景，从而挖掘需求，而B端产品基本上是将「线下已有需求」系统化，所以需要「还原业务」，而非「创造业务」，无法发散获取，只能还原场景，回归场景。
除了单一场景，B端产品还需要考虑多场景的情况，B端产品的业务链条场，缺少任何一个必备场景都可能无法闭环。很容易忽略低频场景。比如小李是某提供线下门店零售解决方案的SaaS产品经理，在对某区域的便利店经营业务场景进行分析时忽略了一些低频的场景，比如挂单这种分支场景就压根没考虑。结果恰恰是因为这个场景没有考虑到，导致收到了很多客诉，甚至有些商家就干脆不用这个产品了。
在《有效需求分析》（by徐锋）一书中，提到了一个回归场景的有趣案例，引用部分对书中案例进行了简化表达，一起来看看回归场景的奥义是如何体现的吧。
在一次酒店管理系统的建设项目中，酒店前台人员提出了一条需求：请在酒店入住页面增加一个酒店平面图，在图中实时展示出房型、状态和价格信息。
需求分析师小王没有多加思索，直接就针对此项需求与前台人员进行了深入探讨——「平面图是一层一张，还是把所有楼层都整合到一起？」「房态有几种，用文字还是用颜色展示？」小王迅速画好了原型图，初步获得了确认。
然而，到了实际开发的层面，由于开发成本远高于估计，最终实现的方案出现了较为严重的变形，远远达不到业务人员的预期，引起了业务人员的投诉，产生了很大的负面影响。
如果回归场景来看，我找到了最初提出这个需求的前台人员：「我这次来就是想了解您通过这个平面图解决什么问题，以便给您构思一个更加有效的解决方案。」
前台人员接过话题：「因为有时客人过来住，会需要两间甚至更多相邻的客房，而房间号相邻并不意味着房间相邻，我就会经常遇到困难。」我继续问道：「您是如何解决的呢？」
前台人员回答：「我首先会找哪些楼层有足够的客人需要的房间，然后再判断是不是挨着的，由于位置不好判断，所以才想有个平面图。」
所以问题并不在于一定要一个平面图，而是要找到相邻的空房间！
找到了问题之后，我认为应采用更简单的解决方案，于是我跟前台人员边画原型边解释道：「在原来的查询空闲房间的界面上，增加间数，是否挨着的选项，当你指定间数并要求挨着时，系统会查询出满足条件的房间。」前台人员听懂了我提出的解决方案后，爽快表示太好了。
只有回归场景，才能找到业务中真正的问题，从而给出更高效的解决方案。
3
如何用场景需求清单梳理场景？ 为什么要用场景清单呢？
B端和C端不同，B端产品经理通常不是产品的用户，没法依赖自己的经验，而且B端产品同时会有多个角色使用，并且相互影响和制约，需要一开始就梳理清楚场景需求清单。
当我们做业务调研的时候，要根据调研结果找到关键流程，根据流程还原每个流程下的场景，抽离出最关键的类别/流程，以及其中不可或缺的场景，形成核心场景需求清单。需要通过核心场景需求清单来迭代验证（MVP）。
举例说明：
我们在做「完美工事」招聘模块的时候就根据调研结果生成招聘的流程图，这一步尽可能详尽梳理业务流程，因为B端软件研发成本是很高的，一旦发现存在问题推到重来的成本很大。
第二步将场景写出并归类到流程，每个流程下可以写多个有代表性的分支场景，如果有多个角色，也可以写出场景对应的角色，并拆解成需求。图里面角色是按照部门划分的，实际还会更复杂。
确定了核心场景需求清单，一定确认下面三点：
- 清单中的场景是否能够让业务闭环；
- 场景之间是否有有明晰的串联逻辑；
- 清单是否已经是最简版本的，即没有多余的、去掉也不影响闭环的场景。
如果这三点存在问题，需要修改场景清单直到没有问题。
4
总结下，B端产品的需求来源于场景，产品经理通过满足客户需求从而产生价值。因此，B端产品经理面对扑面而来的需求时，更应当梳理场景判断需求的真伪。
一点小经验分享给大家，欢迎关注交流。
