在刚做产品的时候，总听人说要理解场景，要摸清场景，那今天首先来聊一个问题：什么是场景？
每个人对于场景都有自己的定义，像比较耳熟能详的5个W，人物因素、时间因素、地点因素、欲望因素、手段因素。那么笔者对于场景的定义就是：什么人，在什么时间，什么地点，有什么样的欲望/需求，而现在是用什么手段来解这个需求的。那么按这个定义我们继续来分析。
1.什么人
什么人，一般指的是人物因素，也就是明确在这个场景下主要角色是谁。当然在这里也要考虑其他非主要角色会不会也会在这个场景有需求。比如在后厨需要一个管控全局菜品出餐的大屏，一般我们是给到后厨管理人员比如厨师长来管理后厨使用，但是在实际场景中，还要多挖掘一下其他人员是否对该屏幕有不同的诉求，避免场景遗漏。
2.在什么时间
时间因素比较简单，白天还是晚上，上班还是下班等等。但是存在一些细节场景，是不涉及具体时间点的。比如打语音电话的过程中，对方突然发来一张图片需要查看，这个时间因素就是打语音电话。
3.什么地点
一般就是指产品使用地点，争议较少。
4.有什么样的欲望/需求
欲望因素，也就是希望达到的目的，也就是用户需求。比如下雨天要从地铁站里出来，这时候地铁门口有一个卖伞的小摊。可能到这里大家就会认为需求、及满足需求的场景已经都由了。需要一把伞就去买一把伞结束了。而实际上可能用户的目的是快速到家，可能家里有很多把伞了，只要能很快的打到车，不一定要买一把伞。因此分析需求是，一定不要被现有的解决方案给迷惑了，需求分析的目的是清楚人物之中希望达到的目的是什么！
5.用什么手段来解决这个需求
需求的解决方案，就是最终产出的需求。
为什么总是要先沟通场景？
很多人在初做产品时，都是接到需求后马上开始产出方案，后续进入评审时就开始受到各种挑战，还要回炉重造，有的人甚至开始怀疑人生。笔者看来都是需求场景没有理解清楚，理清需求场景主要有两点好处：
1.有助于自己分析正确的需求内容
产品人做需求，一定要做到先发散后收敛。要将每一个场景涉及道德因素超细致，然后在对已经拆解出来的细致结论产出解决方案，再去除解决方案中，可实现最小闭环之外不必要的一些功能。其实最终结论很可能和最初设想的一样，但是你考虑的很清晰了，不会在担心评审过程被挑战或其他未考虑到的点所影响。
2.有助于对外沟通
对外就是对外部进行宣讲。一个产品功能的上线是一群人辛苦的结晶，谁都不希望自己产出的内容没有任何价值。因此在产品方案评审时，实际上就是将你的想法灌输到其他人的脑子里，你需要对多个部门，多个角色进行交流和说服，因此场景要简单易于理解，要用贴近现实故事的描述形式来场景。
如何从场景中产出需求？
第一步：根据上述流程沟通的出来场景，进而产出业务流程图。在这里一定要详尽梳理业务流程，每个业务动作有哪些分支，方便拆解需求。
第二步：将场景归类，并明确场景类型和对应角色，并简要描述角色实际场景
第三步：收缩需求范围，确定最小MVP
1.首先确定场景是否完全闭环，场景之间是否完全衔接，是否有明确的串联逻辑；
2.确定当前已经厘清的场景需求清单是否已经是最简版本，存不存在一些不相关的需求，去掉也不影响此次版本上线
如果存在以上两个问题，需要持续修改到没有问题。
总结
B端产品一般都是靠业务驱动，需求场景一般都较为复杂，所以在设计产品前需充分了解需求场景，厘清需求，才能更好的判断需求真伪，不做无用功。
