无论是做产品还是做运营,需求分析都是一个很重要的环节,在本次文章当中,作者给大家带来了一种她所学习到的需求分析方法,一起看看是要如何做的吧。如果你是创业公司、还没用过用户故事地图,请一定试试。 今天给大家介绍的,是来自Jeff Patton的《用户故事地图》当中的需求拆分方法。 一款产品的成功,在于比竞争对手更好地满足了用户需求,而这并不是一件容易的事。这是因为,你或多或少总会在以下3件事上掉坑里:
- 读懂需求本身,能够抓住核心痛点;
- 选择用自己独特的方式来满足;
- 将需求实现拆分成大小不同的故事,比竞争对手速度更快、做得更漂亮。
什么是MVP?
最小可行产品(MVP),是指可以产生预期成果的最小产品发布。这里需要说清楚,“最小”是针对哪些用户而言的?这些用户需要通过软件达成哪些目标? 另外,很少有哪个产品是全新的,往往实在现有产品上增加新的功能或者提升现有功能。所以,又可以讲最小可行方案:最小可行方案是指可以产生预期成果的最小发布方案。 而聚焦于学习、验证第一个MVP发布的假设,还需要设置更小规模的实验和原型来验证我们对最小和可行的猜测,所以,MVP根本就不是产品: 最小可行产品是为验证假设而做的最小规模的实验。如何找到MVP?
很多时候,一个完美产品要做的事情多到我们很快就不堪重负。全部功能的完成,看起来非常重要,但是当我们时候回过头来思考那些特定用户以及用户实现其目标的基本功能时,会发现这些用户和诉求可以用一两句精炼的话来概括。首先,创建用户故事地图
大家来自不同的团队,每个团队都专注于各自不同的领域,但是要交付的是一个产品。大家必须齐心协力交付这个产品,不可以根据各自团队的视角来制定发布计划,必须以可视化的方式展示出所有的依赖。 故事地图用来建立共识,帮助团队以可视化的方式展示依赖关系。 创建故事地图的过程可以帮助发现设计中的坑。我们常常假设其他团队会处理好相关的事情,而实际上他们并不知道自己需要这样做。有时也可以从中发现,有些设计中竟然遗漏了重点特性之间的关键环节。而团队在构建用户故事地图的过程中,可以提前发现被遗漏的部分。 召开一个用户故事地图的讨论会议吧! 你需要做的准备是:- 一个相对不被打扰的空间;
- 一块白板(如果产品复杂,涉及到的用户行为动作较多,可以用地板、玻璃墙等);
- 五个人左右的讨论组(产品、业务、交互设计、运营等,注意人数不宜过多,否则信息会容易失控);
- 便利贴若干(最好有不同颜色)。
其次,划分MVP发布计划
在用户故事地图上划分出第一个发布需要做的内容,其他的在之后的版本中完成。思考过程是这样的:“如果能xx预期里达到xx成果,产品亮相时看起来不错。发布计划中的所有功能都是用户的基本需求,并且是惊艳的,可以让人眼前一亮。” 聚焦于成果,即发布后用户能使用和感知的东西,切分发布计划应该以成果为导向。 接着,划分发布路线图。 整个故事地图包含许多的东西,但是完成所有功能所需的时间是无法接受的,聚焦于最首要的一个目标成果,识别出第一个发布要包含哪些内容。 我们水平划分用户故事地图上的便签,在划分的每一个发布的左边贴上便签,上面写上少量文字描述预期能产生的成果。然后在各个发布之间移动卡片,尽可能匹配各个发布的成果预期。这样,在整个地图的左侧,是发布的名称列表,这些名称标识着目标成果。这就是发布路线图。 聚焦于特定的目标成果,这是排定开发工作优先级的秘密。 最后,为成果排列优先级,而非功能。 拆分大型输出的秘密在于聚焦于小的、特定的成果。成果的背后是参与特定活动的特定用户之特定行为的改变。通过聚焦于即将发生的活动,选择参与活动的用户。但是,聚焦于活动用户,无法同时满足其他用户的需求,这些用户在比较长的一段时间内还是继续通过现有系统来满足需求。你无法一次性取悦于所有人。小结
你的工作不是开发软件,而是比竞争对手更好地满足了用户需求。使用故事地图输出MVP的发布计划,为了更少的开发,为了更快的学习,为了按时发布。 而你在做用户故事地图的时候,记得这三件事:- 尽可能全面地描述用户故事;
- 可视化你的用户行为;
- 站在地图前重新审视:下一个开发阶段,我们要实现什么?
【转载说明】  若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com