|
關于我們
 書單推薦 新書推薦 |
用戶故事地圖 
定 價：59 元 叢書名：國際標準書號ISBN：9787302429944所屬分類：圖書>計算機/網(wǎng)絡>行業(yè)軟件及
9 7 4 8 2 7 9 3 9 0 4 2 4 
用戶故事地圖作為一種有效的需求工具，越來越廣泛地應用于開發(fā)實踐中。本書以用戶故事地圖為主題，強調(diào)以合作溝通的方式來全面理解用戶需求，涉及的主題包括怎么以故事地圖的方式來講用戶需求，如何分解和優(yōu)化需求，如果通過團隊協(xié)同工作的方式來積極吸取經(jīng)驗教訓，從中洞察用戶的需求，開發(fā)真正有價值的、小而美的產(chǎn)品和服務。本書適合產(chǎn)品經(jīng)理、用戶體驗設計師、產(chǎn)品負責人、業(yè)務分析師、IT項目經(jīng)理、敏捷教練和精益教練閱讀和參考，也更適合用作企業(yè)培訓手冊，打造高效能的團隊協(xié)作能力。
對于軟件開發(fā)而言，用戶故事地圖是一個很有價值的工具，但前提是你必須明白它的用途和正確用法。用戶故事地圖很容易被誤解和誤用，因此，本書深入解釋了如何用它來幫助團隊始終聚焦于用戶及其需求，而不是熱衷并癡迷于單個炫酷的產(chǎn)品特性而迷失方向。作者Jeff Patton展示了用戶故事的種種用法，力求幫助團隊在整個開發(fā)過程中始終圍繞著項目展開更好的互動交流。通過這樣的對話，團隊最終能對構(gòu)建怎樣的產(chǎn)品及其能夠用戶帶來怎樣的價值和體驗達成共識。這樣的共識是打造一流產(chǎn)品的前提。俯瞰用戶故事地圖，通過適當?shù)木毩晛碚莆障嚓P的關鍵性概念。領悟故事是如何實際發(fā)揮效用的？在敏捷和精益項目中，如何從故事中挖掘真正的需求探究一個故事的生命周期，從各種可能的機會入手，步步深入，發(fā)現(xiàn)有價值的需求。準備故事，關注其產(chǎn)生過程，從中了解可以轉(zhuǎn)換為特性的需求，打磨出一流的軟件產(chǎn)品
目錄
Martin Fowler 序............................................................. 1 Alan Cooper 序............................................................... 3 Marty Cagan 序.............................................................. 5 前言............................................................................... 9 致謝............................................................................. 17 使用前必讀................................................................... 21 第1章產(chǎn)品全景圖......................................................... 35 讓我們從頭開始....................................................................................................35 故事是講出來的，不是寫出來的..........................................................................36 講故事，要完整....................................................................................................37 Gary 的悲劇............................................................................................................38 邊講邊記...............................................................................................................39 創(chuàng)意框架...............................................................................................................40 刻畫用戶畫像........................................................................................................41 講用戶的故事........................................................................................................42 探索細節(jié)和可選項.................................................................................................45
第2章計劃，為了更少的開發(fā)........................................ 51 故事地圖幫助大型組織建立共識..........................................................................52 創(chuàng)建故事地圖的過程可以幫助發(fā)現(xiàn)設計中的坑....................................................54 要做的總是太多....................................................................................................55 劃分MVP 發(fā)布計劃................................................................................................56 劃分發(fā)布路線圖....................................................................................................57 為成果排列優(yōu)先級，而非功能..............................................................................57 這是魔法嗎？沒錯.................................................................................................58 為什么要反復討論MVP.........................................................................................60 MVP 根本就不是產(chǎn)品............................................................................................61
第3章計劃，為了更快的學習........................................ 63 從討論機會開始....................................................................................................64 驗證問題...............................................................................................................64 在設計原型過程中學習.........................................................................................65 要能夠質(zhì)疑用戶所說的內(nèi)容..................................................................................66 在開發(fā)過程中學習.................................................................................................66 迭代直至可行........................................................................................................68 錯誤的做事方式....................................................................................................69 基于驗證的學習....................................................................................................70 真正的最小化試驗.................................................................................................71 重點復述...............................................................................................................71
第4章計劃，為了按時發(fā)布........................................... 73 要讓團隊所有成員都清楚.....................................................................................74 估算的秘密............................................................................................................75 制定可逐步達成的開發(fā)計劃..................................................................................76 不要將所有的迭代產(chǎn)出都對外發(fā)布......................................................................77 關于估算的另外一些秘密.....................................................................................77 管理研發(fā)預算........................................................................................................78 迭代與增量............................................................................................................82 開局、中局和末局策略.........................................................................................82 根據(jù)開發(fā)策略切分故事地圖..................................................................................83 都是關于風險........................................................................................................84 “劇透”第5章主題...............................................................................................84
第5章如何創(chuàng)建故事地圖............................................... 85
1. 分步驟寫出你的故事.........................................................................................85 2. 組織情節(jié)............................................................................................................88 3. 探索替代故事....................................................................................................89 4. 提取故事地圖的主干.........................................................................................91 5. 切分出能幫你達成特定目標的任務...................................................................92 就是這樣簡單！你已經(jīng)學會了所有重要概念........................................................93 請在家里或者辦公室里練習..................................................................................94 這張地圖是現(xiàn)在的，不是將來的..........................................................................95 實操案例...............................................................................................................96 練習容易，落地難.................................................................................................97 故事地圖僅僅只是個開始.....................................................................................98 第6章用戶故事的故事................................................ 103 Kent Beck 的創(chuàng)意.................................................................................................103 簡單的事情并不一定容易做到............................................................................104 Ron Jeffries 的3C 原則..........................................................................................105 文字和照片..........................................................................................................107 小結(jié).....................................................................................................................108
第7章如何把故事講得更好......................................... 109 Connextra 公司的用戶故事模板...........................................................................109 模板僵尸和萬能犁............................................................................................... 113 提升討論效果的檢查單....................................................................................... 115 創(chuàng)建度假照片...................................................................................................... 117 需要操心的事情還多著呢................................................................................... 117
第8章不要把所有內(nèi)容都寫在卡片上............................ 119
不同角色，各有所需........................................................................................... 119
我們需要一張更大的故事卡................................................................................ 120 信息輻射器和信息冰箱....................................................................................... 122 錯誤的工具和錯誤使用工具................................................................................ 124
第9章卡片只是個開始................................................ 129 在頭腦中構(gòu)建清晰的圖像................................................................................... 130 養(yǎng)成口述用戶故事的習慣................................................................................... 130 檢視產(chǎn)出............................................................................................................. 131 你又不是用戶...................................................................................................... 132 開發(fā)過程就是學習的過程................................................................................... 133 不僅僅是軟件...................................................................................................... 134 為學習做計劃，學習如何做計劃........................................................................ 134
第10 章做產(chǎn)品好比烤蛋糕........................................... 135 食譜..................................................................................................................... 135 切分大蛋糕.......................................................................................................... 137
第11 章碎石行動......................................................... 141 故事的大小很重要............................................................................................... 141 把故事比喻為石頭............................................................................................... 142 史詩故事是大石頭，有時可以用來攻擊他人...................................................... 144 用主題來組織故事............................................................................................... 145 忘掉這些術語，專注于講故事............................................................................ 145 從機會開始.......................................................................................................... 146 探索最小可行方案............................................................................................... 147 在交付階段深入每個故事的細節(jié)........................................................................ 148 在開發(fā)過程中保持日常對話................................................................................ 150 評估每一份產(chǎn)出.................................................................................................. 151 與用戶和客戶一起評估....................................................................................... 152 與業(yè)務干系人一起評估....................................................................................... 152 發(fā)布和持續(xù)評估.................................................................................................. 153
第12 章誰是碎石負責人.............................................. 155 有價值的-可用的-可行的.....................................................................................156 一個成功的探索團隊需要更多的人參與.............................................................158 神勇三蛟龍..........................................................................................................159 產(chǎn)品負責人好比音樂制作人................................................................................162 這項工作并不簡單...............................................................................................163
第13 章從機會開始.................................................... 165 針對機會展開對話...............................................................................................165 深入挖掘機會，丟棄機會或思考機會.................................................................166 機會不應該是一種委婉的說法............................................................................170 故事地圖和機會..................................................................................................170 挑剔.....................................................................................................................176
第14 章通過探索來建立共識....................................... 177 探索不是開發(fā)軟件...............................................................................................177 探索的4個核心步驟.............................................................................................178 探索活動、討論和工件.......................................................................................191 探索的目的是建立共識.......................................................................................192
第15 章通過探索來進行驗證性學習............................. 195 大多數(shù)時候，我們其實都是錯的........................................................................195 糟糕的往事..........................................................................................................196 同理，聚焦，形成想法，制作原型，測試.........................................................197 如何把好事弄糟..................................................................................................200 短期驗證學習循環(huán)...............................................................................................201 精益創(chuàng)業(yè)思想改變產(chǎn)品設計................................................................................202 故事和故事地圖呢...............................................................................................206
第16 章提煉、定義和開發(fā)........................................... 209 卡片，對話，更多卡片，更多對話…… ...........................................................209 細分和提煉..........................................................................................................209 故事工作坊..........................................................................................................210
在沖刺或迭代計劃階段開展故事對話................................................................. 213 人人參與并非明智之舉....................................................................................... 215 分解和瘦身.......................................................................................................... 217 如何在交付階段使用故事地圖............................................................................ 222 如何使用故事地圖來可視化進展........................................................................ 222 在故事工作坊中使用簡易地圖............................................................................ 223
第17 章故事呢，就好比《行星戰(zhàn)機》.......................... 229 把碎石子兒重新聚集起來................................................................................... 230 地圖繪制要適度.................................................................................................. 232 千萬不要小題大作............................................................................................... 233
第18 章開發(fā)完成后怎么學習....................................... 235 團隊回顧............................................................................................................. 235 和團隊外的角色一起回顧................................................................................... 238 夠用..................................................................................................................... 240 向用戶學習.......................................................................................................... 241 從發(fā)布中學習...................................................................................................... 242 預定計劃中的結(jié)果............................................................................................... 242 使用故事地圖來評估發(fā)布是否準備就緒............................................................. 243
結(jié)語........................................................................... 245 Martin Fowler序 敏捷軟件開發(fā)運動的興起為軟件行業(yè)帶來了諸多積極的變化，大型需求要進行拆分，這 個意識的建立便是其中之一。切分后的需求稱為“故事”（story），故事的使用使得軟 件開發(fā)項目的過程進一步可視化。通過故事方式來組織開發(fā)的產(chǎn)品，每一個故事實現(xiàn)都 和整個軟件完全集成，每個人都可以看到產(chǎn)品在不斷成長。用戶也可以理解故事，開發(fā) 者通過決定下一個迭代開發(fā)哪個故事來管理軟件開發(fā)項目�？梢暬潭鹊拇蠓嵘�，使 得用戶可以深入?yún)⑴c到項目中來，而不是像以前那樣需要等上一年甚至更久時間才能拿 到開發(fā)完成的新特性。
需求拆分本身也有很多負面影響，容易丟失軟件系統(tǒng)全景圖（whole picture）便是其中 之一。開發(fā)工作進展到后期，你可能得到的是一堆無法拼接在一起的碎片。也可能由于 過度陷入細節(jié)而丟掉用戶訴求的本質(zhì)，最終構(gòu)建出用戶不需要的產(chǎn)品。
故事地圖是一門在需求拆分過程中保持全景圖的技術。
如果要用一句話來詮釋本書的話，非上面這句話莫屬了，這句話本身就很有價值。全景 圖可以幫助團隊和用戶有效的溝通，幫助參與其中的人避免開發(fā)非必要的特性，也為一 致的用戶體驗提供了基準。當我詢問ThoughtWorks（思特沃克）的同事如何開發(fā)用戶故 事時，他們最常提到的核心技術就是用戶故事地圖。這些ThoughtWorks同事也是在Jeff （杰夫）的工作坊學到這門技術的，因為Jeff開發(fā)了故事地圖，也只有他能把故事地圖 講到如此淋漓盡致的程度。Jeff寫這本書正是為了幫助讀者直接從源頭學習這門技術。 但是，這本書并非單是為那些名片印著產(chǎn)品經(jīng)理、業(yè)務分析師頭銜或者在線簡歷中寫著 產(chǎn)品經(jīng)理頭銜的人而寫的。在采用功能敏捷開發(fā)方法的十年中，最讓我失望的一點是， 程序員把故事當作和產(chǎn)品經(jīng)理之間進行溝通的單行道。在最開始的時候，故事的目的是 激發(fā)溝通中的火花。要想開發(fā)出能有效支撐用戶活動的軟件，就需要求助于開發(fā)軟件中 最關鍵的角色，因為只有程序員最清楚軟件可以做什么。程序員需要理解用戶想要達成 的目標，需要在前期捕獲用戶需求的階段就參與進來，一起開發(fā)故事。懂得故事地圖技 術的程序員能更好地理解用戶上下文，在軟件成形期間更好地參與進來，從而取得更好 的工作成果。
Kent Beck（肯特?貝克，最早提出用戶故事概念的人）發(fā)展了自己在軟件開發(fā)方面的 理念，他呼吁團隊把溝通作為高效團隊的核心價值。故事，是程序員和其他角色溝通中 的必備要素，故事地圖對這些要素組織為結(jié)構(gòu)化，以此來強化軟件開發(fā)中最關鍵的部 分——溝通。
——Martin Fowler（馬丁?福勒） 2014年6月18日
Alan Cooper序 在Mary Shelley（瑪麗?雪萊）的著名科幻小說《科學怪人》中，瘋狂的弗蘭肯斯坦博 士用尸體碎片創(chuàng)造了一個生命，那時候電力還被視作一項新技術，弗蘭肯斯坦博士用電 力給生物注入生命。當然，這只是小說中的情節(jié)，在現(xiàn)實世界中使用尸體碎片創(chuàng)造生命 實際上根本就不可能。
然而在軟件開發(fā)中，我們一直在試圖這樣做。在軟件中堆砌一個又一個新功能，然后陷 入“為什么沒有多少用戶喜歡這個產(chǎn)品”的困惑中。這個謎題的核心在于開發(fā)人員將工 程方法作為了設計工具，實際上兩者不是一回事兒。
程序員逐個開發(fā)特性是完全合情合理的，并且經(jīng)過數(shù)年驗證是一個行之有效的策略。同 樣經(jīng)過數(shù)年驗證的是，設計軟件產(chǎn)品的行為和范圍時，也遵循逐個進行的方式，這就有 點像科學怪人的做事方式了。
盡管有相通之處，設計軟件行為和開發(fā)軟件的實踐之間其實有明顯的不同，主要原因在 于這兩件事是由不同技能特長的人來承擔的。像交互設計師那樣花好幾個小時的時間觀 察用戶行為和提取行為模式，這樣的工作會讓程序員抓狂。而像程序員那樣花好幾個小 時研究算法，對大多數(shù)設計師而言也同樣難以忍受。
但是，當設計和開發(fā)兩類工作產(chǎn)生協(xié)同的時候，就會像弗蘭肯斯坦所使用的電力一樣， 能夠創(chuàng)造出有生命的產(chǎn)品。團隊協(xié)作為產(chǎn)品注入生命力，并讓用戶也愛上它。 雖然協(xié)作本身并不是什么新概念，但要做到高效協(xié)作實際上確實十分困難。程序員工作 的節(jié)奏、語言和交互設計師之間有非常大的差別。
程序員和設計師在各自的領域中都非常專業(yè)、精干，都有自己的工作規(guī)范，同時他們又 有著共同的弱點。設計問題是很難用開發(fā)術語來描述的，同樣，開發(fā)難題也難以使用設 計術語來說明白。這對姊妹學科之間缺乏共同的語言，而連接兩者恰恰是Jeff Patton（杰 夫?帕頓）所擅長的。
Jeff的用戶故事地圖方法能夠為程序員所理解，同樣也可以為設計師所理解。用戶故事 地圖就像數(shù)字時代的羅塞塔石碑（Rosetta Stone）。
撇開業(yè)界對敏捷的成見，敏捷軟件開發(fā)方法本身也不見得是一種良好的產(chǎn)品設計方法。 敏捷開發(fā)是一種很好的思維方式，可以使設計方案更順利地交付，卻無法產(chǎn)出能讓用戶 喜愛的產(chǎn)品。換句話說，我們看到過不少優(yōu)秀的設計，文檔完成后交給開發(fā)人員，不管 是敏捷開發(fā)還是非敏捷開發(fā)，設計的核心理念在實現(xiàn)過程中都會被抹殺掉。
Jeff Patton的用戶故事地圖方法是連接開發(fā)和設計的橋梁。交互設計的核心是發(fā)現(xiàn)用戶行 為并像講故事一樣把它們描述出來。軟件開發(fā)則是將這些描述拆分、實現(xiàn)并集成到產(chǎn)品 中。在這個復雜的過程中，設計的核心理念非常容易丟失。是的，就像是手術失敗，所 有的規(guī)定操作都做完，病人最后卻死在手術臺上。
通過用戶故事地圖的方式來處理用戶故事，設計仍然保持其敘事結(jié)構(gòu)，開發(fā)工作也可以 得到很好的分解從而得以高效實現(xiàn)。設計師的方案以規(guī)范化的用戶故事形式描述，在開 發(fā)過程中流動并保持其完整性。
在傳統(tǒng)公司中已經(jīng)證實，以兩三百人規(guī)模的團隊，要開發(fā)出能讓用戶喜愛的產(chǎn)品幾乎是 不可能的。而創(chuàng)業(yè)社區(qū)則證實，四五個人組成的創(chuàng)業(yè)團隊可以開發(fā)出能讓人們喜愛的小 產(chǎn)品，即使這些小產(chǎn)品也會最終隨著規(guī)模變大而失去光芒。我們面對的挑戰(zhàn)是如何創(chuàng)造 出用戶喜愛的大型軟件產(chǎn)品。大型軟件產(chǎn)品用戶群廣，并且用戶從事的是復雜的商業(yè)活 動。想把這樣的軟件做得有趣并且簡單易學，是非常困難的。
要想避免將大型軟件產(chǎn)品開發(fā)成“科學怪人”，唯一的方法是學習如何充分協(xié)調(diào)好產(chǎn)品 設計和軟件開發(fā)。在這方面，沒有人比Je ff Patton做得更好。
——Alan Cooper（艾倫?庫珀） 2014年6月17日
Marty Cagan序 我的職業(yè)生涯非常幸運，因為我一直有機會和世界頂尖的許多產(chǎn)品技術團隊合作。他們 創(chuàng)造出用戶非常喜愛，并且每天都在使用的產(chǎn)品。這些團隊正在改變世界。
我也曾經(jīng)受命前往幫助一些做得不那么好的公司。創(chuàng)業(yè)團隊努力在錢燒完之前找到新的 投資。大公司則掙扎于復制早期的成功。團隊無法持續(xù)為業(yè)務貢獻價值。主管則為新想 法何時才能上線操碎了心。工程師對產(chǎn)品經(jīng)理滿腹怨言。
在這個過程中，我認識到頂尖產(chǎn)品公司在軟件設計開發(fā)上和普通公司之間存在巨大的差 別。從主管行為到團隊授權(quán)級別；到團隊協(xié)作的方式；到組織在投資、招聘和產(chǎn)品開發(fā) 方面的思考；到文化；再到產(chǎn)品、設計、開發(fā)如何協(xié)作共同發(fā)現(xiàn)對客戶行之有效的解決 方案。
這本書的題目是用戶故事地圖，但仔細閱讀之后，你會發(fā)現(xiàn)這本書的內(nèi)容并不局限于故 事地圖這一強有力卻看似很簡單的技術上。這本書更多講述團隊如何溝通、協(xié)作并最終 交付好的產(chǎn)品。
大部分人是沒有機會近距離觀察一個強大的產(chǎn)品團隊是如何運作的。讀者能夠了解的更 多是自己公司以及前東家是如何運作的。所以接下來我會幫助大家來識別頂尖產(chǎn)品團隊 和普通團隊之間的差別。
我非常贊同Ben Horowitz（本?霍羅威茨）的文章“好的產(chǎn)品經(jīng)理和差的產(chǎn)品經(jīng)理”中的 觀點，下面借用其形式，初步探討一下好的產(chǎn)品團隊和差的產(chǎn)品團隊之間的主要不同。 好的團隊，有引人入勝的產(chǎn)品愿景，懷著傳教士般的熱忱在工作。差的團隊，像是 由雇傭兵組成的，當一天和尚撞一天鐘，靠混的。
好的團隊，從關鍵業(yè)務指標得到啟發(fā)，通過觀察用戶的痛點和分析用戶使用過程中 產(chǎn)生的數(shù)據(jù)，不斷嘗試新技術解決現(xiàn)實問題。差的團隊，從銷售人員和用戶那里收 集需求。
好的團隊，理解誰是主要干系人，干系人所受的約束，承諾引入解決方案，方案對 用戶和客戶有用，同時也滿足業(yè)務上的約束條件。差的團隊，只知道從干系人那里 收集需求。
好的團隊，掌握大量的技術手段，這些技術手段可以快速驗證哪些產(chǎn)品創(chuàng)意是值得 開發(fā)的。差的團隊，召集會議來制定路標和排列優(yōu)先級。
好的團隊，喜歡和公司內(nèi)有想法的主管展開頭腦風暴和討論產(chǎn)品。差的團隊，在團 隊之外的人膽敢提議他們做任何事的時候，會覺得自己受到了冒犯。
好的團隊，產(chǎn)品經(jīng)理、交互設計師和開發(fā)工程師坐在一起，對功能、用戶體驗、技 術可行性達成一致見解。差的團隊，各自坐在小格子間里，沒有文檔和會議安排， 就不會主動響應其他人的請求。
好的團隊，持續(xù)嘗試新想法以求創(chuàng)新，過程中會注意保護公司利益和品牌。差的團 隊，仍然坐著等待開始嘗試的指令。
好的團隊，對于創(chuàng)造出成功產(chǎn)品所需的技能很有信心，比如強大的交互設計能力。 差的團隊，甚至壓根兒就不知道交互設計為何物。
好的團隊，保證開發(fā)工程師每天有時間參與產(chǎn)品原型的討論，為做好產(chǎn)品獻計獻 策。差的團隊，在迭代計劃會上展示原型，一心只為了估出工作量。
好的團隊，每周直接和用戶交流，以更好地理解用戶訴求，并試探用戶對最新的產(chǎn) 品創(chuàng)意的反饋。差的團隊，以為他們自己就能代表用戶。
好的團隊，清楚地知道盡管他們很喜歡自己在產(chǎn)品上的創(chuàng)意，但這些創(chuàng)意中的很大 一部分用戶并不見得會接受，即使有一些被用戶接受了，也需要經(jīng)過多個迭代的打 磨才能達到預期的效果。差的團隊，只開發(fā)路標上規(guī)劃的內(nèi)容，能按時交付，只求 不出重大質(zhì)量問題就阿彌陀佛。
好的團隊，理解速度和快速迭代對于產(chǎn)品創(chuàng)新的價值，更知道速度來自于正確的方 法，而非強制加班。差的團隊，抱怨同事工作不夠努力，速度太慢。
好的團隊，在評估方案，確認可行并對用戶和業(yè)務有實際價值后，共同做出承諾。 差的團隊，抱怨自己公司是一個受銷售驅(qū)動的公司。
好的團隊，使用工具，以便快速了解用戶是如何使用產(chǎn)品的，并基于數(shù)據(jù)做出判 斷。差的團隊，認為統(tǒng)計分析是可有可無的。
好的團隊，持續(xù)集成和發(fā)布產(chǎn)品，因為他們知道持續(xù)的小發(fā)布能為用戶提供了穩(wěn)定 可靠的解決方案。差的團隊，在經(jīng)過痛苦的集成聯(lián)調(diào)之后，手工測試，一次性發(fā)布 所有功能。
好的團隊，專注于用戶。差的團隊，專注于競品。
好的團隊，在關鍵業(yè)務目標重大影響達成后慶祝。差的團隊，在終于發(fā)布產(chǎn)品之后 慶祝。
我已經(jīng)意識到讀者會困惑，上面所提到的這些東西和用戶故事地圖有什么關系呢？我知 道你會感到驚訝。這恰恰就是我成為故事地圖鐵桿兒粉絲的原因。
在我接觸過的敏捷專家中，真正有能力幫助產(chǎn)品團隊提升產(chǎn)品研發(fā)能力水平的并不多， Jeff Patton便是其中之一。我觀察了Jeff在產(chǎn)品發(fā)現(xiàn)（Product Discovery）階段親自動手 和團隊一起工作的場景。我也把他介紹給公司，因為他做事非常高效。團隊也很喜歡 他，因為他不但知識豐富，人也非常幽默。
產(chǎn)品經(jīng)理都聚到一起寫需求文檔，交互設計師忙于為產(chǎn)品進行涂脂抹粉般的設計，工程 師躲在地下室寫代碼，這樣的日子在頂尖團隊中早已經(jīng)銷聲匿跡�，F(xiàn)在，是時候把這些 現(xiàn)象清出你的團隊了。
——Marty Cagan（馬蒂?卡根） 2014年6月18日
前言 Live in it, laugh in it, love in it/Removes embarrassing, stains from contour sheets,that's right/And it entertains visiting, relatives, it turns a sandwich into a banquet ——Tom Waits, “Step Right Up”
這本書本來是想做成一本小……小……小冊子的，真的。
我打算寫一個簡單的實踐，我稱之為“用戶故事地圖”。除我本人之外，還有許多人使 用類似方法，通過構(gòu)造簡單的故事地圖來使產(chǎn)品使用過程中的用戶體驗圖形化和可視 化，從而提升團隊的協(xié)同效率。
故事地圖可以使我們專注于用戶和用戶體驗， 產(chǎn)生更好的溝通效果，最終做出更好的產(chǎn)品。
做故事地圖這件事真的簡單得要命。和其他人一起工作，一個人來講產(chǎn)品的用戶故事， 一邊講一邊把故事中用戶經(jīng)過的重要步驟記錄在便簽上，并按照從左到右的順序水平排 user_列。然后，回過頭來討論每個步驟的細節(jié)，在便簽上記下討論的細節(jié)，在每個步驟下面垂直排列。結(jié)果得到一個簡單的網(wǎng)格結(jié)構(gòu)，從左到右講述故事，自頂向下拆分細節(jié)。這 樣做快速而有趣。這些細節(jié)故事為敏捷開發(fā)項目提供了更好的待辦列表內(nèi)容。
既然這樣簡單，為何要勞神費力整一本書出來呢？
即便是如此簡單的事情，有時候也會讓人很困惑。光是寫寫想要構(gòu)建故事地圖的原因， 在構(gòu)建過程中會發(fā)生的事情以及故事地圖的好多種不同使用方法，就會占去不少的篇 幅。這本書中需要寫的與這個簡單實踐相關的內(nèi)容，比我起初預想的多得多。
如果你正在使用敏捷開發(fā)過程，想必也是使用用戶故事來填充待辦列表的。過去我只是 假設用戶故事是一個普通的實踐，認為在書里闡述用戶故事是浪費墨水的事情。但是， 我錯了。自Kent Beck首次提出用戶故事以來，已經(jīng)有十五個年頭，用戶故事比以前更流 行，也更普遍被錯誤理解和錯誤使用。這讓我很沮喪，更重要的問題是，這也抹殺了我 們能從用戶故事地圖中獲得的收益。
所以，在這本書中我會盡最大努力來糾正在敏捷和精益軟件開發(fā)中關于用戶故事的錯誤 理念。這就是我寫這本書的初衷。就像Tom Waits在歌詞中寫的那樣，就這樣把三明治辦 成了一場宴會（it turns a sandwich into a baquet）。 為什么是我 我喜歡折騰，樂于看到用戶使用我開發(fā)的軟件并從中獲益。這種樂趣一直激勵著我。成 為一個方法論專家并非我的本意。但學習流程和實踐如何結(jié)合發(fā)揮作用以產(chǎn)生更好的結(jié) 果，進而傳授給別人，確實是我在軟件開發(fā)行業(yè)學習了二十多年才做到的。我也知道教 的東西一直在變化。我對故事地圖的理解每個禮拜都在變，對這種理解的最佳闡述，也 和我的理解一樣變得快。如此種種，讓我好幾年都沒法子靜下心寫書。
但是，現(xiàn)在時機到了。
用戶故事和故事地圖都是非常棒的主意，許多人從中受益，他們的生活更好，產(chǎn)品也更 受歡迎。盡管有人受益于生活變好，然而更多的人還掙扎在用戶故事之中，我總不能坐 視不管吧。
我所能做的，就是寫這本書。如果這本書能夠改善他們的工作和生活，哪怕一點點，我 都會感到很欣慰。
謹以此書獻給那些還在用戶故事中掙扎的人
越來越多的組織采用敏捷和精益開發(fā)流程，同時也采用用戶故事，所以可能會因為對用 戶故事的曲解而落入如下陷阱之中。
? 用戶故事聚焦于構(gòu)建小特性，很容易“只見樹木不見森林”。開發(fā)出來的產(chǎn)品由彼 此不匹配的部分拼湊而成，在用戶看來，這樣的產(chǎn)品就像是瘋狂博士的作品“科學 怪人”。 ? 在開發(fā)大型產(chǎn)品的時候，逐個開發(fā)小特性會讓人們不知道整個產(chǎn)品何時能夠完成開 發(fā)和發(fā)布。團隊中的工程師也會有同樣的困惑。 ? 用戶故事強調(diào)溝通，于是不寫任何文檔。這會導致大家忘記在溝通中討論的內(nèi)容和 達成的共識。 ? 好的用戶故事要有驗收條件，以至于只專注于寫驗收條件，卻對要做什么缺乏一致 的理解。結(jié)果，團隊無法在計劃的時間點完成交付。 ? 好的用戶故事是從用戶角度來描述的，然而系統(tǒng)中有大量不與用戶產(chǎn)生直接交互的 部分，團隊成員認為產(chǎn)品沒有用戶，用戶故事并不適用。 ? 如果你曾經(jīng)落入上述任何一個陷阱，那么接下來對誤解的澄清就會對你有所幫助。你也 可以從中學習如何從全局開始思考，如何在項目中進行估算，如何就用戶目標組織進行 高效的溝通，如何開發(fā)一個能解決用戶問題的好的（產(chǎn)品）特性。 誰需要讀這本書 你當然需要！特別是你剛剛買了這本書，我認為購買這本書是一個明智的投資決定。如 果你是從別人那里借的這本書，現(xiàn)在是時候買一本，等新書到手之后趕緊把借的書還回 人家。
不同的角色閱讀這本書都可以獲得獨特的收益。 ? 對于產(chǎn)品經(jīng)理和用戶體驗設計師，閱讀這本書可以幫助他們彌補完整的產(chǎn)品用戶體 驗和項目計劃之間的鴻溝。如果你正糾結(jié)于產(chǎn)品愿景和開發(fā)細節(jié)，或正在努力幫助 其他人理解用戶和體驗，或正在苦苦尋求用戶體驗和產(chǎn)品設計方法，在工作中嘗試 精益創(chuàng)業(yè)方法，用戶故事地圖都可以幫到你。 ? 產(chǎn)品負責人、業(yè)務分析師和IT項目經(jīng)理應該讀這本書，幫助他們消除內(nèi)部用戶、干 系人和工程師之間的鴻溝。如果你苦于如何說服干系人，希望他們可以對產(chǎn)品達成 一致的理解，或者你正努力幫助工程師理解全景圖，故事地圖都可以幫到你。 ? 幫助團隊和個人提升能力的敏捷教練和精益教練應該讀一讀這本書。如果你已經(jīng)開 始讀了，回憶一下公司成員對用戶故事的錯誤理解吧。遵循本書內(nèi)容，使用用戶故 事做簡單的練習，這本書介紹的實踐可以幫助你的團隊提升能力。 ? 其他任何角色。在使用敏捷過程的時候，會有產(chǎn)品負責人或者業(yè)務分析師這樣的角 色，這些角色在需求管理上要投入大量的精力，能否高效使用用戶故事取決于大家 ? 是否都具備基礎的背景知識。如果大家不了解基礎的背景，就會質(zhì)疑用戶故事沒寫 好或者認為需求粒度過粗，細節(jié)不清晰。讀完這本書之后，你會發(fā)現(xiàn)用戶故事并不 只是一種更好的需求撰寫方式，而是一種組織更有效的溝通方式。這本書可以幫你 理解什么樣的溝通才能幫助你及時獲得需要的信息。
希望你能從我所描述的眾多讀者群體中找到自己的影子。找不到的話，請把書送給其他 能夠從中找到自己的人吧。
找到自己了，對嗎？接下來我們就正式開始吧。
這本書是如何組織的 不久以前，我買了一臺新的彩色激光打印機。打開包裝盒，在打印機頂上有一個紅色的 大信封，里面裝著一本標題為《使用前必讀》的小冊子。我當時還奇怪：“真的有必要 先讀一下嗎？”我之前都是不會讀的，覺得沒什么用處。很幸運，這次我讀了，因為打 印機內(nèi)部的不同地方有很多塑料支撐件，這是為了保證打印機在運輸過程中不被損壞而 加入的，如果我不清理，讓它們直接開始打印，這臺打印機就廢了。
這個故事看起來有點跑題？其實一點兒都不跑題。
這本書也有一章叫“使用前必讀”，闡述了兩個關鍵概念，以及本書使用的詞匯表。在 開始讀這本書之前，我希望你能將這些概念熟記于心。如果沒有理解這兩個概念就開始 毛手毛腳使用用戶故事地圖，后果自負。 一萬英尺高空俯瞰用戶故事地圖 本書的第1~4章從整體視角介紹用戶故事地圖。如果用過用戶故事并且也玩過用戶故事 地圖，閱讀這幾章就足夠你掌握使用故事地圖的正確“姿勢”。
第5章是一個精彩的練習，幫助你學習創(chuàng)建故事地圖的核心理念。和同事一起做一下這 個練習，每個參與者都可以從中學習這些理念。我相信，在此之后他們?yōu)楫a(chǎn)品做的用戶 故事地圖會比之前好很多。
深入理解用戶故事 第6~12章介紹用戶故事背后的故事，用戶故事的工作原理，如何在敏捷和精益項目中更 好地使用用戶故事。故事地圖中有許多小的用戶故事，足以驅(qū)動每天的開發(fā)進程。即使 是敏捷老兵，我相信也會學到此前并不知道的內(nèi)容。如果剛開始使用用戶故事，你在本 章學到的知識足以使那些自稱了解敏捷的同事感到驚訝。
更好的待辦列表 第13~15章深入用戶故事的整個生命周期。這幾章討論可以幫助你使用用戶故事和故事 地圖的特定實踐，應用這些實踐可以創(chuàng)建出更好的待辦列表。
更好的產(chǎn)品 第16~18章深入介紹如何在持續(xù)迭代中使用用戶故事。你可以從中學習如何準備用戶故 事，在開發(fā)過程中如何關注用戶故事，真正完成用戶故事開發(fā)，從每個開發(fā)完成的用戶 故事中獲取反饋并不斷優(yōu)化。
我發(fā)現(xiàn)，不少軟件開發(fā)書籍的前幾章完全是多余的，所以一般都會直接跳過這幾章。但 是，我并沒有在本書中設置這樣多余的章節(jié)。你需要通讀全書。如果在讀完每一章之 后，都能得到一些可以直接應用于實際工作中的寶貴知識，我會感到非常欣慰。 接下來開始我們的尋寶之旅吧。 結(jié)語 完，還是未完？這是個問題。就像好的軟件產(chǎn)品一樣，本書其實還沒有完。貫穿全書， 有很多很不錯的好例子，這些例子都是我所碰到的人講給我聽的，說的都是他們用故事 和故事地圖都做了哪些很棒很酷的事情。我的硬盤上還有好多好多這樣的故事，因此， 由于時間關系而不能把它們修飾打磨好納入本書，簡直就是要我的命。
關于故事和故事地圖，我還可以討論更多細節(jié)。我敢保證，你自己在使用故事時，肯定 也存在一些問題想要找到答案。臨近本書完成時，我也有那樣的擔憂。
作為舊日的開發(fā)人員、UI設計師和產(chǎn)品經(jīng)理，我可以坦白告訴你，在產(chǎn)品發(fā)布的時候， 我基本上都高興不起來。因為我知道我還有一些東西沒有被納入其中，還有一些東西只 需要多一點點時間打磨和修飾，就能夠做得更好一些。如果你真的在乎自己的作品，你 會和我一樣感同身受。
下面我要重復我在前面所用的一句話：“偉大的作品永遠沒有‘完成’這回事, 只有放 棄（Great art is never finished, only abandoned）。 ”我要閉嘴不說這本書是一部偉大的 作品，但得承認我真的精心篩選過，要不然會做得更多。那個“更多”，我留給你，期 待聽到你的發(fā)現(xiàn)，知道你是如何通過更好的協(xié)作來打造偉大產(chǎn)品的。
你還可能感興趣
我要評論
|
