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作为行头
基于验证的学习和真正最小化试验
卡片,只是个开始
不要都写在卡上
不同角色需求不同,各个角色的切换
标题-描述信息-故事序号-估算何规模预算-优先级-度量结果-依赖-状态-日期