如何进行有效需求分析（4）场景篇

原创： 啊庄    公众号： 晓庄同学产品笔记

欢迎来到大型情感类专题： 如何进行有效需求分析——业务场景篇！

场景二字，或许我们再熟悉不过了，在整个产品的实现过程中，它都是这么的如影随形。 场景是很具体的，因为它是客观存在的，我们凭借肉眼，就能够捕捉到它； 但场景又似乎很抽象，我们每天都要纠结场景到底是什么，场景与功能之间到底有什么联系。 今天，就让我们一起来探究一下场景的奥秘吧！

内容回顾

上一期我们讲述了业务流程的相关知识，按照惯例，我们先来一起回顾一下：

• 分工产生的原因： 规模、风险、专业；

• 业务流程三个管理要素： 审核、规则、异常；

• 业务流程五个基本要素： 分工、活动、协作、产物关系、分支；

• 业务流程的起点即外部服务请求； 业务流程的终点即满足服务请求；

• 业务流程的优化策略： “ESIA分析法”。

业务流程与业务场景是环环相扣、层层递进的关系，在开始本文的正题之前，先把这样两句话送给大家：

业务流程是指不同岗位之间通过协作满足外部服务请求的过程； 而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动；

管理层用户关注事到事的逻辑，他们关注的核心是业务流程； 而操作层用户则更关注人到事的逻辑，他们关注的核心是业务场景。

思维方式

一切行为的改变，都源自于思维方式的转变。 我单独将这两句话做成一张图片，也是为了能够引起大家的重视。

在我们需求分析系列的第一篇文章中，我们就探讨了“产品思维”与“技术思维”的两种不同思维方式，而以上图中的两句话，则是两种思维方式在用户场景这个阶段的进一步体现。

图中的红色箭头，不知是多少人难以逾越的鸿沟。 大多数情况下，我们都在 “以需 求分析之名，行功能分解之实！” （对号入座的同学请举手~）

思维方式的转变，真的很难，这不仅需要我们坚定不移的信念，更需要我们千锤百炼的实践。

目的意义

先来说一下，我们研究业务场景的目的意义是什么呢？ 你也许会说，研究业务场景肯定是为了进一步的需求分析呀。 没错，这的确是目的意义之所在，但这个描述太过笼统，而且业务场景所能带来的，也绝不止这些。

价值传递的介质

我曾经在自己的转正述职报告中，提到过价值驱动与任务驱动的相关内容。 我觉得我们做任何一件事情，都应该明确其目的和意义，而不是单纯地去为了完成上级交代的任务而去开展工作。

而需求这种东西，经过层层传递，最终开发接收到的，可能就只剩功能了。 于是，我们或许经常会听到这种声音： “这个需求当初为什么这么定呢？ ”“我也不知道，产品经理就是这么定的。 ”并且随着时间的推移，产品经理可能自己也会忘记当初为什么要做这个需求了。

这会造成团队的后劲不足，当一个人对正在做的事情，不知道有何意义时，是很痛苦的。 而业务场景，则完美地充当了价值传递的介质，为整个团队带来自驱力。

沟通交流的基准

有多少位同学的需求评审会议，开着开着最后开成了产品经理吐槽大会。 那些开发与售前，本着让产品更好的“初心”，在吐槽的道路上越走越远、无法自拔，毕竟怒怼产品的机会，那可是机不可失时不再来呀。

天使的脸庞，魔鬼的心肠，一大堆问题就像脱了缰的野马一样狂奔不止！ “你看人家某某产品做的这个功能多好，为什么我们不加上呢？ ”，“这些功能我们竞争对手也都有啊，我们也做这些有什么优势呢？ ”，“一个小小的功能，你搞这么复杂，你考虑过开发成本吗？ ”......

纵使你有三寸不烂之舌，此时也难以抵御众人的口若悬河啊，因为他们全是以发散性的思维方式提的问题。 既然招式无形，你也就无法有效地进行防御与反击。 最后身心疲惫，不得已说一句： “老板/客户就是这么要求的！ ”然后在一万只草泥马奔腾而过的心态中，会议结束。 而他们也都投来了质问和鄙夷的目光： “原来这些都是你YY的需求啊！ ”

那怎样才能让他们“迷途知返”呢？ 其实也很简单，所有的沟通都要有一个基准，不然就会演变成喋喋不休的争论。 而需求沟通的基准就是业务场景。 我们只从一个维度进行沟通： 作为一个<用户角色>，我想要<完成活动>，以便于<实现价值> 。

呈现形式

既然业务场景这么重要，那我们怎么把它给呈现出来呢？ 业务场景最经典的呈现形式莫过于两种，一种是用户故事，另外一种是用例图。

用户故事

其实在刚才，我们已经接触过用户故事了 ： 作为一个<用户角色>，我想要<完成活动>，以便于<实现价值> 。 这就是用户故事的经典描述格式。

用户故事三要素：

1. 角色（who）： 谁要使用这个；

2. 活动（what）： 要完成什么活动；

3. 价值（value）： 为什么要这么做，这么做能带来什么价值。

用户故事3C原则：

1. 卡片（Card）： 用户故事一般写在小的记事卡片上。 卡片上可能会写上故事的简短描述，工作量估算等；
2. 交谈（Conversation）： 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
3. 确认（Confirmation）： 通过验收测试确认用户故事被正确完成。

这些抽象的理论介绍完了，那我们来看看，到底怎样记录这个用户故事吧：

我们可以看到，用户故事小卡片包含三类信息：

1. 故事标题；

2. 故事描述；

3. 规则描述： 为了完成故事，有时需要制定故事的实现规则，涉及的名词定义等。 规则描述由产品经理初步制定，在故事讨论后，进行修订确认。 写作方式就是一条条穷举列出。

用例图

不知道有没有同学画过这样的用例图：

嗯，不瞒各位，反正我之前是这样画的~

然鹅，这就是 非常典型的技术动词+业务名词命名的伪用例！

从用例图中，我们能看到什么？增删改查的功能，这跟场景没有半毛钱关系啊，并且一句话能说清楚的事情，还画个图有什么意义啊.....

我们再来看一张用例图：

这次大家看到的是什么？ 是不是这样就能够看到用户场景了？ 其实这样难么？ 答案是一点都不难，两张图对应一下，同样表达的仍然是增删改查嘛。 这就回到了我们开篇所说的内容了，最重要的，还是思维方式的转变！

关于用例图的画法已经很成熟了，这里不再赘述，大家有兴趣的可自行查阅资料。

场景分析

在目的意义的段落里面，我们说到了，研究场景的目的在于进一步的需求分析。 那么我们接下来看一下，应该如何对场景进行分析呢？

分析方法： 场景—挑战—方案三步法

第一步，场景细化： 将场景细化为事件流，先整理出用户预期的正常步骤，然后写出变化的情况；

第二步，问题/挑战识别： 针对每一步骤，站在用户的角度来思考他们会遇到什么问题，面对什么样的挑战；

第三步，思考应对方案： 针对这些问题，思考系统应该提供什么样的解决方案。

莫急，莫急，是不是觉得这些加粗的知识点太干了，我们这就给出一个案例来润润喉：

旅游这个事情大家肯定都有所体会，那如果是让我们做一个在线旅游服务网站的需求分析，我们该怎么做呢？ 我们就拿“行程计划”这个场景为例，一起来分析一下吧。

第一步： 将场景细化为事件流，这个根据大家的自身经历，是很容易列举出来的，我这里直接给出答案：

然后呢，我们写出变化的情况。 我们分析一下，在第二步是不是可能发生变化？ 比如这种安排时间不够，或者是钱不够......然后我们把这两种可能存在的变化情况，也记录下来：

第二步： 我们来思考一下，整个过程中用户都会遇到什么问题或者挑战吧。

确定计划去的景食娱购点，大家想一下自己旅游的经历，这里最大的问题，是不是一直纠结到底去哪里好呢？ 旅行回来，如果大家问起你去了某某地方没，如果说没，别人说那你这旅游都白去了，这将是多么郁闷的一件事情啊。

确定先后顺序以及预计花费时间，这个最大的困难莫过于不知道这些兴趣点之间的距离，应该如何换乘交通工具，以及每个兴趣点需要花费多长时间。

同样的，准备相应的行李这一步，我们是不是也会纠结带一些什么行李好呢？ 用不用防晒霜，穿运动服呢，还是休闲装也行，用不用防虫剂等等。

我们把这些也都记录到表格当中：

第三步： 我们来看看针对这些问题，应该提供什么样的解决方案吧。

对于 不知道有哪些，怕遗漏 这种问题，我们设计成类似购物车如何？然后加上“十大建议”、“分类查看”、“游客必去”等推荐功能，来强化体验；

对于 不知道距离、游玩时间以及交通 的问题，我们在地图上显示出所有的兴趣点，然后标注出每个景点的游玩时间，推荐路径、两点间交通建议以及预计耗时，同时统计总时、总钱，这样是不是就能够解决问题了；

对于 该带哪些行李 这个问题，就更好解决了，我们给出一个必备物品清单，以及天气情况，注意事项等，这些足够让用户确定带什么行李了吧；

对于 时间不够、钱不够 的变化情况，我们直接在地图上将某个景点剔除，系统自动重新计算花费的总时、总钱，这就OK啦。

最终，我们对于场景分析，会得出这样的表格：

好了，一份完整的场景分析到此结束，接下来是不是就可以探讨技术可行性了？

再多说一句吧，以上的分析内容，我是站在“先知”的视角，给出的总结性内容。大家在分析的过程中，肯定会遇到诸多困难，也有很多额外的工作要做，例如业务理解啊，竞品分析啊等等。这里 提供给大家最重要的，还是这种思维方式。

彩蛋

用户听你说话的感受

足球解说一般都是这样的： “有个球员接到球后，有路沉底、底部传中、中路突破，球进了！ ”

而用户听你说话时，似乎在听这样的足球解说： “有个球员接到球，向自己右上方45°角传球7米，另外一个球员接球后向自己的右上方30°角传球3米，这时跟上的球员向正前方推射1米，球进了......”

这就是与客户沟通时，你带给他的感觉。所以说，赶紧转变思维方式吧，不然你就是用户眼中的“code monkey”！

结语

个人觉得“业务流程”与“业务场景”是需求分析过程中最最重要的内容了，当二者分析完毕之后，我们就可以“明目张胆”地开始讨论功能了。

另外，在上周我们分析了网易云音乐，拓展线下场景的【小纸条】功能，大家可以从场景的分析与场景的应用，两个不同维度感受一下其中的奥妙。

需求分析系列剩余的内容已经不是很多了，我尽量一期，最多两期为大家总结完毕。 让我们下期不见不散吧。

如果我有帮助到您，也希望您能够帮助我一下，您点击的每一次“在看”，每一次的分享，每一次的赞赏，哪怕是一块钱，都是笔者不断前行的动力。晓庄同学在此叩谢！