产品经理的日常主要工作就是与需求打交道，如何能够快速准确地洞察用户或客户的需求，让功能直击用户痛点是很多产品经理的愿望。而笔者就发现，利用用户故事，可以有效帮助产品经理解决产品需求策划的问题。
前段时间看了一本书《敏捷软件开发：用户故事实战》，顾名思义，整本书大概讲的是在敏捷软件开发中，如何运用用户故事来开发和迭代客户需求。
“故事”在百度百科的定义是：通过叙述的方式讲一个带有寓意的事件，或是陈述一件往事，侧重于事件发展时的描述。应用到软件开发流程中，用户故事，就可以理解为是叙述用户在使用软件功能时的过程。
整本书所表达的思想就是：如何在敏捷项目中用用户故事思维做产品开发。所以，用户故事的方法适用于敏捷项目。
换句话说，针对产品需求和目标明确的敏捷开发项目，使用用户故事更有益于开发出符合客户需求的功能。
目前个人在实际产品工作中，处理需求的过程，会经常涉及需求场景梳理，看完本书后，感觉用户故事的一些思路和方法，有助于日常需求场景的梳理。下面就结合书中的理解，说说用户故事在实际开发过程中的流程以及使用方法。
一、本书的思想：运用到实际项目中的具体流程
1. 识别用户角色
通过梳理识别该需求的用户，然后针对该需求角色进行用户角色建模，简单讲就是通过先发散再收敛的方法识别初始角色，然后聚合分类、去重，最后形成几个典型的用户角色，同时抽象出对应的用户画像。
根据整理出来的用户画像，梳理各用户角色的用户故事，编写用户故事的过程其实也是发散到收敛的过程。
如果公司有客户拜访和调研的条件，可以直接与客户进行沟通，那用户故事自然相对客观；如果不具备客户访谈的条件，那就只能发挥场景想象力来头脑风暴了。
3. 故事评估
此阶段主要是评估用户故事，对梳理出来的故事清单进行评估，主要针对故事的理想实现时间、复杂性以及对于团队和客户的价值等方面。
评估时可以赋予每个故事一定的估算值，来客观显示这些故事点的重要性。此阶段故事评估时使用的估算值，既可以排优先级，还可以估算速率。
4. 计划发布
在创建发布计划时，需要确定故事优先级和迭代速率。优先级评估的方法和评估需求优先级的方法类似。书中讲的四种评估优先级为必须要有、应该有的、可以有的、不需要有，当然这不是随便决定的，而是根据故事评估阶段每个故事的估算值来排序，同时结合估算的迭代速率，即通过计算估算值来决定每次迭代多少个故事点。
5. 验收测试
验收测试阶段主要测试发布的故事有没有完成，书中建议是最好客户可以参与验收，但实际对于大多数公司来讲，是不具备这个条件的。
除讲述运用用户故事贯穿整个开发流程外，本书还顺便提到了技术开发时，可以使用结对编程，可大大减少返工率，并最大程度优化代码架构。
总之，本书中描述的开发流程与互联网从0-1的产品开发是有区别，因为是敏捷开发项目，因此流程是建立在产品需求和目标明确的前提下，没有需求挖掘的过程，直接通过调研和规划用户故事的方法进行计划迭代。
产品经理的日常主要工作就是与需求打交道，如何能够快速准确地洞察用户或客户的需求，开发的功能直击用户痛点是很多产品经理的愿望。
平时在分析需求时，大多按照需求的三要素，用户/角色、场景、任务路径来梳理目标用户的核心需求。
可产品目标用户的真实需求，往往就诞生在真实的业务场景里，这点体验在B端产品里尤为明显。因此接到需求后，在进入功能策划阶段之前，梳理完善的、核心的场景就显得至关重要。
那么如何运用用户故事来帮我们梳理完善的场景呢？可以分三步走。
C端产品通常都有几个典型的用户画像，B端产品也不例外，也可以梳理出来自家产品对应的几个典型客户画像。
按照2/8定律，虽然这几类典型的用户/客户可能只占全部注册用户的20%，但通常可以覆盖产品中80%的功能，或者说可以贡献产品收益的80%。
因此在梳理产品用户的核心场景时，首先要针对此类用户的使用场景进行调研。
2. 根据典型用户的核心场景拆分需求
梳理完核心场景后，再将核心需求从场景中提炼出来，此时的需求应该就是最接近用户/客户的真实期望了。将场景用文字描述出来，可以整理成表格清单，便于后续整理。
表格清单示例
从核心场景提炼出来的需求点，还可以进一步细化为单个或多个故事点。
产品需求在一定程度上可以理解为故事，用户在描述需求时，其实就是在描述用户期望的使用场景，可以理解为用户是在叙述他是在何种情境下，通过/使用何种物质，如何完成某个行为的。
但我们在提炼出需求的时候，往往有很多一句话需求，关于这个需求的细节无法很好地体现出来。甚至很多需求点不一定就是功能点，往往需求只是目的，达到目的的方法却不止一个。
因此就需要通过用户故事的方法来细化需求场景，便于充分拆解当前的需求，同时也有利于充实用户场景，在需求策划阶段的决策更有依据，功能设计也更加全面。
确定目标用户画像和核心使用场景后，在策划具体功能之前，应梳理用户在使用该功能时的场景，然后以用户故事的形式罗列出来。用户故事可以用于针对某个需求功能做计划和提示，有助于充实使用场景的细节。后续可对用户故事清单进行优先级排序，用于决策哪些用户故事应该优先被实现。
独立的：每个故事尽可能相互独立，相互依赖的故事可以合并成一个更大但更独立的故事；
对用户或客户有价值的：是客户真正关注的，可以真正解决用户问题，满足用户需求的故事；
可估算的：用于后续产品开发进行工作量估算，必要时要拆分故事点，便于项目管控；
可测试的：测试人员可根据用户故事，直接测试该故事点是否已被成功开发；
小的：单个用户故事尽可能可以被量化和评估，保证每个故事尽可能小，便于穷尽故事细节。
了解了用户故事的价值和特点后，以“115”产品中的记录功能做个示例，当我们从核心场景中提炼出一些需求点后，就需要进一步将这些需求点展开，便于后续需求规划和原型策划。
用户可在115上快速新增记录，可直接选择某个记录分类进行添加；
用户可自定义创建记录分类，添加记录后可归类到某个分类下；
用户在记录时支持文字编辑和本地图片上传；
用户在编辑记录时，可选择拍摄照片上传；
用户添加的记录支持备注标签，并且可根据标签查找记录；
用户可以将记录的文本内容进行复制、粘贴；
用户可选择部分文本记录内容，快速转为待办项或日程；
用户可将单个记录进行重点标记或星标；
编辑记录时，用户可在文本框实时查看当前已编辑的文本字数。
