快好知 kuaihz

用户故事:如何在敏捷开发中助力产品需求策划?

产品经理的日常主要工作就是与需求打交道,如何能够快速准确地洞察用户或客户的需求,让功能直击用户痛点是很多产品经理的愿望。而笔者就发现,利用用户故事,可以有效帮助产品经理解决产品需求策划的问题。

前段时间看了一本书《敏捷软件开发:用户故事实战》,顾名思义,整本书大概讲的是在敏捷软件开发中,如何运用用户故事来开发和迭代客户需求。

故事”在百度百科的定义是:通过叙述的方式讲一个带有寓意的事件,或是陈述一件往事,侧重于事件发展时的描述。应用到软件开发流程中,用户故事,就可以理解为是叙述用户在使用软件功能时的过程。

整本书所表达的思想就是:如何在敏捷项目中用用户故事思维做产品开发。所以,用户故事的方法适用于敏捷项目。

换句话说,针对产品需求和目标明确的敏捷开发项目,使用用户故事更有益于开发出符合客户需求的功能。

目前个人在实际产品工作中,处理需求的过程,会经常涉及需求场景梳理,看完本书后,感觉用户故事的一些思路和方法,有助于日常需求场景的梳理。下面就结合书中的理解,说说用户故事在实际开发过程中的流程以及使用方法。

一、本书的思想:运用到实际项目中的具体流程

敏捷项目-用户故事开发流程

1. 识别用户角色

通过梳理识别该需求的用户,然后针对该需求角色进行用户角色建模,简单讲就是通过先发散再收敛的方法识别初始角色,然后聚合分类、去重,最后形成几个典型的用户角色,同时抽象出对应的用户画像。

2. 梳理用户故事

根据整理出来的用户画像,梳理各用户角色的用户故事,编写用户故事的过程其实也是发散到收敛的过程。

如果公司有客户拜访和调研的条件,可以直接与客户进行沟通,那用户故事自然相对客观;如果不具备客户访谈的条件,那就只能发挥场景想象力来头脑风暴了。

3. 故事评估

此阶段主要是评估用户故事,对梳理出来的故事清单进行评估,主要针对故事的理想实现时间、复杂性以及对于团队和客户的价值等方面。

评估时可以赋予每个故事一定的估算值,来客观显示这些故事点的重要性。此阶段故事评估时使用的估算值,既可以排优先级,还可以估算速率。

4. 计划发布

在创建发布计划时,需要确定故事优先级和迭代速率。优先级评估的方法和评估需求优先级的方法类似。书中讲的四种评估优先级为必须要有、应该有的、可以有的、不需要有,当然这不是随便决定的,而是根据故事评估阶段每个故事的估算值来排序,同时结合估算的迭代速率,即通过计算估算值来决定每次迭代多少个故事点。

5. 验收测试

验收测试阶段主要测试发布的故事有没有完成,书中建议是最好客户可以参与验收,但实际对于大多数公司来讲,是不具备这个条件的。

除讲述运用用户故事贯穿整个开发流程外,本书还顺便提到了技术开发时,可以使用结对编程,可大大减少返工率,并最大程度优化代码架构。

总之,本书中描述的开发流程与互联网从0-1的产品开发是有区别,因为是敏捷开发项目,因此流程是建立在产品需求和目标明确的前提下,没有需求挖掘的过程,直接通过调研和规划用户故事的方法进行计划迭代。

二、用户故事帮助完善产品用户场景

产品经理的日常主要工作就是与需求打交道,如何能够快速准确地洞察用户或客户的需求,开发的功能直击用户痛点是很多产品经理的愿望。

平时在分析需求时,大多按照需求的三要素,用户/角色、场景、任务路径来梳理目标用户的核心需求。

可产品目标用户的真实需求,往往就诞生在真实的业务场景里,这点体验在B端产品里尤为明显。因此接到需求后,在进入功能策划阶段之前,梳理完善的、核心的场景就显得至关重要。

那么如何运用用户故事来帮我们梳理完善的场景呢?可以分三步走。

1. 结合目标用户画像,梳理目标用户对应的核心使用场景

C端产品通常都有几个典型的用户画像,B端产品也不例外,也可以梳理出来自家产品对应的几个典型客户画像。

按照2/8定律,虽然这几类典型的用户/客户可能只占全部注册用户的20%,但通常可以覆盖产品中80%的功能,或者说可以贡献产品收益的80%。

因此在梳理产品用户的核心场景时,首先要针对此类用户的使用场景进行调研。

2. 根据典型用户的核心场景拆分需求

梳理完核心场景后,再将核心需求从场景中提炼出来,此时的需求应该就是最接近用户/客户的真实期望了。将场景用文字描述出来,可以整理成表格清单,便于后续整理。

表格清单示例

3. 需求点转化为用户故事

从核心场景提炼出来的需求点,还可以进一步细化为单个或多个故事点。

产品需求在一定程度上可以理解为故事用户在描述需求时,其实就是在描述用户期望的使用场景,可以理解为用户是在叙述他是在何种情境下,通过/使用何种物质,如何完成某个行为的。

但我们在提炼出需求的时候,往往有很多一句话需求,关于这个需求的细节无法很好地体现出来。甚至很多需求点不一定就是功能点,往往需求只是目的,达到目的的方法却不止一个。

因此就需要通过用户故事的方法来细化需求场景,便于充分拆解当前的需求,同时也有利于充实用户场景,在需求策划阶段的决策更有依据,功能设计也更加全面。

三、结合书中理解,说说用户故事如何编写

1. 用户故事的价值

确定目标用户画像和核心使用场景后,在策划具体功能之前,应梳理用户在使用该功能时的场景,然后以用户故事的形式罗列出来。用户故事可以用于针对某个需求功能做计划和提示,有助于充实使用场景的细节。后续可对用户故事清单进行优先级排序,用于决策哪些用户故事应该优先被实现。

2. 用户故事的特点

独立的:每个故事尽可能相互独立,相互依赖的故事可以合并成一个更大但更独立的故事

用户或客户有价值的:是客户真正关注的,可以真正解决用户问题,满足用户需求的故事

可估算的:用于后续产品开发进行工作量估算,必要时要拆分故事点,便于项目管控;

可测试的:测试人员可根据用户故事,直接测试该故事点是否已被成功开发;

小的:单个用户故事尽可能可以被量化和评估,保证每个故事尽可能小,便于穷尽故事细节。

3. 用户故事示例

了解了用户故事的价值和特点后,以“115”产品中的记录功能做个示例,当我们从核心场景中提炼出一些需求点后,就需要进一步将这些需求点展开,便于后续需求规划和原型策划。

“记录”功能的用户故事

用户可在115上快速新增记录,可直接选择某个记录分类进行添加;

用户可自定义创建记录分类,添加记录后可归类到某个分类下;

用户在记录时支持文字编辑和本地图片上传;

用户在编辑记录时,可添加记录时用户的位置信息;

用户在编辑记录时,可选择拍摄照片上传;

用户添加的记录支持备注标签,并且可根据标签查找记录;

用户可以将记录的文本内容进行复制、粘贴;

用户可选择部分文本记录内容,快速转为待办项或日程;

用户可将单个记录进行重点标记或星标;

编辑记录时,用户可在文本框实时查看当前已编辑的文本字数。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:助力  助力词条  敏捷  敏捷词条  需求  需求词条  策划  策划词条  故事  故事词条  
设计

 安慰你的用户

在煎蛋上看到一个比较有意思的文章,顺便也看看下面的回复,突然想起很多有意思的东西,关于情感化设计。我开始思考,是不是在很多时候,在考虑界面精简的同时,我们也需提...(展开)