用户故事是抛出来讨论的,大家坐在一块,用故事的方式配合告示贴和画图,一起探讨用户需求。是一种和团队一起建立共识的机制。 并且要用最小化的工作(特性开发)带来最大的效果,也就是做最重要的事情。

第一章:

团队在一起讲述用户故事,通过讲故事的方式,大家获得对产品愿景的一致理解,然后共同创建更好的产品解决方案。 而用户地图是一个模式,团队对整个产品或整个特性达成共识,将大的用户故事进一步拆分。但是前提是提出需求的一方要清晰的知道自己要什么!! 用户故事地图,就是在讲大故事的同时进行故事拆分。

在开始进行用户故事地图的创建的时候,无论是访谈、团队思考还是个人思考,把所有想到的内容写下来,记录成卡片。卡片的优势是方便移动和更加直观,并且对于卡片的移动大家都可以参与,整个讨论更加有参与感。

思考-记录-讲解-摆放 这是讨论或者用户故事地图的操作模式。

第一步:打造框架

也就是思考产品的价值和用户的价值,产品的愿景。 为什么要做这个产品或者这个特性? 用户能从这个产品或者这个特性获得哪些收益? 产品和特性能够解决用户哪些问题?

第二步:刻画用户画像

哪些客户会为产品提供的服务付钱??哪些用户会使用产品提供的服务? 这里需要罗列不同类型的用户(与之相关的),讨论他们能从中得到什么好处,使用的动机,并且开始假设他们的使用方式,他们需要哪些功能。 这是需要完成地域了解需求背景的前提下才能展开。

第三步:针对用户,讲述用户的故事

讲述用户在一天中如何使用产品或特性; 把用户的行为按照从左到右的顺序摆放卡片; 太大的故事,就在大故事下面拆分成一个个小故事; 并在故事下面完善这个故事的细节。 注意:开始的时候聚焦于故事的整体,不要过早陷入细节,在迷失之前,先走一遍整个故事。

第四步:探索细节和可选项

当完成宽度的故事地图后,就可以进行细化了。 细节将包含这些思考: 1、用户在这一步具体要做什么事情? 2、用户在这一步还有其他选择吗?-思考更好的解决方案 3、如何做才能使用户觉得更酷炫? 4、出现问题时如何处理? -会出现什么问题。

完成以上的工作需要穷举,考虑更多的用户,更多的特性,更多的故事细节。 然后再做减法,哪些是不需要的?组成一个最小产品集。 重要的是考虑没有哪些功能就没法工作?

第二章

做计划,是为了更少的开发:MVP(最小可发布产品)

—— 规划发布路线图 绘制了用户故事地图之后,我们将得到一个目前来说完整清晰的产品内容,但是产品的细节或者要做的需求很多的时候,我们需要考虑怎么去分版本的迭代它们。 而制定迭代的界限可以更多的考虑每次发布聚焦于系统外的预期成果来决定系统内需要什么功能,也就是说这个迭代发布的最高效益的目标是什么?关注当下最重要的目标去迭代。一旦有了清晰的目标之后,要做什么,不做什么就会比较清晰了(明确优先级)。而版本迭代的内容就会容易划分了。

在用户故事地图上面,通过胶带作为分割线,把迭代区分出来,对卡片进行上下移动。在每个迭代后面写上少量的文字描述预期能产生的成果,而移动的卡片内容尽可能匹配这个预期结果。

技巧:聚焦于特性的目标成果,即产品发布后用户能使用和感知的东西,切分发布计划应该已成果为导向。

技巧:也可用不同颜色的小便签把各个卡片(故事)进行分类:差异化功能(显著区分于其他竞争对手的功能),搅局功能(针对竞争对手差异化功能),降低成本功能(降低组织运作成本的功能),基础功能(进入市场竞争所需要的基础功能) …….

而关于MVP的定义,不同企业或团队有不同的定义,不能说都是对的和错的,毕竟MVP是通过讨论定义出来的,很难去马上验证是否最小或是否最有效的功能。 而Eric ries的精益创业指出,要把第一个产品当做试验品,其后的版本是不断试验结果(猜测),知道验证产品时对的。

所以最小可行产品是为了验证假设而做的最小规模(金钱成本,时间成本)的试验。

问自己两个问题: 1、最大胆、风险最大的假设是什么?哪些是不确定的? 2、为了消除假设或风险,需要哪些真是的信息?