网站需求分析(如何进行有效需求分析)

  欢迎来到大型情感类专题:如何进行有效需求分析——业务场景篇!场景二字,或许我们再熟悉不过了,在整个产品的实现过程中,它都是这么的如影随形。场景是很具体的,因为它是客观存在的,我们凭借肉眼,就能够捕捉到它;但场景又似乎很抽象,我们每天都要纠结场景到底是什么,场景与功能之间到底有什么联系。今天,就让我们一起来探究一下场景的奥秘吧!

网站需求分析(如何进行有效需求分析)内容回顾

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

  分工产生的原因:规模、风险、专业;业务流程三个管理要素:审核、规则、异常;业务流程五个基本要素:分工、活动、协作、产物关系、分支;业务流程的起点即外部服务请求;业务流程的终点即满足服务请求;业务流程的优化策略:“ESIA分析法”。

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

  业务流程是指不同岗位之间通过协作满足外部服务请求的过程;而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动;管理层用户关注事到事的逻辑,他们关注的核心是业务流程;而操作层用户则更关注人到事的逻辑,他们关注的核心是业务场景。思维方式

网站需求分析(如何进行有效需求分析)

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

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

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

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

  目的意义

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

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

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

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

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

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

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

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

  呈现形式

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

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

  用户故事三要素:

  1. 角色(who):谁要使用这个;

  2. 活动(what):要完成什么活动;

  3. 价值(value):为什么要这么做,这么做能带来什么价值。

  用户故事3C原则:

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

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

网站需求分析(如何进行有效需求分析)

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

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

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

网站需求分析(如何进行有效需求分析)

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

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

  从用例图中,我们能看到什么?

  增删改查的功能,这跟场景没有半毛钱关系啊,并且一句话能说清楚的事情,还画个图有什么意义啊…..

  我们再来看一张用例图:

网站需求分析(如何进行有效需求分析)

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

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

  场景分析

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

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

  第一步,场景细化:将场景细化为事件流,先整理出用户预期的正常步骤,然后写出变化的情况;第二步,问题/挑战识别:针对每一步骤,站在用户的角度来思考他们会遇到什么问题,面对什么样的挑战;第三步,思考应对方案:针对这些问题,思考系统应该提供什么样的解决方案。

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

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

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

网站需求分析(如何进行有效需求分析)

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

网站需求分析(如何进行有效需求分析)

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

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

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

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

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

网站需求分析(如何进行有效需求分析)

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

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

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

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

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

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

网站需求分析(如何进行有效需求分析)

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

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

  彩蛋

  足球解说一般都是这样的:

  “有个球员接到球后,有路沉底、底部传中、中路突破,球进了!”

  而用户听你说话时,似乎在听这样的足球解说:

  “有个球员接到球,向自己右上方45°角传球7米,另外一个球员接球后向自己的右上方30°角传球3米,这时跟上的球员向正前方推射1米,球进了……”

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

  结语

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

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

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

  相关阅读

  如何进行有效需求分析?(三)

  如何进行有效需求分析?(二)

  如何进行有效需求分析?(一)

  网易云音乐,送你一张【小纸条】

  晓庄同学;公众号:晓庄同学产品笔记,人人都是产品经理专栏作家。智慧校园领域的B端产品经理。

  本文原创发布于人人都是产品经理。未经许可,禁止转载

  题图来自Unsplash,基于CC0协议

  以上就是关于《网站需求分析(如何进行有效需求分析)》的详细内容,更多的信息请关注新闻频道其它相关资讯!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 22673576@qq.com 举报,一经查实,本站将立刻删除。