用户故事地图
第一阶段的需求结束，产品团队很想松口气，但是我在盘点需求文档时遇到很多实际问题。
1、需求按模块拆分，强调用例
用例利于项目组内部沟通，解决的是开发测试的问题。但，用户的使用与感受不可能通过用例去理解。
2、整体框架与内部关联关系模糊
虽然有全局规则的定义，有公共规则，有叙词表，有权限表，有推广需求，有数据统计……但是当每个人陷入细节，特别是自己负责的那部分，谁来负责整体框架性与关联关系？
3、业务缺乏可视化
文档过于碎片，缺乏可视化，查找某个深埋在某份文档里的分支或规则非常困难，方圆几米，基本靠吼或行走，没有人有时间去翻。
4、PRD 参差不齐
项目赶进度，PRD 很难尽善尽美，何况存在多人撰写再合并，个体能力与习惯不同，文档调性明显不一。包括我自己的部分，还是有很多细节，难以通过文字与研发、测试达成一致，更多要靠口头反复确认，甚至是一起到交互处对着设计稿核对，团队协同效率太低。
5、培训是难题
业务丢失全景图，想从全局角度理解业务有一定难度。如果这个时候团队有新人，培训就是难题。
就像某个前端同事说的，“这么多文档咋没有个索引？”
我开始思考，有没有办法用项目里各种角色的人（至少是产品团队）都能理解的方式，构建一张业务全景图，或者是需求索引？
用户故事地图（User Story Map）
整个故事的结构由脊梁骨（backbone）与行走中的骨骼（skeleton）组成，骨骼中有较多的主干，按照必要性（necessity）从上到下排序。
图片来源：SlideShare 公开资源
具体到案例演绎，有点像卡片分类与需求用例。
任务是用动词描述用户做什么事情。从左到右形成叙事主线。
任务有不同的目标层级，优先级从上到下降序。地图的深度包含各个子任务。
活动构成了故事的主干。
橘色第一行，对应上图中的脊梁骨（backbon），就是最小化的用户故事，即用户行为。
蓝色第二行，对应上图中的骨骼（skeleton），按照从左到右的顺序叙述用户任务。
黄色第三行，就是故事情节的内容组成与细节，按照优先级，对应下图中的发布计划（Release），Release 1 ＞ Release 2＞Release 3。
图片来源：Winnipeg Agilist
举例：
图片来源：SlideShare 公开资源
我们在新项目里的执行
很可惜，我们在项目初期没有采取这样的方式。但是在第一阶段的需求盘点，这种模式还是给了我很大帮助。
用户故事地图的理论基础，做适度的改良。
个人体会：
需求范围没有扩大，但是我对需求的理解更加深刻了。也许这会至少成为我在其他新项目里对于全局规则的标配，它不取代全局规则的定义，但是可以辅助团队进行讨论。
实践经验：
1、展示了为谁做，为什么做，而不仅仅是做了什么。
故事地图以广度优先（从左到右），而非深度，探索时向深度拓展（从上到下）。
2、实践起来成本低。
我甚至没有用卡片也没有用白板，就是最简单的Excel，影响最大化（可用性较高，利于传播）。
3、PRD 不是最优先的。
有不同用户角色使用网站的步骤，也有每个阶段的需求点，需要查看细节，可以随时查看文档，此时的 PRD反而成了备忘。
参考书目：《用户故事地图》
作者：Jeff Patton著 李涛 向振东译
