2020-10-27日客套企业名录搜索软件新增45728条企业名录资源,注册提取>>>

这是Product Monk产品管理教程的的第七章。全部章节目录参见本文

目前为止,你已经了解了用户在不同阶段所面临的挑战,及其可能的解决方案。用户故事(user story)可以帮助我们在团队之间,高效沟通功能的详细描述。用户故事有助于让每个人都保持在同一基础上。

用户故事是从用户或客户的角度,对所讲述功能的简短描述。他们通常遵循一个简单的模板:

作为一个<用户类型>,我想要<一些目标>,(如果可以的话)这样<一些原因>。比如“作为一个消费者,我希望可以在网上买到化妆品,这样我没空出门的时候也可以即时补给化妆品了。”用户故事可以帮助你将功能需求传达给工程团队。这样,工程团队就更容易理解:他们为什么要构建这个功能,它将如何给用户带来好处,或者用户将如何使用它。

如何编写用户故事?

你应该写一个史诗般的用户故事,然后把它分解。

这个史诗(Epic)是指非常大、而且抽象的用户故事,它源自用户画像和用户旅程映射。它告诉产品应该为用户做什么(对应用户画像/客户旅程映射中,提供的用户目标)。它可以让你在不提交细节的情况下,勾画产品功能。这对于描述新产品和新功能特别有帮助:它让你捕获大致范围,并为了解如何最好地满足用户需求,争取了时间。

一旦这个史诗准备好了,就可以把它分解成更小、更详细的故事,直到它们都具备三点:清晰、可行、可测试。例如,某个功能描述为:“我想和朋友分享我的照片”。这可以被分解成——我想和朋友在Facebook、Twitter、Insta、WhatsApp分享我的照片,等等。这些都形成了不同的用户故事。

让我们看一下在第4章(用户旅程映射部分)使用的例子——用户预订酒店。让我们来看看在发现阶段的一个史诗叙述:作为用户,我希望在一个带有适当过滤器和信息的地图上,看到酒店搜索的结果。以上叙述可以进一步分解成更小的用户故事:

  • “作为用户,我应该能够在地图上查看结果,这样我就不必在结果列表视图和地图位置之间来回切换了。”
  • “当我移动地图查看其他区域时,结果应该根据新位置得到更新”
  • “作为用户,我应该能够在地图视图中查看我需要的信息(价格、评分、星级、照片)”
  • “作为用户,我应该能够在地图视图中应用过滤器(价格,评级)”

以打车服务的旅程映射为例,我们可以写下以下史诗,并进一步分解为更小的用户故事。

用户故事的验收标准

创建了用户故事之后,要为用户故事添加验收标准。验收标准是为了将故事标记为已完成,必须满足的条件。验收标准对用户故事做了完善,使其可测试,并确保用户故事可以向用户和其他利益相关者,进行演示或发布。

考虑下前面例子中,第一个用户故事:

“作为用户,我应该能够使用我的位置,这样可以看到我附近可用的出租车”。

验收标准可以是:

  • app应该能够检测我的位置,并在地图上指出来。
  • app应该能够接收任何位置的文本输入,并在地图上指出来。
  • 一旦确定位置,附近可用的出租车应显示在地图上。

评估用户故事的标准就是:I.N.V.E.S.T.

  • 独立(Independent):用户故事应该是独立的,因为任何依赖都会使它们之间的优先级难以区分
  • 可协商(Negotiable):实现细节没有指定,它们由团队来决定
  • 有价值(Valuable):用户故事对客户应该是有价值的
  • 可评估(Estimable):它们应该被分解成团队可以开展工作的最简单形式
  • 小(Small):它们应该足够小,可以在一个冲刺(Sprint)内完成
  • 可测试(Testable):可以根据指定的验收标准,对这个增量交付进行测试

在哪里编写这些用户故事?

你可以使用类似Google表单这样的简单解决方案,也可以使用如Trello、Jira、Aha、Craft以及许多其他工具的高级方案。

用户故事评估

工作量评估是很困难的。因为传统软件开发团队以时间(小时或天)来提供估算。然而,许多团队(遵循敏捷开发实践)使用基于评估的故事点数进行估算。

故事点数(Story points)就像一种货币,它告诉你开发一个用户故事,需要付出相当于多少的努力。故事点数使用斐波那契数列格式,对工作的相对工作量进行排序,格式为: 0、0.5、1、2、3、5、8、13、20、40、100。这种抽象可以帮助团队用更少的工作量对工作的难度,做出艰难的决定。下面的矩阵(由Dan Olsen编写)有助于指导如何将故事点数分配给用户故事。

简单来说,你也可以根据以下定义来分配故事点数:

  • 1个点数——我非常清楚需要做什么,也非常清楚如何去做。
  • 2个点数——我非常清楚需要做什么,但我需要做一些研究或实验,弄清楚如何去做。
  • 3个点数——我大部分了解需要做什么,对于如何去做也了解一些。(但完全否定这个故事,是大概率不会的)
  • 如果用户故事拥有的故事点数高于5点或8点,那么它们通常被分解成更小的用户故事。

规划扑克(Planning Poker)评估技术

在这种方法中,团队成员拿到的卡片上,写有基于斐波那契数列的数字。协调人(通常是产品经理/负责人)提供用户故事的简短介绍,团队成员将展示用户故事的卡片。评估点数的任何差异都要被讨论。通常,在对评估点数的最低值和最高值进行一两轮讨论之后,团队会达成一致意见。

下一章,我们将看看如何验证你的MVP。