Please enable JavaScript.
Coggle requires JavaScript to display documents.
《用户故事地图》 (产品全景图 (用户故事地图，在讲大故事的同时进行拆分, 靠讲而不是靠写，团队整体的复述, 边讲边记，讲思想解放出来，同时认真聆听…
《用户故事地图》
产品全景图
用户故事地图，在讲大故事的同时进行拆分
靠讲而不是靠写，团队整体的复述
边讲边记，讲思想解放出来，同时认真聆听
试着排列错优先级，调动团队的观察力
从创意框架到用户画像，服务到用户，优先级
在迷失在细节之前，聚焦一次整体故事
是一个个动词短语，连接成的地图
问自己：具体要做什么？其他的选择？如何酷炫？如何处理问题
如何创建故事地图
写出故事——
海平面级的任务，连贯完成的任务，对于鱼类任务的归类抽象
使用目标层级的概念，汇总小任务、拆解大任务
人与人的故事不一样——数量丰富的故事——注重细节
组织情节、探索替代故事
从左到右的叙事
细节的补充——细节、替代、变化和异常构成地图的主体
保持流动性－起床－锻炼－洗澡——穿上运动服
*利用用户故事地图，来写一本武侠小说
:check:*
提取故事地图的主干——活动组成主干——活动卡片下的任务卡片
切分达成特定目标的任务——抽象特定任务目标
用户体验路径图——痛点：没有收益令人讨厌的事情；乐趣和奖励：有趣值得做的事情；问题——人们为什么这么做，过程？；创意——消除痛点or提升乐趣
故事地图六步法：问题－用户－价值；全景图－优先级－深度；探索－深度－why－问题－解决方案；4发布策略；5学习策略mvp；6开发策略
用户需求标签的维度？基础、期望、兴奋？
计划，为了更少的开发
故事排列去发现坑
划分mvp和发布路线图
为成功排列优先级而非功能
寻找更小的可用发布集
差异化功能differentiator
搅局功能spoiler
降成本功能cost reducer
基础功能tablestakes
MVP的定义：不是发布一个粗略的产品；是可以产生预期效果的最小产品发布；最小发布方案（minimum viable solution）
“最小可行产品是为验证假设而做的最小规模的实验”
按时发布
故事的估算力求团队有效沟通为限
最靠谱的估算，理解自己在做什么！
see it work; make it better;make it releasable
Risk Story、未知故事、团队学习的知识
迭代框架和增量计划
主流程－复杂规则－亮点
讲好一个故事：
Title－Priority－Perspective－Requirements－Reson－Date－Reserved for estimate
使用模版引发讨论
僵尸模版的情况——只是看看卡，没有深思熟虑的流程
检查单：who what why，角色，功能，为什么，异常，问题和假设，解决方案，实现，周期
用户故事的故事
简单的故事不一定容易做到
3C原则：Card Conversation Confirmation
协作，充分的kickoff，BA对团队认知的统一
引言
使用用户故事的目的并不是为了写出更好的用户故事
产品开发的目的也并不是开发出产品
计划，为了更快的学习
从讨论机会开始
产品故事的首次讨论，聚焦于如何具象化产品机会
这个想法是什么？客户是谁？哪些客户会采购？用户是谁？解决什么问题？购买和使用的冬季？解决了哪些无法解决的问题？能获得什么收益？为什么要开发？开发成功后我们的收益？
验证问题，要解决的问题是否存在？
通过原型和用户测试验证产品方案的可行性
质疑用户所说的内容，在验证功能的时候
用户故事作为列头，backbone current release next releases作为行头
基于验证的学习和真正最小化试验
卡片，只是个开始
不要都写在卡上
不同角色需求不同，各个角色的切换
标题－描述信息－故事序号－估算何规模预算－优先级－度量结果－依赖－状态－日期