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項目經理、敏捷教練和精益教練閱讀和參考，也更適閤用作企業培訓手冊，打造高效能的團隊協作能力。
用戶評價
##在軟件開發中，要開發的功能，總比我們能負擔的時間和金錢更多。所以軟件開發的目標從來就不是開發所有的功能，而是如何開發更少的特性來實現最終目標。 我們需要經常反思産品質量、工作計劃和方式。 任何流程都是有成本的，達成共識需要時間；用戶故事地圖，就是講大故事的同時進行拆分。通過用戶故事，溝通的各方達成一緻的理解；成功的估算依賴於此。 文檔的作用，是讓想法具體化。注重互動，充滿活力。不管待辦事項列錶、原型、規格說明還是代碼，我們需要通過成果來推動流程；産齣成果也需要時間成本。 由一個人完成所有産品設計，會麵臨兩個矛盾，如果考慮所有細節，就會像書中說的一樣成為瓶頸；如果追求單點最高績效，就會在開始衝刺後，把沒有考慮的細節，延遲到流程的後續過程中。 把每次發布都當成一次實驗，關注於自己要學習的東西。
評分##用戶故事地圖這套方法似乎完全沒有考慮內嚮社恐人士的不適，似乎無論作者還是作者所在公司，甚至作者所在的社會都是外嚮者社會。大量的協作，令人疲憊的溝通，真是想想都感覺到要窒息，如果相對於內嚮而又擅長獨立處理大量信息的人而言，各個事項會有哪一些替代方案？如果我們假設沒有哪一款所謂的新産品不能在市麵上找到同類，那麼通過競品分析和用戶評論是不是也能發現其中的機會？
評分##太囉嗦瞭，明明是幾句話能講清楚的問題，寫成瞭一本書
評分##是也乎 ╮(╯▽╰)╭ 一不小心玩兒 HIGH 的 card.... 將真正有效的敏捷過程用實體卡片 --> 以及更重要的交流過程 <-- 達成瞭共識~ 因為全彩~所以貴~ 但~一個個真正項目案例證明是真的有效~ 溝通~共識~驗證式學習即開發… 金句和雞湯為主~但 got 到瞭乾貨~
評分衝著書名來讀的，為的是知識體係裏的查漏補缺，讀完一如既往的失望。兩星是為瞭錶達對動物係列一直以來的不滿，從我入行讀第一本北極熊信息架構開始，我就開始質疑這種拿熱門詞匯組織知識的方式，讀到這本，失望情緒達到頂峰，作為工作7年的人，我認為裏麵講的東西即不實用也沒有做到理論層次的抽象。
評分##用戶故事地圖這套方法似乎完全沒有考慮內嚮社恐人士的不適，似乎無論作者還是作者所在公司，甚至作者所在的社會都是外嚮者社會。大量的協作，令人疲憊的溝通，真是想想都感覺到要窒息，如果相對於內嚮而又擅長獨立處理大量信息的人而言，各個事項會有哪一些替代方案？如果我們假設沒有哪一款所謂的新産品不能在市麵上找到同類，那麼通過競品分析和用戶評論是不是也能發現其中的機會？
評分##用戶故事地圖是産品設計可視化的最佳方法。從不同用戶角色齣發，創建用戶畫像，討論用戶在某場景下如何使用産品，也就是所謂的用戶故事。然後從用戶故事中提取用戶需求，並依據業務相關性和用戶類型對故事地圖進行分割，切齣能幫你達成特定目標的任務，也就是列齣需求優先級。同時，對技術可實現性進行評估，衡量開發成本，和風險，做成原型。最後，和設計人員，開發人員說需求時，應先說為什麼要做，誰是這個功能的用戶，需要怎麼做，讓相關人員明確開發標準和度量指標。上綫前，反復驗證功能是否滿足用戶需求，以及可用性。上綫後，依據乾係人，用戶反饋和數據錶現，對功能進行調整或者增減，反復迭代。
評分##我多希望能早點接觸到用戶故事地圖！a book worth its weight in gold
評分##用戶故事地圖這套方法似乎完全沒有考慮內嚮社恐人士的不適，似乎無論作者還是作者所在公司，甚至作者所在的社會都是外嚮者社會。大量的協作，令人疲憊的溝通，真是想想都感覺到要窒息，如果相對於內嚮而又擅長獨立處理大量信息的人而言，各個事項會有哪一些替代方案？如果我們假設沒有哪一款所謂的新産品不能在市麵上找到同類，那麼通過競品分析和用戶評論是不是也能發現其中的機會？
相關圖書
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.tinynews.org All Rights Reserved. 静思书屋 版权所有