如何在淘宝购物_用户故事：如何在敏捷开发中助力产品需求策划？

产品经理的日常主要工作是处理需求。许多产品经理都希望如何快速准确地洞察用户或客户的需求，并让功能直接触及用户的痛点。作者发现用户故事的使用可以有效地帮助产品经理解决产品需求规划的问题。

不久前读过一本书“敏捷软件开发:用户故事战斗”。顾名思义，整本书是关于如何在敏捷软件开发中使用用户故事来开发和迭代客户需求。

“故事”在百度百科中的定义是:通过叙述讲述一个有寓意的事件，或陈述一个过去的事件，当事件发展时侧重于描述当应用于软件开发过程时，用户故事可以理解为描述用户使用软件功能的过程。整本书

表达了如何在敏捷项目中使用用户故事思维进行产品开发的想法。因此，用户故事法适用于敏捷项目。

换句话说，对于具有明确产品需求和目标的敏捷开发项目，用户故事的使用更有利于满足客户需求的功能开发。

目前，在实际的产品工作中，处理需求的过程往往涉及到需求场景的整理。读完这本书，我感受到了一些用户故事的想法和方法，这些想法和方法有助于理清日常需求场景。以下是根据书中的理解，对用户故事在实际开发过程中的过程和用法的描述。

1。这本书的想法:具体过程

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

1。识别用户角色

通过分类识别该需求的用户，然后根据该需求角色对用户角色建模。简而言之，它通过发散和收敛的方法识别初始角色，然后聚合、分类和去重复，最后形成几个典型的用户角色，并同时抽象出相应的用户肖像

2。结合用户故事

根据分类的用户肖像结合各种用户角色的用户故事，编写用户故事的过程实际上是一个从发散到收敛的过程。

如果公司有客户拜访和调查的条件，可以直接与客户沟通，那么用户故事自然是相对客观的。如果你不具备采访客户的条件，你只能利用想象中的场景进行头脑风暴。

3。故事评估

这个阶段主要是评估用户故事和评估故事的排序列表。它主要针对故事的理想实现时间、复杂性以及对团队和客户的价值。

评价可以给每个故事一定的评价，以客观地显示这些故事点的重要性在这一阶段，故事评估中使用的评估值不仅可以确定优先级，还可以评估比率。

4。计划发布

创建发布计划时，您需要确定故事优先级和迭代速率优先级评估的方法类似于需求优先级评估的方法书中提到的四个评估重点是必要的、应该有的、可以有的和不需要有的。当然，这不是随机决定，而是根据故事评估阶段中每个故事的估计值进行排序，并与估计迭代速率相结合，即通过计算估计值来确定每次迭代的故事点数。

5。验收测试

验收测试阶段发布的主要测试的故事已经完成了吗？书中建议最好的客户可以参与验收，但实际上，对大多数公司来说，这种条件是不存在的。

讲述了在整个开发过程中使用用户故事的故事。此外，这本书还提到成对编程可以用于技术开发，这可以极大地降低返工率，并最大程度地优化代码架构。

总之，本书描述的开发过程不同于互联网上0-1的产品开发，因为它是一个敏捷开发项目，所以这个过程是基于明确的产品需求和目标的前提，没有需求挖掘的过程，计划迭代是通过调查和用户故事计划的方式直接进行的。

2。用户故事有助于改善产品用户场景。

产品经理的日常主要工作是处理需求。如何快速准确地观察用户或顾客的需求是许多产品经理的愿望。开发的功能直接触及用户的痛点。

在分析需求时，通常根据需求的三个要素:用户/角色、场景和任务路径，对目标用户的核心需求进行分类

产品目标用户的真正需求通常是在真实的业务场景中产生的，这在B端产品中尤其明显。因此，在收到需求后，在进入功能规划阶段之前，对完美的核心场景进行梳理是非常重要的。

那么如何使用用户故事来帮助我们整理出完美的场景呢？可以分为三个步骤

1。梳理目标用户的肖像，梳理目标用户对应的核心使用场景

C终端产品通常有几个典型的用户肖像，而B终端产品也不例外，也可以梳理出几个典型的客户肖像对应自己的产品。

根据2/8定律，虽然这些类型的典型用户/客户可能只占所有注册用户的20%,但他们通常可以涵盖产品中80%的功能，或者可以贡献80%的产品收入。

因此，在梳理产品用户的核心场景时，我们应该首先调查这些用户的使用场景。

2。在根据典型用户

的核心场景分割需求对核心场景进行排序后，从场景中提取核心需求。此时的需求应该最接近用户/客户的真实期望用文字描述场景可以被编译成一个表格列表用于后续的校对。

表列表示例

3。需求点被用户故事

转换成从核心场景提取的需求点，用户故事

可以被进一步细化成单个或多个故事点

产品需求在一定程度上可以理解为故事。在描述需求时，用户实际上是在描述用户期望的使用场景，这可以理解为用户描述了他们传递/使用的情况、材料和行为。

，但是当我们提取需求时，我们经常有很多一句话的需求，并且关于这个需求的细节不能很好地反映出来。即使许多需求点不一定是功能点，通常需求只是一个目的，但有不止一种方法可以达到这个目的。

因此需要通过用户故事的方法来提炼需求场景，这样便于全面分解当前需求，丰富用户场景。需求规划阶段的决策更加可靠，功能设计更加全面。

3。解释如何结合本书写一个用户故事。1.在用户故事

的值确定了目标用户肖像和核心使用场景之后，在规划特定功能之前，用户的使用场景应该被分类，然后以用户故事的形式列出。用户故事可以用来计划和提示某个需要的功能，有助于丰富使用场景的细节。用户故事的列表可以稍后被优先化，以确定哪些用户故事应该被优先化。

2。用户故事的特点是独立的:每个故事尽可能独立，相互依赖的故事可以组合成一个更大但更独立的故事；对用户或客户有价值:客户真正关心的故事，能够真正解决用户的问题，满足用户的需求；可估计的:用于后续产品开发中的工作量估计。为了便于项目控制，必要时应该拆分故事点。可测试性:测试人员可以根据用户的故事直接测试故事点是否已经成功开发。小:可以尽可能量化和评估单个用户的故事，以确保每个故事尽可能小，这样故事的细节就可以很容易地被穷尽。

3。用户故事示例

在了解用户故事的价值和特征后，以“115”产品中的录音功能为例。当我们从核心场景中提取一些需求点时，我们需要进一步扩展这些需求点，以便于后续的需求规划和原型规划用户故事

"记录"功能:用户可以在115上快速添加记录，并可以直接选择一个记录类别进行添加；用户可以自己创建记录分类。添加记录后，它们可以被分类到某个分类下。用户在录制时支持文本编辑和本地图片上传；当编辑记录时，用户可以在记录时添加用户的位置信息。编辑记录时，用户可以选择拍照并上传。用户添加的记录支持注释标签，根据标签可以找到记录；用户可以复制和粘贴记录的文本内容。用户可以选择部分文本记录内容，并将其快速转换为待办事项或日程。用户可以用下划线或星号来标记单个记录。编辑记录时，用户可以实时查看文本框中当前编辑的字数

这篇文章最初是由@王书发表的。每个人都是产品经理。未经许可，根据CC0协议

张图片