一、用戶故事地圖是什么？
1、瀑布模型
在進(jìn)入正題前，讓我先來(lái)講講敏捷開發(fā)的誕生。在很早以前的軟件開發(fā)中，并沒有系統(tǒng)的流程管理方式，所以造成大量的人員、時(shí)間以及金錢的浪費(fèi)。于是，在1970年，一個(gè)叫做溫斯頓·羅伊斯的人提出了針對(duì)于軟件開發(fā)的一種架構(gòu)，叫做“瀑布模型”，他把大型軟件開發(fā)分為：分析與編程，像工廠流水線一樣把軟件開發(fā)過程分成各種工序，流程如上圖（1），之后，“瀑布模型”便沿用下去。但是隨著時(shí)代的進(jìn)步，人們的需求越來(lái)越多，軟件迭代越來(lái)越快，“瀑布模型”的缺點(diǎn)暴露的也越來(lái)越明顯：因?yàn)檫@種“一去不復(fù)返”的流程中沒有迭代與反饋，應(yīng)變能力差，所以對(duì)客戶需求非常不容易適應(yīng)，只要有一處修改，就意味著前面的工作都白做了。所以“瀑布模型”逐漸被淘汰，一種叫“敏捷開發(fā)”的管理新模式應(yīng)運(yùn)而生。
2、敏捷開發(fā)的優(yōu)勢(shì)
敏捷開發(fā)避免了傳統(tǒng)瀑布方式的弊端，主要是吸收了各種新型開發(fā)模式的“動(dòng)態(tài)”特性，敏捷開發(fā)把關(guān)注點(diǎn)從文檔轉(zhuǎn)移到了開發(fā)者，管理方式也從工廠的流水線到團(tuán)隊(duì)的自我放松式的組織。在這種模式下，客戶的需求可以隨著進(jìn)程的推進(jìn)和實(shí)際情況而改變，團(tuán)隊(duì)輸出的產(chǎn)品也是“最小可行產(chǎn)品”（MVP），即可以產(chǎn)生預(yù)期成果的最小發(fā)布方案。這樣，就大大降低了成本，提高了靈活性，減小了風(fēng)險(xiǎn)，修改起產(chǎn)品也不需要全盤重做。所以，“敏捷開發(fā)”模式一直沿用至今。
3、用戶故事地圖的誕生
在以前，人們確定項(xiàng)目時(shí)總要寫厚厚的幾大本說明，好讓開發(fā)人員對(duì)要做的東西有統(tǒng)一認(rèn)識(shí)，但很快，這種充滿條條框框的說明就被淘汰掉了，取而代之的是“敏捷開發(fā)”模式中的“用戶故事”。當(dāng)然，這并不代表人們不用再寫那些惱人的文檔，“用戶故事”的創(chuàng)建依然要有文檔作為依據(jù)，只不過文檔的篇幅和格式已經(jīng)大大優(yōu)化。通過“用戶故事”這一步驟，避免了團(tuán)隊(duì)成員的主觀影響，可以客觀的搜集整理大量用戶需求，形成一個(gè)個(gè)用戶問題、客戶問題、公司問題的解決方案。
但是問題又來(lái)了，因?yàn)閷?duì)于大型產(chǎn)品的開發(fā)，用戶需求的內(nèi)容會(huì)很多，像是一個(gè)龐大的地圖，而“用戶故事”擅長(zhǎng)聚焦于構(gòu)建小的特性，專注于小的細(xì)節(jié)就沒法掌握整體，所以會(huì)帶給人們困惑，不知何時(shí)才能完成開發(fā)和發(fā)布。不同的用戶故事塊也容易出現(xiàn)互不相匹配的產(chǎn)品部分，所以，為了避免這種管中窺豹的錯(cuò)誤出現(xiàn)，人們改進(jìn)了用戶故事的處理方法，這種新的方法就是“用戶故事地圖“。下面，就來(lái)介紹如何創(chuàng)建用戶故事地圖。
二、如何創(chuàng)建用戶故事地圖？
1、前期準(zhǔn)備
召集3-5名產(chǎn)品核心人員，可以包括產(chǎn)品負(fù)責(zé)人、項(xiàng)目經(jīng)理、業(yè)務(wù)分析師、架構(gòu)師，因?yàn)檫@些人代表了項(xiàng)目中的主要角色的看法，所以創(chuàng)建出故事地圖后，在以后的全體計(jì)劃會(huì)上就可以避免出現(xiàn)許多不必要的辯論。準(zhǔn)備一面空出的白板，或一面墻壁，若干顏色和數(shù)量的便利貼，一卷彩色膠帶。
2、整理創(chuàng)意框架
在正式開始創(chuàng)建用戶故事之前，大家要在一起重新明確產(chǎn)品的創(chuàng)意框架，如：
明確產(chǎn)品的目標(biāo)是什么？
能為用戶解決哪些問題？
公司、用戶都能獲得哪些收益？
然后大家統(tǒng)一答案，把明確的目標(biāo)寫在便利貼上，按照優(yōu)先級(jí)排好順序。
3、刻畫用戶畫像
下面針對(duì)優(yōu)先級(jí)最高的目標(biāo)開始討論，開始頭腦風(fēng)暴：
產(chǎn)品面向的主要用戶群是那些？
產(chǎn)品的潛在用戶群有哪些？
誰(shuí)會(huì)為我們的產(chǎn)品付錢？
基于這些問題，羅列不同類型的用戶，討論他們能從中得到什么好處，使用的動(dòng)機(jī)，需要的功能等。精煉出若干類用戶，制成“用戶畫像”卡片，卡片上的內(nèi)容不用很詳細(xì)，可以描述出基本特征即可，給每個(gè)類型的人群起一個(gè)人的名字，張三李四隨意，目的是方便日后討論，以后這個(gè)名字就代表這一類人群，再對(duì)每個(gè)用戶做一下簡(jiǎn)單的訴求描述。最后，把這些寫著用戶類型的卡片，按照優(yōu)先級(jí)排好，重要的用戶放在上面，貼在白板上。
為了講解的更加清晰，我把之前參與過的一個(gè)項(xiàng)目當(dāng)做例子，演示“用戶故事地圖”的產(chǎn)生過程：這是一款大學(xué)生的微電影服務(wù)平臺(tái)，我們的初衷是想要“大學(xué)生影視團(tuán)隊(duì)”和“有拍微電影意愿的人”在平臺(tái)上對(duì)接起來(lái)，由于攝影團(tuán)隊(duì)所駕馭的影片難度低，需要的資金少，所以我們的目標(biāo)很可能包括這些：“學(xué)生拍畢業(yè)季微電影“”學(xué)校社團(tuán)宣傳“”婚禮開場(chǎng)微電影烘托氣氛“等等（下面我所繪制的用戶故事地圖只是想讓大家看起來(lái)更直觀，如果有不嚴(yán)謹(jǐn)之處還望大家見諒）。
4、大故事
從最重要的用戶類型下手，這里依然使用頭腦風(fēng)暴，可以按照時(shí)間順序挖掘，描述這個(gè)人在一天中使用產(chǎn)品的情景，“首先他會(huì)怎樣，然后怎樣，然后……“這些故事可以比較概括，如“用戶注冊(cè)”或“修改日程”，團(tuán)隊(duì)中安排專門的人負(fù)責(zé)記錄把每一件事都寫到一張便利貼中，按照時(shí)間順序從左到右排好便利貼。當(dāng)有遺漏的故事被挖掘出來(lái)時(shí)，可以隨時(shí)調(diào)整卡片順序。在這個(gè)過程中，做到了團(tuán)隊(duì)成員對(duì)所要做的東西達(dá)成了一致，產(chǎn)品創(chuàng)意精彩的細(xì)節(jié)部分被所有人所消化。
下圖以其中的一個(gè)用戶類型為例，寫出大故事：
5、深挖細(xì)節(jié)
在完成第五步的“大故事”后，“用戶故事地圖”的框架已經(jīng)結(jié)束，下面要做的是深挖細(xì)節(jié)。白板上的卡片已經(jīng)出現(xiàn)了第一列，這些都是大故事，我們要在每一個(gè)大故事上深挖，寫出包括的細(xì)節(jié)：
用戶在這一步具體要做什么事情？
用戶在這一步還有其他選擇么？
如何做才能更符合用戶的習(xí)慣？
出現(xiàn)問題時(shí)如何解決？
在完成以上等等問題后，記錄員要把每一個(gè)小細(xì)節(jié)都寫在便利貼上，豎向排列在“大故事”卡片的下面，如果有與大故事無(wú)關(guān)的其他細(xì)節(jié)，可以放在“用戶卡片”的上方區(qū)域。到此為止，一個(gè)巨大的恐龍骨骼一樣的“用戶故事地圖”出現(xiàn)在白板上，甚至，它可以占滿一面墻。
6、劃分MVP發(fā)布計(jì)劃
在第五步我們所創(chuàng)建的“用戶故事地圖”涵蓋了多個(gè)用戶故事和敘事主線，包含了項(xiàng)目人員所有的愿景，但是它太龐大了，如果同時(shí)研發(fā)這些功能點(diǎn)，可能幾年時(shí)間都做不完，“敏捷開發(fā)”也不允許我們這么做。所以，為了縮短項(xiàng)目周期，我們要在“用戶故事地圖”上進(jìn)行MVP的內(nèi)容篩選，把最重要的內(nèi)容放在前面。橫向移動(dòng)用戶目標(biāo)，縱向移動(dòng)深挖出的細(xì)節(jié)，然后用膠帶做出分隔，如下面這個(gè)例子，在第一個(gè)版本中，我只開發(fā)標(biāo)號(hào)為1的部分，隨著軟件的不斷迭代，用戶故事地圖也不斷向下推移。此時(shí)已經(jīng)完成了這個(gè)產(chǎn)品的發(fā)布路線圖。
三、說在最后
“用戶故事地圖”以直觀易變的方式進(jìn)行項(xiàng)目的良好溝通，大多數(shù)人看重的是地圖的形式部分，橫向是講述大故事的部分，縱向是逐步的細(xì)化，但是最關(guān)鍵的是產(chǎn)品的構(gòu)思框架，讓團(tuán)隊(duì)成員對(duì)想要做出的產(chǎn)品一目了然，大大提高了團(tuán)隊(duì)之間相互協(xié)作的默契度，但是要注意的一點(diǎn)就是，功能的開拓要適度，否則這幅用戶地圖永遠(yuǎn)都畫不完。正如《用戶故事地圖》的作者Jeff Patton所說：“如果不需要討論，就不必繪制用戶故事地圖。”
