Martin Fowler序

敏捷軟件開(kāi)發(fā)運(yùn)動(dòng)的興起為軟件行業(yè)帶來(lái)了諸多積極的變化，大型需求要進(jìn)行拆分，這

個(gè)意識(shí)的建立便是其中之一。切分后的需求稱為“故事”（story），故事的使用使得軟

件開(kāi)發(fā)項(xiàng)目的過(guò)程進(jìn)一步可視化。通過(guò)故事方式來(lái)組織開(kāi)發(fā)的產(chǎn)品，每一個(gè)故事實(shí)現(xiàn)都

和整個(gè)軟件完全集成，每個(gè)人都可以看到產(chǎn)品在不斷成長(zhǎng)。用戶也可以理解故事，開(kāi)發(fā)

者通過(guò)決定下一個(gè)迭代開(kāi)發(fā)哪個(gè)故事來(lái)管理軟件開(kāi)發(fā)項(xiàng)目�？梢暬�程度的大幅提升，使

得用戶可以深入?yún)⑴c到項(xiàng)目中來(lái)，而不是像以前那樣需要等上一年甚至更久時(shí)間才能拿

到開(kāi)發(fā)完成的新特性。

需求拆分本身也有很多負(fù)面影響，容易丟失軟件系統(tǒng)全景圖（whole picture）便是其中

之一。開(kāi)發(fā)工作進(jìn)展到后期，你可能得到的是一堆無(wú)法拼接在一起的碎片。也可能由于

過(guò)度陷入細(xì)節(jié)而丟掉用戶訴求的本質(zhì)，最終構(gòu)建出用戶不需要的產(chǎn)品。

故事地圖是一門在需求拆分過(guò)程中保持全景圖的技術(shù)。

如果要用一句話來(lái)詮釋本書(shū)的話，非上面這句話莫屬了，這句話本身就很有價(jià)值。全景

圖可以幫助團(tuán)隊(duì)和用戶有效的溝通，幫助參與其中的人避免開(kāi)發(fā)非必要的特性，也為一

致的用戶體驗(yàn)提供了基準(zhǔn)。當(dāng)我詢問(wèn)ThoughtWorks（思特沃克）的同事如何開(kāi)發(fā)用戶故

事時(shí)，他們最常提到的核心技術(shù)就是用戶故事地圖。這些ThoughtWorks同事也是在Jeff

（杰夫）的工作坊學(xué)到這門技術(shù)的，因?yàn)镴eff開(kāi)發(fā)了故事地圖，也只有他能把故事地圖

講到如此淋漓盡致的程度。Jeff寫這本書(shū)正是為了幫助讀者直接從源頭學(xué)習(xí)這門技術(shù)。

但是，這本書(shū)并非單是為那些名片印著產(chǎn)品經(jīng)理、業(yè)務(wù)分析師頭銜或者在線簡(jiǎn)歷中寫著

產(chǎn)品經(jīng)理頭銜的人而寫的。在采用功能敏捷開(kāi)發(fā)方法的十年中，最讓我失望的一點(diǎn)是，

程序員把故事當(dāng)作和產(chǎn)品經(jīng)理之間進(jìn)行溝通的單行道。在最開(kāi)始的時(shí)候，故事的目的是

激發(fā)溝通中的火花。要想開(kāi)發(fā)出能有效支撐用戶活動(dòng)的軟件，就需要求助于開(kāi)發(fā)軟件中

最關(guān)鍵的角色，因?yàn)橹挥谐绦騿T最清楚軟件可以做什么。程序員需要理解用戶想要達(dá)成

的目標(biāo)，需要在前期捕獲用戶需求的階段就參與進(jìn)來(lái)，一起開(kāi)發(fā)故事。懂得故事地圖技

術(shù)的程序員能更好地理解用戶上下文，在軟件成形期間更好地參與進(jìn)來(lái)，從而取得更好

的工作成果。

Kent Beck（肯特?貝克，最早提出用戶故事概念的人）發(fā)展了自己在軟件開(kāi)發(fā)方面的

理念，他呼吁團(tuán)隊(duì)把溝通作為高效團(tuán)隊(duì)的核心價(jià)值。故事，是程序員和其他角色溝通中

的必備要素，故事地圖對(duì)這些要素組織為結(jié)構(gòu)化，以此來(lái)強(qiáng)化軟件開(kāi)發(fā)中最關(guān)鍵的部

分——溝通。

——Martin Fowler（馬丁?福勒）

2014年6月18日

Alan Cooper序

在Mary Shelley（瑪麗?雪萊）的著名科幻小說(shuō)《科學(xué)怪人》中，瘋狂的弗蘭肯斯坦博

士用尸體碎片創(chuàng)造了一個(gè)生命，那時(shí)候電力還被視作一項(xiàng)新技術(shù)，弗蘭肯斯坦博士用電

力給生物注入生命。當(dāng)然，這只是小說(shuō)中的情節(jié)，在現(xiàn)實(shí)世界中使用尸體碎片創(chuàng)造生命

實(shí)際上根本就不可能。

然而在軟件開(kāi)發(fā)中，我們一直在試圖這樣做。在軟件中堆砌一個(gè)又一個(gè)新功能，然后陷

入“為什么沒(méi)有多少用戶喜歡這個(gè)產(chǎn)品”的困惑中。這個(gè)謎題的核心在于開(kāi)發(fā)人員將工

程方法作為了設(shè)計(jì)工具，實(shí)際上兩者不是一回事兒。

程序員逐個(gè)開(kāi)發(fā)特性是完全合情合理的，并且經(jīng)過(guò)數(shù)年驗(yàn)證是一個(gè)行之有效的策略。同

樣經(jīng)過(guò)數(shù)年驗(yàn)證的是，設(shè)計(jì)軟件產(chǎn)品的行為和范圍時(shí)，也遵循逐個(gè)進(jìn)行的方式，這就有

點(diǎn)像科學(xué)怪人的做事方式了。

盡管有相通之處，設(shè)計(jì)軟件行為和開(kāi)發(fā)軟件的實(shí)踐之間其實(shí)有明顯的不同，主要原因在

于這兩件事是由不同技能特長(zhǎng)的人來(lái)承擔(dān)的。像交互設(shè)計(jì)師那樣花好幾個(gè)小時(shí)的時(shí)間觀

察用戶行為和提取行為模式，這樣的工作會(huì)讓程序員抓狂。而像程序員那樣花好幾個(gè)小

時(shí)研究算法，對(duì)大多數(shù)設(shè)計(jì)師而言也同樣難以忍受。

但是，當(dāng)設(shè)計(jì)和開(kāi)發(fā)兩類工作產(chǎn)生協(xié)同的時(shí)候，就會(huì)像弗蘭肯斯坦所使用的電力一樣，

能夠創(chuàng)造出有生命的產(chǎn)品。團(tuán)隊(duì)協(xié)作為產(chǎn)品注入生命力，并讓用戶也愛(ài)上它。

雖然協(xié)作本身并不是什么新概念，但要做到高效協(xié)作實(shí)際上確實(shí)十分困難。程序員工作

的節(jié)奏、語(yǔ)言和交互設(shè)計(jì)師之間有非常大的差別。

程序員和設(shè)計(jì)師在各自的領(lǐng)域中都非常專業(yè)、精干，都有自己的工作規(guī)范，同時(shí)他們又

有著共同的弱點(diǎn)。設(shè)計(jì)問(wèn)題是很難用開(kāi)發(fā)術(shù)語(yǔ)來(lái)描述的，同樣，開(kāi)發(fā)難題也難以使用設(shè)

計(jì)術(shù)語(yǔ)來(lái)說(shuō)明白。這對(duì)姊妹學(xué)科之間缺乏共同的語(yǔ)言，而連接兩者恰恰是Jeff Patton（杰

夫?帕頓）所擅長(zhǎng)的。

Jeff的用戶故事地圖方法能夠?yàn)槌绦騿T所理解，同樣也可以為設(shè)計(jì)師所理解。用戶故事

地圖就像數(shù)字時(shí)代的羅塞塔石碑（Rosetta Stone）。

撇開(kāi)業(yè)界對(duì)敏捷的成見(jiàn)，敏捷軟件開(kāi)發(fā)方法本身也不見(jiàn)得是一種良好的產(chǎn)品設(shè)計(jì)方法。

敏捷開(kāi)發(fā)是一種很好的思維方式，可以使設(shè)計(jì)方案更順利地交付，卻無(wú)法產(chǎn)出能讓用戶

喜愛(ài)的產(chǎn)品。換句話說(shuō)，我們看到過(guò)不少優(yōu)秀的設(shè)計(jì)，文檔完成后交給開(kāi)發(fā)人員，不管

是敏捷開(kāi)發(fā)還是非敏捷開(kāi)發(fā)，設(shè)計(jì)的核心理念在實(shí)現(xiàn)過(guò)程中都會(huì)被抹殺掉。

Jeff Patton的用戶故事地圖方法是連接開(kāi)發(fā)和設(shè)計(jì)的橋梁。交互設(shè)計(jì)的核心是發(fā)現(xiàn)用戶行

為并像講故事一樣把它們描述出來(lái)。軟件開(kāi)發(fā)則是將這些描述拆分、實(shí)現(xiàn)并集成到產(chǎn)品

中。在這個(gè)復(fù)雜的過(guò)程中，設(shè)計(jì)的核心理念非常容易丟失。是的，就像是手術(shù)失敗，所

有的規(guī)定操作都做完，病人最后卻死在手術(shù)臺(tái)上。

通過(guò)用戶故事地圖的方式來(lái)處理用戶故事，設(shè)計(jì)仍然保持其敘事結(jié)構(gòu)，開(kāi)發(fā)工作也可以

得到很好的分解從而得以高效實(shí)現(xiàn)。設(shè)計(jì)師的方案以規(guī)范化的用戶故事形式描述，在開(kāi)

發(fā)過(guò)程中流動(dòng)并保持其完整性。

在傳統(tǒng)公司中已經(jīng)證實(shí)，以兩三百人規(guī)模的團(tuán)隊(duì)，要開(kāi)發(fā)出能讓用戶喜愛(ài)的產(chǎn)品幾乎是

不可能的。而創(chuàng)業(yè)社區(qū)則證實(shí)，四五個(gè)人組成的創(chuàng)業(yè)團(tuán)隊(duì)可以開(kāi)發(fā)出能讓人們喜愛(ài)的小

產(chǎn)品，即使這些小產(chǎn)品也會(huì)最終隨著規(guī)模變大而失去光芒。我們面對(duì)的挑戰(zhàn)是如何創(chuàng)造

出用戶喜愛(ài)的大型軟件產(chǎn)品。大型軟件產(chǎn)品用戶群廣，并且用戶從事的是復(fù)雜的商業(yè)活

動(dòng)。想把這樣的軟件做得有趣并且簡(jiǎn)單易學(xué)，是非常困難的。

要想避免將大型軟件產(chǎn)品開(kāi)發(fā)成“科學(xué)怪人”，唯一的方法是學(xué)習(xí)如何充分協(xié)調(diào)好產(chǎn)品

設(shè)計(jì)和軟件開(kāi)發(fā)。在這方面，沒(méi)有人比Je ff Patton做得更好。

——Alan Cooper（艾倫?庫(kù)珀）

2014年6月17日

Marty Cagan序

我的職業(yè)生涯非常幸運(yùn)，因?yàn)槲乙恢庇袡C(jī)會(huì)和世界頂尖的許多產(chǎn)品技術(shù)團(tuán)隊(duì)合作。他們

創(chuàng)造出用戶非常喜愛(ài)，并且每天都在使用的產(chǎn)品。這些團(tuán)隊(duì)正在改變世界。

我也曾經(jīng)受命前往幫助一些做得不那么好的公司。創(chuàng)業(yè)團(tuán)隊(duì)努力在錢燒完之前找到新的

投資。大公司則掙扎于復(fù)制早期的成功。團(tuán)隊(duì)無(wú)法持續(xù)為業(yè)務(wù)貢獻(xiàn)價(jià)值。主管則為新想

法何時(shí)才能上線操碎了心。工程師對(duì)產(chǎn)品經(jīng)理滿腹怨言。

在這個(gè)過(guò)程中，我認(rèn)識(shí)到頂尖產(chǎn)品公司在軟件設(shè)計(jì)開(kāi)發(fā)上和普通公司之間存在巨大的差

別。從主管行為到團(tuán)隊(duì)授權(quán)級(jí)別；到團(tuán)隊(duì)協(xié)作的方式；到組織在投資、招聘和產(chǎn)品開(kāi)發(fā)

方面的思考；到文化；再到產(chǎn)品、設(shè)計(jì)、開(kāi)發(fā)如何協(xié)作共同發(fā)現(xiàn)對(duì)客戶行之有效的解決

方案。

這本書(shū)的題目是用戶故事地圖，但仔細(xì)閱讀之后，你會(huì)發(fā)現(xiàn)這本書(shū)的內(nèi)容并不局限于故

事地圖這一強(qiáng)有力卻看似很簡(jiǎn)單的技術(shù)上。這本書(shū)更多講述團(tuán)隊(duì)如何溝通、協(xié)作并最終

交付好的產(chǎn)品。

大部分人是沒(méi)有機(jī)會(huì)近距離觀察一個(gè)強(qiáng)大的產(chǎn)品團(tuán)隊(duì)是如何運(yùn)作的。讀者能夠了解的更

多是自己公司以及前東家是如何運(yùn)作的。所以接下來(lái)我會(huì)幫助大家來(lái)識(shí)別頂尖產(chǎn)品團(tuán)隊(duì)

和普通團(tuán)隊(duì)之間的差別。

我非常贊同Ben Horowitz（本?霍羅威茨）的文章“好的產(chǎn)品經(jīng)理和差的產(chǎn)品經(jīng)理”中的

觀點(diǎn)，下面借用其形式，初步探討一下好的產(chǎn)品團(tuán)隊(duì)和差的產(chǎn)品團(tuán)隊(duì)之間的主要不同。

好的團(tuán)隊(duì)，有引人入勝的產(chǎn)品愿景，懷著傳教士般的熱忱在工作。差的團(tuán)隊(duì)，像是

由雇傭兵組成的，當(dāng)一天和尚撞一天鐘，靠混的。

好的團(tuán)隊(duì)，從關(guān)鍵業(yè)務(wù)指標(biāo)得到啟發(fā)，通過(guò)觀察用戶的痛點(diǎn)和分析用戶使用過(guò)程中

產(chǎn)生的數(shù)據(jù)，不斷嘗試新技術(shù)解決現(xiàn)實(shí)問(wèn)題。差的團(tuán)隊(duì)，從銷售人員和用戶那里收

集需求。

好的團(tuán)隊(duì)，理解誰(shuí)是主要干系人，干系人所受的約束，承諾引入解決方案，方案對(duì)

用戶和客戶有用，同時(shí)也滿足業(yè)務(wù)上的約束條件。差的團(tuán)隊(duì)，只知道從干系人那里

收集需求。

好的團(tuán)隊(duì)，掌握大量的技術(shù)手段，這些技術(shù)手段可以快速驗(yàn)證哪些產(chǎn)品創(chuàng)意是值得

開(kāi)發(fā)的。差的團(tuán)隊(duì)，召集會(huì)議來(lái)制定路標(biāo)和排列優(yōu)先級(jí)。

好的團(tuán)隊(duì)，喜歡和公司內(nèi)有想法的主管展開(kāi)頭腦風(fēng)暴和討論產(chǎn)品。差的團(tuán)隊(duì)，在團(tuán)

隊(duì)之外的人膽敢提議他們做任何事的時(shí)候，會(huì)覺(jué)得自己受到了冒犯。

好的團(tuán)隊(duì)，產(chǎn)品經(jīng)理、交互設(shè)計(jì)師和開(kāi)發(fā)工程師坐在一起，對(duì)功能、用戶體驗(yàn)、技

術(shù)可行性達(dá)成一致見(jiàn)解。差的團(tuán)隊(duì)，各自坐在小格子間里，沒(méi)有文檔和會(huì)議安排，

就不會(huì)主動(dòng)響應(yīng)其他人的請(qǐng)求。

好的團(tuán)隊(duì)，持續(xù)嘗試新想法以求創(chuàng)新，過(guò)程中會(huì)注意保護(hù)公司利益和品牌。差的團(tuán)

隊(duì)，仍然坐著等待開(kāi)始嘗試的指令。

好的團(tuán)隊(duì)，對(duì)于創(chuàng)造出成功產(chǎn)品所需的技能很有信心，比如強(qiáng)大的交互設(shè)計(jì)能力。

差的團(tuán)隊(duì)，甚至壓根兒就不知道交互設(shè)計(jì)為何物。

好的團(tuán)隊(duì)，保證開(kāi)發(fā)工程師每天有時(shí)間參與產(chǎn)品原型的討論，為做好產(chǎn)品獻(xiàn)計(jì)獻(xiàn)

策。差的團(tuán)隊(duì)，在迭代計(jì)劃會(huì)上展示原型，一心只為了估出工作量。

好的團(tuán)隊(duì)，每周直接和用戶交流，以更好地理解用戶訴求，并試探用戶對(duì)最新的產(chǎn)

品創(chuàng)意的反饋。差的團(tuán)隊(duì)，以為他們自己就能代表用戶。

好的團(tuán)隊(duì)，清楚地知道盡管他們很喜歡自己在產(chǎn)品上的創(chuàng)意，但這些創(chuàng)意中的很大

一部分用戶并不見(jiàn)得會(huì)接受，即使有一些被用戶接受了，也需要經(jīng)過(guò)多個(gè)迭代的打

磨才能達(dá)到預(yù)期的效果。差的團(tuán)隊(duì)，只開(kāi)發(fā)路標(biāo)上規(guī)劃的內(nèi)容，能按時(shí)交付，只求

不出重大質(zhì)量問(wèn)題就阿彌陀佛。

好的團(tuán)隊(duì)，理解速度和快速迭代對(duì)于產(chǎn)品創(chuàng)新的價(jià)值，更知道速度來(lái)自于正確的方

法，而非強(qiáng)制加班。差的團(tuán)隊(duì)，抱怨同事工作不夠努力，速度太慢。

好的團(tuán)隊(duì)，在評(píng)估方案，確認(rèn)可行并對(duì)用戶和業(yè)務(wù)有實(shí)際價(jià)值后，共同做出承諾。

差的團(tuán)隊(duì)，抱怨自己公司是一個(gè)受銷售驅(qū)動(dòng)的公司。

好的團(tuán)隊(duì)，使用工具，以便快速了解用戶是如何使用產(chǎn)品的，并基于數(shù)據(jù)做出判

斷。差的團(tuán)隊(duì)，認(rèn)為統(tǒng)計(jì)分析是可有可無(wú)的。

好的團(tuán)隊(duì)，持續(xù)集成和發(fā)布產(chǎn)品，因?yàn)樗麄冎�道持續(xù)的小發(fā)布能為用戶提供了穩(wěn)定

可靠的解決方案。差的團(tuán)隊(duì)，在經(jīng)過(guò)痛苦的集成聯(lián)調(diào)之后，手工測(cè)試，一次性發(fā)布

所有功能。

好的團(tuán)隊(duì)，專注于用戶。差的團(tuán)隊(duì)，專注于競(jìng)品。

好的團(tuán)隊(duì)，在關(guān)鍵業(yè)務(wù)目標(biāo)重大影響達(dá)成后慶祝。差的團(tuán)隊(duì)，在終于發(fā)布產(chǎn)品之后

慶祝。

我已經(jīng)意識(shí)到讀者會(huì)困惑，上面所提到的這些東西和用戶故事地圖有什么關(guān)系呢？我知

道你會(huì)感到驚訝。這恰恰就是我成為故事地圖鐵桿兒粉絲的原因。

在我接觸過(guò)的敏捷專家中，真正有能力幫助產(chǎn)品團(tuán)隊(duì)提升產(chǎn)品研發(fā)能力水平的并不多，

Jeff Patton便是其中之一。我觀察了Jeff在產(chǎn)品發(fā)現(xiàn)（Product Discovery）階段親自動(dòng)手

和團(tuán)隊(duì)一起工作的場(chǎng)景。我也把他介紹給公司，因?yàn)樗�做事非常高效。團(tuán)隊(duì)也很喜歡

他，因?yàn)樗�不但知識(shí)豐富，人也非常幽默。

產(chǎn)品經(jīng)理都聚到一起寫需求文檔，交互設(shè)計(jì)師忙于為產(chǎn)品進(jìn)行涂脂抹粉般的設(shè)計(jì)，工程

師躲在地下室寫代碼，這樣的日子在頂尖團(tuán)隊(duì)中早已經(jīng)銷聲匿跡�，F(xiàn)在，是時(shí)候把這些

現(xiàn)象清出你的團(tuán)隊(duì)了。

——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”

這本書(shū)本來(lái)是想做成一本小……小……小冊(cè)子的，真的。

我打算寫一個(gè)簡(jiǎn)單的實(shí)踐，我稱之為“用戶故事地圖”。除我本人之外，還有許多人使

用類似方法，通過(guò)構(gòu)造簡(jiǎn)單的故事地圖來(lái)使產(chǎn)品使用過(guò)程中的用戶體驗(yàn)圖形化和可視

化，從而提升團(tuán)隊(duì)的協(xié)同效率。

故事地圖可以使我們專注于用戶和用戶體驗(yàn)，

產(chǎn)生更好的溝通效果，最終做出更好的產(chǎn)品。

做故事地圖這件事真的簡(jiǎn)單得要命。和其他人一起工作，一個(gè)人來(lái)講產(chǎn)品的用戶故事，

一邊講一邊把故事中用戶經(jīng)過(guò)的重要步驟記錄在便簽上，并按照從左到右的順序水平排

user_列。然后，回過(guò)頭來(lái)討論每個(gè)步驟的細(xì)節(jié)，在便簽上記下討論的細(xì)節(jié)，在每個(gè)步驟下面垂直排列。結(jié)果得到一個(gè)簡(jiǎn)單的網(wǎng)格結(jié)構(gòu)，從左到右講述故事，自頂向下拆分細(xì)節(jié)。這

樣做快速而有趣。這些細(xì)節(jié)故事為敏捷開(kāi)發(fā)項(xiàng)目提供了更好的待辦列表內(nèi)容。

既然這樣簡(jiǎn)單，為何要?jiǎng)谏褓M(fèi)力整一本書(shū)出來(lái)呢？

即便是如此簡(jiǎn)單的事情，有時(shí)候也會(huì)讓人很困惑。光是寫寫想要構(gòu)建故事地圖的原因，

在構(gòu)建過(guò)程中會(huì)發(fā)生的事情以及故事地圖的好多種不同使用方法，就會(huì)占去不少的篇

幅。這本書(shū)中需要寫的與這個(gè)簡(jiǎn)單實(shí)踐相關(guān)的內(nèi)容，比我起初預(yù)想的多得多。

如果你正在使用敏捷開(kāi)發(fā)過(guò)程，想必也是使用用戶故事來(lái)填充待辦列表的。過(guò)去我只是

假設(shè)用戶故事是一個(gè)普通的實(shí)踐，認(rèn)為在書(shū)里闡述用戶故事是浪費(fèi)墨水的事情。但是，

我錯(cuò)了。自Kent Beck首次提出用戶故事以來(lái)，已經(jīng)有十五個(gè)年頭，用戶故事比以前更流

行，也更普遍被錯(cuò)誤理解和錯(cuò)誤使用。這讓我很沮喪，更重要的問(wèn)題是，這也抹殺了我

們能從用戶故事地圖中獲得的收益。

所以，在這本書(shū)中我會(huì)盡最大努力來(lái)糾正在敏捷和精益軟件開(kāi)發(fā)中關(guān)于用戶故事的錯(cuò)誤

理念。這就是我寫這本書(shū)的初衷。就像Tom Waits在歌詞中寫的那樣，就這樣把三明治辦

成了一場(chǎng)宴會(huì)（it turns a sandwich into a baquet）。

為什么是我

我喜歡折騰，樂(lè)于看到用戶使用我開(kāi)發(fā)的軟件并從中獲益。這種樂(lè)趣一直激勵(lì)著我。成

為一個(gè)方法論專家并非我的本意。但學(xué)習(xí)流程和實(shí)踐如何結(jié)合發(fā)揮作用以產(chǎn)生更好的結(jié)

果，進(jìn)而傳授給別人，確實(shí)是我在軟件開(kāi)發(fā)行業(yè)學(xué)習(xí)了二十多年才做到的。我也知道教

的東西一直在變化。我對(duì)故事地圖的理解每個(gè)禮拜都在變，對(duì)這種理解的最佳闡述，也

和我的理解一樣變得快。如此種種，讓我好幾年都沒(méi)法子靜下心寫書(shū)。

但是，現(xiàn)在時(shí)機(jī)到了。

用戶故事和故事地圖都是非常棒的主意，許多人從中受益，他們的生活更好，產(chǎn)品也更

受歡迎。盡管有人受益于生活變好，然而更多的人還掙扎在用戶故事之中，我總不能坐

視不管吧。

我所能做的，就是寫這本書(shū)。如果這本書(shū)能夠改善他們的工作和生活，哪怕一點(diǎn)點(diǎn)，我

都會(huì)感到很欣慰。

謹(jǐn)以此書(shū)獻(xiàn)給那些還在用戶故事中掙扎的人

越來(lái)越多的組織采用敏捷和精益開(kāi)發(fā)流程，同時(shí)也采用用戶故事，所以可能會(huì)因?yàn)閷?duì)用

戶故事的曲解而落入如下陷阱之中。

?      用戶故事聚焦于構(gòu)建小特性，很容易“只見(jiàn)樹(shù)木不見(jiàn)森林”。開(kāi)發(fā)出來(lái)的產(chǎn)品由彼

此不匹配的部分拼湊而成，在用戶看來(lái)，這樣的產(chǎn)品就像是瘋狂博士的作品“科學(xué)

怪人”。

?      在開(kāi)發(fā)大型產(chǎn)品的時(shí)候，逐個(gè)開(kāi)發(fā)小特性會(huì)讓人們不知道整個(gè)產(chǎn)品何時(shí)能夠完成開(kāi)

發(fā)和發(fā)布。團(tuán)隊(duì)中的工程師也會(huì)有同樣的困惑。

?      用戶故事強(qiáng)調(diào)溝通，于是不寫任何文檔。這會(huì)導(dǎo)致大家忘記在溝通中討論的內(nèi)容和

達(dá)成的共識(shí)。

?      好的用戶故事要有驗(yàn)收條件，以至于只專注于寫驗(yàn)收條件，卻對(duì)要做什么缺乏一致

的理解。結(jié)果，團(tuán)隊(duì)無(wú)法在計(jì)劃的時(shí)間點(diǎn)完成交付。

?      好的用戶故事是從用戶角度來(lái)描述的，然而系統(tǒng)中有大量不與用戶產(chǎn)生直接交互的

部分，團(tuán)隊(duì)成員認(rèn)為產(chǎn)品沒(méi)有用戶，用戶故事并不適用。

?      如果你曾經(jīng)落入上述任何一個(gè)陷阱，那么接下來(lái)對(duì)誤解的澄清就會(huì)對(duì)你有所幫助。你也

可以從中學(xué)習(xí)如何從全局開(kāi)始思考，如何在項(xiàng)目中進(jìn)行估算，如何就用戶目標(biāo)組織進(jìn)行

高效的溝通，如何開(kāi)發(fā)一個(gè)能解決用戶問(wèn)題的好的（產(chǎn)品）特性。

誰(shuí)需要讀這本書(shū)

你當(dāng)然需要！特別是你剛剛買了這本書(shū)，我認(rèn)為購(gòu)買這本書(shū)是一個(gè)明智的投資決定。如

果你是從別人那里借的這本書(shū)，現(xiàn)在是時(shí)候買一本，等新書(shū)到手之后趕緊把借的書(shū)還回

人家。

不同的角色閱讀這本書(shū)都可以獲得獨(dú)特的收益。

?      對(duì)于產(chǎn)品經(jīng)理和用戶體驗(yàn)設(shè)計(jì)師，閱讀這本書(shū)可以幫助他們彌補(bǔ)完整的產(chǎn)品用戶體

驗(yàn)和項(xiàng)目計(jì)劃之間的鴻溝。如果你正糾結(jié)于產(chǎn)品愿景和開(kāi)發(fā)細(xì)節(jié)，或正在努力幫助

其他人理解用戶和體驗(yàn)，或正在苦苦尋求用戶體驗(yàn)和產(chǎn)品設(shè)計(jì)方法，在工作中嘗試

精益創(chuàng)業(yè)方法，用戶故事地圖都可以幫到你。

?      產(chǎn)品負(fù)責(zé)人、業(yè)務(wù)分析師和IT項(xiàng)目經(jīng)理應(yīng)該讀這本書(shū)，幫助他們消除內(nèi)部用戶、干

系人和工程師之間的鴻溝。如果你苦于如何說(shuō)服干系人，希望他們可以對(duì)產(chǎn)品達(dá)成

一致的理解，或者你正努力幫助工程師理解全景圖，故事地圖都可以幫到你。

?      幫助團(tuán)隊(duì)和個(gè)人提升能力的敏捷教練和精益教練應(yīng)該讀一讀這本書(shū)。如果你已經(jīng)開(kāi)

始讀了，回憶一下公司成員對(duì)用戶故事的錯(cuò)誤理解吧。遵循本書(shū)內(nèi)容，使用用戶故

事做簡(jiǎn)單的練習(xí)，這本書(shū)介紹的實(shí)踐可以幫助你的團(tuán)隊(duì)提升能力。

?      其他任何角色。在使用敏捷過(guò)程的時(shí)候，會(huì)有產(chǎn)品負(fù)責(zé)人或者業(yè)務(wù)分析師這樣的角

色，這些角色在需求管理上要投入大量的精力，能否高效使用用戶故事取決于大家

?      是否都具備基礎(chǔ)的背景知識(shí)。如果大家不了解基礎(chǔ)的背景，就會(huì)質(zhì)疑用戶故事沒(méi)寫

好或者認(rèn)為需求粒度過(guò)粗，細(xì)節(jié)不清晰。讀完這本書(shū)之后，你會(huì)發(fā)現(xiàn)用戶故事并不

只是一種更好的需求撰寫方式，而是一種組織更有效的溝通方式。這本書(shū)可以幫你

理解什么樣的溝通才能幫助你及時(shí)獲得需要的信息。

希望你能從我所描述的眾多讀者群體中找到自己的影子。找不到的話，請(qǐng)把書(shū)送給其他

能夠從中找到自己的人吧。

找到自己了，對(duì)嗎？接下來(lái)我們就正式開(kāi)始吧。

這本書(shū)是如何組織的

不久以前，我買了一臺(tái)新的彩色激光打印機(jī)。打開(kāi)包裝盒，在打印機(jī)頂上有一個(gè)紅色的

大信封，里面裝著一本標(biāo)題為《使用前必讀》的小冊(cè)子。我當(dāng)時(shí)還奇怪：“真的有必要

先讀一下嗎？”我之前都是不會(huì)讀的，覺(jué)得沒(méi)什么用處。很幸運(yùn)，這次我讀了，因?yàn)榇?/p>

印機(jī)內(nèi)部的不同地方有很多塑料支撐件，這是為了保證打印機(jī)在運(yùn)輸過(guò)程中不被損壞而

加入的，如果我不清理，讓它們直接開(kāi)始打印，這臺(tái)打印機(jī)就廢了。

這個(gè)故事看起來(lái)有點(diǎn)跑題？其實(shí)一點(diǎn)兒都不跑題。

這本書(shū)也有一章叫“使用前必讀”，闡述了兩個(gè)關(guān)鍵概念，以及本書(shū)使用的詞匯表。在

開(kāi)始讀這本書(shū)之前，我希望你能將這些概念熟記于心。如果沒(méi)有理解這兩個(gè)概念就開(kāi)始

毛手毛腳使用用戶故事地圖，后果自負(fù)。

一萬(wàn)英尺高空俯瞰用戶故事地圖

本書(shū)的第1~4章從整體視角介紹用戶故事地圖。如果用過(guò)用戶故事并且也玩過(guò)用戶故事

地圖，閱讀這幾章就足夠你掌握使用故事地圖的正確“姿勢(shì)”。

第5章是一個(gè)精彩的練習(xí)，幫助你學(xué)習(xí)創(chuàng)建故事地圖的核心理念。和同事一起做一下這

個(gè)練習(xí)，每個(gè)參與者都可以從中學(xué)習(xí)這些理念。我相信，在此之后他們?yōu)楫a(chǎn)品做的用戶

故事地圖會(huì)比之前好很多。

深入理解用戶故事

第6~12章介紹用戶故事背后的故事，用戶故事的工作原理，如何在敏捷和精益項(xiàng)目中更

好地使用用戶故事。故事地圖中有許多小的用戶故事，足以驅(qū)動(dòng)每天的開(kāi)發(fā)進(jìn)程。即使

是敏捷老兵，我相信也會(huì)學(xué)到此前并不知道的內(nèi)容。如果剛開(kāi)始使用用戶故事，你在本

章學(xué)到的知識(shí)足以使那些自稱了解敏捷的同事感到驚訝。

更好的待辦列表

第13~15章深入用戶故事的整個(gè)生命周期。這幾章討論可以幫助你使用用戶故事和故事

地圖的特定實(shí)踐，應(yīng)用這些實(shí)踐可以創(chuàng)建出更好的待辦列表。

更好的產(chǎn)品

第16~18章深入介紹如何在持續(xù)迭代中使用用戶故事。你可以從中學(xué)習(xí)如何準(zhǔn)備用戶故

事，在開(kāi)發(fā)過(guò)程中如何關(guān)注用戶故事，真正完成用戶故事開(kāi)發(fā)，從每個(gè)開(kāi)發(fā)完成的用戶

故事中獲取反饋并不斷優(yōu)化。

我發(fā)現(xiàn)，不少軟件開(kāi)發(fā)書(shū)籍的前幾章完全是多余的，所以一般都會(huì)直接跳過(guò)這幾章。但

是，我并沒(méi)有在本書(shū)中設(shè)置這樣多余的章節(jié)。你需要通讀全書(shū)。如果在讀完每一章之

后，都能得到一些可以直接應(yīng)用于實(shí)際工作中的寶貴知識(shí)，我會(huì)感到非常欣慰。

接下來(lái)開(kāi)始我們的尋寶之旅吧。

結(jié)語(yǔ)

完，還是未完？這是個(gè)問(wèn)題。就像好的軟件產(chǎn)品一樣，本書(shū)其實(shí)還沒(méi)有完。貫穿全書(shū)，

有很多很不錯(cuò)的好例子，這些例子都是我所碰到的人講給我聽(tīng)的，說(shuō)的都是他們用故事

和故事地圖都做了哪些很棒很酷的事情。我的硬盤上還有好多好多這樣的故事，因此，

由于時(shí)間關(guān)系而不能把它們修飾打磨好納入本書(shū)，簡(jiǎn)直就是要我的命。

關(guān)于故事和故事地圖，我還可以討論更多細(xì)節(jié)。我敢保證，你自己在使用故事時(shí)，肯定

也存在一些問(wèn)題想要找到答案。臨近本書(shū)完成時(shí)，我也有那樣的擔(dān)憂。

作為舊日的開(kāi)發(fā)人員、UI設(shè)計(jì)師和產(chǎn)品經(jīng)理，我可以坦白告訴你，在產(chǎn)品發(fā)布的時(shí)候，

我基本上都高興不起來(lái)。因?yàn)槲抑�道我還有一些東西沒(méi)有被納入其中，還有一些東西只

需要多一點(diǎn)點(diǎn)時(shí)間打磨和修飾，就能夠做得更好一些。如果你真的在乎自己的作品，你

會(huì)和我一樣感同身受。

下面我要重復(fù)我在前面所用的一句話：“偉大的作品永遠(yuǎn)沒(méi)有‘完成’這回事, 只有放

棄（Great art is never finished, only abandoned）。 ”我要閉嘴不說(shuō)這本書(shū)是一部偉大的

作品，但得承認(rèn)我真的精心篩選過(guò)，要不然會(huì)做得更多。那個(gè)“更多”，我留給你，期

待聽(tīng)到你的發(fā)現(xiàn)，知道你是如何通過(guò)更好的協(xié)作來(lái)打造偉大產(chǎn)品的。