Alan Cooper序
Marty Cagan序
前言
致谢 .
使用前必读
第1章 产品全景图
让我们从头开始
故事是讲出来的，不是写出来的
讲故事，要完整
Gary的悲剧
边讲边记
创意框架
刻画用户画像
讲用户的故事
探索细节和可选项
user_story_mapping-table.indd 5 16-3-15 下午3:43
vi ｜ 目录
第2章 计划，为了更少的开发
故事地图帮助大型组织建立共识
创建故事地图的过程可以帮助发现设计中的坑
要做的总是太多
划分MVP发布计划
划分发布路线图
为成果排列优先级，而非功能
这是魔法吗？没错
为什么要反复讨论MVP
MVP根本就不是产品
第3章 计划，为了更快的学习
从讨论机会开始
验证问题
在设计原型过程中学习
要能够质疑用户所说的内容
在开发过程中学习
迭代直至可行
错误的做事方式
基于验证的学习
真正的最小化试验
重点复述
第4章 计划，为了按时发布
要让团队所有成员都清楚 .
估算的秘密
制定可逐步达成的开发计划
不要将所有的迭代产出都对外发布
关于估算的另外一些秘密
管理研发预算
迭代与增量
开局、中局和末局策略
user_story_mapping-table.indd 6 16-3-15 下午3:43
目录 | vii
根据开发策略切分故事地图
都是关于风险
“剧透”第5章主题
第5章 如何创建故事地图
1. 分步骤写出你的故事
2. 组织情节
3. 探索替代故事
4. 提取故事地图的主干
5. 切分出能帮你达成特定目标的任务
就是这样简单！你已经学会了所有重要概念
请在家里或者办公室里练习
这张地图是现在的，不是将来的
实操案例
练习容易，落地难
故事地图仅仅只是个开始
第6章 用户故事的故事
Kent Beck的创意
简单的事情并不一定容易做到
Ron Jeffries的3C原则
文字和照片
小结
第7章 如何把故事讲得更好
Connextra公司的用户故事模板
模板僵尸和万能犁
提升讨论效果的检查单
创建度假照片
需要操心的事情还多着呢
第8章 不要把所有内容都写在卡片上
不同角色，各有所需
user_story_mapping-table.indd 7 16-3-15 下午3:43
viii ｜ 目录
我们需要一张更大的故事卡
信息辐射器和信息冰箱
错误的工具和错误使用工具
第9章 卡片只是个开始
在头脑中构建清晰的图像
养成口述用户故事的习惯
检视产出
你又不是用户
开发过程就是学习的过程
不仅仅是软件
为学习做计划，学习如何做计划
第10章 做产品好比烤蛋糕
食谱
切分大蛋糕
第11章 碎石行动
故事的大小很重要
把故事比喻为石头
史诗故事是大石头，有时可以用来攻击他人
用主题来组织故事
忘掉这些术语，专注于讲故事
从机会开始
探索最小可行方案
在交付阶段深入每个故事的细节
在开发过程中保持日常对话
评估每一份产出
与用户和客户一起评估
与业务干系人一起评估
发布和持续评估
user_story_mapping-table.indd 8 16-3-15 下午3:43
目录 | ix
第12章 谁是碎石负责人
有价值的-可用的-可行的
一个成功的探索团队需要更多的人参与
神勇三蛟龙
产品负责人好比音乐制作人
这项工作并不简单
第13章 从机会开始
针对机会展开对话
深入挖掘机会，丢弃机会或思考机会
机会不应该是一种委婉的说法
故事地图和机会
挑剔
第14章 通过探索来建立共识
探索不是开发软件
探索的4个核心步骤
探索活动、讨论和工件
探索的目的是建立共识
第15章 通过探索来进行验证性学习
大多数时候，我们其实都是错的
糟糕的往事
同理，聚焦，形成想法，制作原型，测试
如何把好事弄糟
短期验证学习循环
精益创业思想改变产品设计
故事和故事地图呢
第16章 提炼、定义和开发
卡片，对话，更多卡片，更多对话……
细分和提炼
故事工作坊
user_story_mapping-table.indd 9 16-3-15 下午3:43
x ｜ 目录
在冲刺或迭代计划阶段开展故事对话
人人参与并非明智之举
分解和瘦身
如何在交付阶段使用故事地图
如何使用故事地图来可视化进展
在故事工作坊中使用简易地图
第17章 故事呢，就好比《行星战机》
把碎石子儿重新聚集起来
地图绘制要适度
千万不要小题大作
第18章 开发完成后怎么学习
团队回顾
和团队外的角色一起回顾
够用
向用户学习
从发布中学习
预定计划中的结果
使用故事地图来评估发布是否准备就绪
结语
· · · · · · (收起)
具体描述
用戶故事地圖作為一種有效的需求工具，越來越廣泛地應用於開發實踐中。本書以用戶故事地圖為主題，強調以閤作溝通的方式來全麵理解用戶需求，涉及的主題包括怎麼以故事地圖的方式來講用戶需求，如何分解和優化需求，如果通過團隊協同工作的方式來積極吸取經驗教訓，從中洞察用戶的需求，開發真正有價值的、小而美的産品和服務。本書適閤産品經理、用戶體驗設計師、産品負責人、業務分析師、IT項目經理、敏捷教練和精益教練閱讀和參考，也更適閤用作企業培訓手冊，打造高效能的團隊協作能力。
用户评价
##用户故事地图是产品设计可视化的最佳方法。从不同用户角色出发，创建用户画像，讨论用户在某场景下如何使用产品，也就是所谓的用户故事。然后从用户故事中提取用户需求，并依据业务相关性和用户类型对故事地图进行分割，切出能帮你达成特定目标的任务，也就是列出需求优先级。同时，对技术可实现性进行评估，衡量开发成本，和风险，做成原型。最后，和设计人员，开发人员说需求时，应先说为什么要做，谁是这个功能的用户，需要怎么做，让相关人员明确开发标准和度量指标。上线前，反复验证功能是否满足用户需求，以及可用性。上线后，依据干系人，用户反馈和数据表现，对功能进行调整或者增减，反复迭代。
评分##用户故事地图这套方法似乎完全没有考虑内向社恐人士的不适，似乎无论作者还是作者所在公司，甚至作者所在的社会都是外向者社会。大量的协作，令人疲惫的沟通，真是想想都感觉到要窒息，如果相对于内向而又擅长独立处理大量信息的人而言，各个事项会有哪一些替代方案？如果我们假设没有哪一款所谓的新产品不能在市面上找到同类，那么通过竞品分析和用户评论是不是也能发现其中的机会？
评分##7年前研究生课程中有一门「设计思维」，核心思路和这本书是类似的，但是毕业后接触的多是2B、2G的项目，敏捷开发还没有成为主流，多年后有种殊途同归、兜兜转转又遇到的感觉，也是工作些年，对设计思维有了更多的认识。用户故事目的在于建立共识，记录过程，整理解决方案，保持小团队快速推进，并避免引入不必要的工具，方法是好的，但是需要执行人员具备相应的素质来配合，参与感、使命感、责任感缺一不可，以及频繁迭代是否适合2G一些局域部署项目还是个待确定的命题。
评分##方法论和案例集，研究者方式练成
评分##我觉得5页PPT能讲完。
评分##理解了迭代
评分##听君一席话，如听一席话。看不下去了，核心思想就是说在展开一个具体的产品开发之前，先把全部的产品用户路径梳理清楚，再根据优先级开发迭代之类的吧。【2022-3】
评分##好书。书中大多数实践都是我们以前实践过的，外国人在总结、提炼和编写方面确实很牛逼，佩服。
评分##「2019.15」非常老派和外企感的一本书。有价值但在国内的团队未必能够实现。[业务201903]
相关图书
本站所有內容均為互聯網搜索引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 tushu.tinynews.org All Rights Reserved. 求知書站 版权所有