欢迎关注大型情感类主题:有效需求分析——商务场景篇! 场景这个词,我们可能已经不熟悉了,但在整个产品实现过程中,它就是这样的影子。 场景很具体,它是客观存在的,所以我们能用肉眼捕捉到它; 但是场景似乎很抽象,我们每天都在烦恼场景是什么,场景和功能之间有什么联系。 今天,一起探索场景的神秘吧!
内容回顾
上一期介绍了业务流程方面的知识,按照惯例,我们先一起回顾一下。分工产生的原因:规模、风险、专业; 业务流程的三个管理要素:审核、规则、异常; 业务流程的五个基本要素:分工、活动、合作、产物关系、分歧; 业务流程的起点是外部服务请求业务流程的结束是满足服务请求。 业务流程优化策略:《ESIA分析法》。 业务流程和业务场景紧密相连,是分阶段联系在一起的关系。 在开始本论文的正题之前,我先给您这两句话。
业务流程是指不同岗位之间合作满足外部服务要求的流程,业务场景是以一个岗位为中心完成的,是相对独立的、可以报告的业务活动,管理层关注事物逻辑,他们关注的核心是业务流程,操作层的用户是以业务场景为中心的人
思维方式
。一切行为的变化,都源于思维方式的变化。 我把这两句话单独做成一张照片也是为了能引起大家的重视。
我们需求分析系列的第一篇文章探讨了“产品思维”和“技术思维”两种不同的思维方式,而上图中的两个词在用户场景这一阶段进一步体现了两种思维方式。
图中的红色箭头,不知道是多少人难以逾越的鸿沟。 大多数情况下,我们“以需求分析为名,结出了功能分解的果实! ”。 对号入座的同学请举手~
想法的转变真的很难。 这不仅需要我们坚定的信念,也需要我们的实践。
目的意义
首先,我们研究业务场景的目的意义是什么? 你可能会说研究商业场景一定是为了进一步的需求分析吧。 是的。 这确实是目的的意义,但这个描述太模糊了,商业场景带来的不仅仅是这些。
价值传递的介质
我曾经在自己的跳槽报告中提到过价值驱动和任务驱动的相关内容。 我认为无论我们做什么,都应该明确其目的和意义。 并不是单纯地为了完成上司说的任务而进行工作。需求,经过层层传播,最终被开发接受的,可能只是功能。 于是,“这个需求为什么这么确定? 你可能经常听到“”的声音。 “我不知道。 产品经理是这么决定的。 ”然后随着时间的推移,产品经理自己可能也会忘记为什么会有这个需求。
这导致队伍后劲不足,不知道一个人做这件事有什么意义时,很痛苦。 业务场景完美地充当价值传递的媒介,为整个团队带来自我防卫力。
沟通交流的基准
有几个同学的需求审核会议,开着开着最后一场产品经理的吐槽大会。 基于产品更好的“初心”,它们的开发和售前越走越远,就越无法自拔。 毕竟,生气产品的机会,不要错过机会。天使的脸,恶魔的心,很多问题像脱缰的野马一样横冲直撞! “人家某产品做的这个功能有多好? 我们为什么不加? ”、“这些功能竞争对手也有啊。 我们也做这些有什么好处呢? ”,“你有没有想过,用一个小功能,做这么复杂的事情,开发成本? ……
即使有三寸不烂之舌,这个时候也很难防止大家的嘴变得拘束。 因为他们都以发散的思维方式提出问题。 既然招式看不见,你也不能有效地进行防御和反击。 最后身心疲惫,不得已说了一句“上司/客人是这么要求的! ”然后在一万匹草泥马奔腾而过的心情中,会议结束了。 他们也说:“这些都是你YY的需要啊! ”他用询问和轻蔑的目光看了看。
那么,如何才能让他们“迷走”呢? 其实很简单。 所有交流都需要一个标准。 否则,就会演变成喋喋不休的争论。 需求交流的标准是业务场景。 我们只能从一个维度交流。 作为用户角色,我们希望完成活动以实现价值。
呈现形式
商业场景如此重要,你怎么表达它? 商业场景最典型的表现形式莫过于两种:用户故事和用例图。
用户故事
其实刚才我们接触了用户故事。 作为用户的角色,我想完成活动以实现价值。 这是用户故事的典型描述格式。用户故事3要素:
1 .角色(世卫组织) :谁会使用这个;
2 .活动(假设) :完成哪些活动;
3 .价值(value )为什么要这么做,这样做能产生什么价值?
用户故事3C原则:
卡片(Card ) :用户故事一般写在小便条卡上。 卡片上可能会写故事的简短描写
述,工作量估算等;交谈(Conversation):用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确认(Confirmation):通过验收测试确认用户故事被正确完成。这些抽象的理论介绍完了,那我们来看看,到底怎样记录这个用户故事吧:
我们可以看到,用户故事小卡片包含三类信息:
故事标题;故事描述;规则描述:为了完成故事,有时需要制定故事的实现规则,涉及的名词定义等。规则描述由产品经理初步制定,在故事讨论后,进行修订确认。写作方式就是一条条穷举列出。用例图
不知道有没有同学画过这样的用例图:
嗯,不瞒各位,反正我之前是这样画的~
然鹅,这就是非常典型的技术动词+业务名词命名的伪用例!
从用例图中,我们能看到什么?
增删改查的功能,这跟场景没有半毛钱关系啊,并且一句话能说清楚的事情,还画个图有什么意义啊…..
我们再来看一张用例图:
这次大家看到的是什么?是不是这样就能够看到用户场景了?其实这样难么?答案是一点都不难,两张图对应一下,同样表达的仍然是增删改查嘛。这就回到了我们开篇所说的内容了,最重要的,还是思维方式的转变!
关于用例图的画法已经很成熟了,这里不再赘述,大家有兴趣的可自行查阅资料。
场景分析
在目的意义的段落里面,我们说到了,研究场景的目的在于进一步的需求分析。那么我们接下来看一下,应该如何对场景进行分析呢?
分析方法:场景—挑战—方案三步法
第一步,场景细化:将场景细化为事件流,先整理出用户预期的正常步骤,然后写出变化的情况;第二步,问题/挑战识别:针对每一步骤,站在用户的角度来思考他们会遇到什么问题,面对什么样的挑战;第三步,思考应对方案:针对这些问题,思考系统应该提供什么样的解决方案。莫急,莫急,是不是觉得这些加粗的知识点太干了,我们这就给出一个案例来润润喉:
旅游这个事情大家肯定都有所体会,那如果是让我们做一个在线旅游服务网站的需求分析,我们该怎么做呢?我们就拿“行程计划”这个场景为例,一起来分析一下吧。
第一步
将场景细化为事件流,这个根据大家的自身经历,是很容易列举出来的,我这里直接给出答案:
然后呢,我们写出变化的情况。我们分析一下,在第二步是不是可能发生变化?比如这种安排时间不够,或者是钱不够……然后我们把这两种可能存在的变化情况,也记录下来:
第二步
我们来思考一下,整个过程中用户都会遇到什么问题或者挑战吧。
确定计划去的景食娱购点,大家想一下自己旅游的经历,这里最大的问题,是不是一直纠结到底去哪里好呢?旅行回来,如果大家问起你去了某某地方没,如果说没,别人说那你这旅游都白去了,这将是多么郁闷的一件事情啊。
确定先后顺序以及预计花费时间,这个最大的困难莫过于不知道这些兴趣点之间的距离,应该如何换乘交通工具,以及每个兴趣点需要花费多长时间。
同样的,准备相应的行李这一步,我们是不是也会纠结带一些什么行李好呢?用不用防晒霜,穿运动服呢,还是休闲装也行,用不用防虫剂等等。
我们把这些也都记录到表格当中:
第三步
我们来看看针对这些问题,应该提供什么样的解决方案吧。
对于不知道有哪些,怕遗漏这种问题,我们设计成类似购物车如何?然后加上“十大建议”、“分类查看”、“游客必去”等推荐功能,来强化体验;
对于不知道距离、游玩时间以及交通的问题,我们在地图上显示出所有的兴趣点,然后标注出每个景点的游玩时间,推荐路径、两点间交通建议以及预计耗时,同时统计总时、总钱,这样是不是就能够解决问题了;
对于该带哪些行李这个问题,就更好解决了,我们给出一个必备物品清单,以及天气情况,注意事项等,这些足够让用户确定带什么行李了吧;
对于时间不够、钱不够的变化情况,我们直接在地图上将某个景点剔除,系统自动重新计算花费的总时、总钱,这就OK啦。
最终,我们对于场景分析,会得出这样的表格:
好了,一份完整的场景分析到此结束,接下来是不是就可以探讨技术可行性了?
再多说一句吧,以上的分析内容,我是站在“先知”的视角,给出的总结性内容。大家在分析的过程中,肯定会遇到诸多困难,也有很多额外的工作要做,例如业务理解啊,竞品分析啊等等。这里提供给大家最重要的,还是这种思维方式。
彩蛋
用户听你说话的感受
足球解说一般都是这样的:
“有个球员接到球后,有路沉底、底部传中、中路突破,球进了!”
而用户听你说话时,似乎在听这样的足球解说:
“有个球员接到球,向自己右上方45°角传球7米,另外一个球员接球后向自己的右上方30°角传球3米,这时跟上的球员向正前方推射1米,球进了……”
这就是与客户沟通时,你带给他的感觉。所以说,赶紧转变思维方式吧,不然你就是用户眼中的“code monkey”!
结语
个人觉得“业务流程”与“业务场景”是需求分析过程中最最重要的内容了,当二者分析完毕之后,我们就可以“明目张胆”地开始讨论功能了。
另外,在上周我们分析了网易云音乐,拓展线下场景的【小纸条】功能,大家可以从场景的分析与场景的应用,两个不同维度感受一下其中的奥妙。
需求分析系列剩余的内容已经不是很多了,我尽量一期,最多两期为大家总结完毕。让我们下期不见不散吧。
相关阅读
如何进行有效需求分析?(三)
如何进行有效需求分析?(二)
如何进行有效需求分析?(一)
网易云音乐,送你一张【小纸条】
#专栏作家#
晓庄同学;公众号:晓庄同学产品笔记,人人都是产品经理专栏作家。智慧校园领域的B端产品经理。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议