“用戶故事地圖”以直觀易變的方式進(jìn)行項目的良好溝通，大多數(shù)人看重的是地圖的形式部分，橫向是講述大故事的部分，縱向是逐步的細(xì)化，但是最關(guān)鍵的是產(chǎn)品的構(gòu)思框架，讓團(tuán)隊成員對想要做出的產(chǎn)品一目了然，大大提高了團(tuán)隊之間相互協(xié)作的默契度。

一、用戶故事地圖是什么？

1、瀑布模型

圖（1）

在進(jìn)入正題前，讓我先來講講敏捷開發(fā)的誕生。在很早以前的軟件開發(fā)中，并沒有系統(tǒng)的流程管理方式，所以造成大量的人員、時間以及金錢的浪費(fèi)。于是，在1970年，一個叫做溫斯頓·羅伊斯的人提出了針對于軟件開發(fā)的一種架構(gòu)，叫做“瀑布模型”，他把大型軟件開發(fā)分為：分析與編程，像工廠流水線一樣把軟件開發(fā)過程分成各種工序，流程如上圖（1），之后，“瀑布模型”便沿用下去。但是隨著時代的進(jìn)步，人們的需求越來越多，軟件迭代越來越快，“瀑布模型”的缺點(diǎn)暴露的也越來越明顯：因為這種“一去不復(fù)返”的流程中沒有迭代與反饋，應(yīng)變能力差，所以對客戶需求非常不容易適應(yīng)，只要有一處修改，就意味著前面的工作都白做了。所以“瀑布模型”逐漸被淘汰，一種叫“敏捷開發(fā)”的管理新模式應(yīng)運(yùn)而生。

2、敏捷開發(fā)的優(yōu)勢

圖（2）

敏捷開發(fā)避免了傳統(tǒng)瀑布方式的弊端，主要是吸收了各種新型開發(fā)模式的“動態(tài)”特性，敏捷開發(fā)把關(guān)注點(diǎn)從文檔轉(zhuǎn)移到了開發(fā)者，管理方式也從工廠的流水線到團(tuán)隊的自我放松式的組織。在這種模式下，客戶的需求可以隨著進(jìn)程的推進(jìn)和實(shí)際情況而改變，團(tuán)隊輸出的產(chǎn)品也是“最小可行產(chǎn)品”（MVP），即可以產(chǎn)生預(yù)期成果的最小發(fā)布方案。這樣，就大大降低了成本，提高了靈活性，減小了風(fēng)險，修改起產(chǎn)品也不需要全盤重做。所以，“敏捷開發(fā)”模式一直沿用至今。

3、用戶故事地圖的誕生

在以前，人們確定項目時總要寫厚厚的幾大本說明，好讓開發(fā)人員對要做的東西有統(tǒng)一認(rèn)識，但很快，這種充滿條條框框的說明就被淘汰掉了，取而代之的是“敏捷開發(fā)”模式中的“用戶故事”。當(dāng)然，這并不代表人們不用再寫那些惱人的文檔，“用戶故事”的創(chuàng)建依然要有文檔作為依據(jù)，只不過文檔的篇幅和格式已經(jīng)大大優(yōu)化。通過“用戶故事”這一步驟，避免了團(tuán)隊成員的主觀影響，可以客觀的搜集整理大量用戶需求，形成一個個用戶問題、客戶問題、公司問題的解決方案。

但是問題又來了，因為對于大型產(chǎn)品的開發(fā)，用戶需求的內(nèi)容會很多，像是一個龐大的地圖，而“用戶故事”擅長聚焦于構(gòu)建小的特性，專注于小的細(xì)節(jié)就沒法掌握整體，所以會帶給人們困惑，不知何時才能完成開發(fā)和發(fā)布。不同的用戶故事塊也容易出現(xiàn)互不相匹配的產(chǎn)品部分，所以，為了避免這種管中窺豹的錯誤出現(xiàn)，人們改進(jìn)了用戶故事的處理方法，這種新的方法就是“用戶故事地圖“。下面，就來介紹如何創(chuàng)建用戶故事地圖。

二、如何創(chuàng)建用戶故事地圖？

1、前期準(zhǔn)備

召集3-5名產(chǎn)品核心人員，可以包括產(chǎn)品負(fù)責(zé)人、項目經(jīng)理、業(yè)務(wù)分析師、架構(gòu)師，因為這些人代表了項目中的主要角色的看法，所以創(chuàng)建出故事地圖后，在以后的全體計劃會上就可以避免出現(xiàn)許多不必要的辯論。準(zhǔn)備一面空出的白板，或一面墻壁，若干顏色和數(shù)量的便利貼，一卷彩色膠帶。

2、整理創(chuàng)意框架

在正式開始創(chuàng)建用戶故事之前，大家要在一起重新明確產(chǎn)品的創(chuàng)意框架，如：

• 明確產(chǎn)品的目標(biāo)是什么？
• 能為用戶解決哪些問題？
• 公司、用戶都能獲得哪些收益？

然后大家統(tǒng)一答案，把明確的目標(biāo)寫在便利貼上，按照優(yōu)先級排好順序。

3、刻畫用戶畫像

下面針對優(yōu)先級最高的目標(biāo)開始討論，開始頭腦風(fēng)暴：

• 產(chǎn)品面向的主要用戶群是那些？
• 產(chǎn)品的潛在用戶群有哪些？
• 誰會為我們的產(chǎn)品付錢？

基于這些問題，羅列不同類型的用戶，討論他們能從中得到什么好處，使用的動機(jī)，需要的功能等。精煉出若干類用戶，制成“用戶畫像”卡片，卡片上的內(nèi)容不用很詳細(xì)，可以描述出基本特征即可，給每個類型的人群起一個人的名字，張三李四隨意，目的是方便日后討論，以后這個名字就代表這一類人群，再對每個用戶做一下簡單的訴求描述。最后，把這些寫著用戶類型的卡片，按照優(yōu)先級排好，重要的用戶放在上面，貼在白板上。

為了講解的更加清晰，我把之前參與過的一個項目當(dāng)做例子，演示“用戶故事地圖”的產(chǎn)生過程：這是一款大學(xué)生的微電影服務(wù)平臺，我們的初衷是想要“大學(xué)生影視團(tuán)隊”和“有拍微電影意愿的人”在平臺上對接起來，由于攝影團(tuán)隊所駕馭的影片難度低，需要的資金少，所以我們的目標(biāo)很可能包括這些：“學(xué)生拍畢業(yè)季微電影“”學(xué)校社團(tuán)宣傳“”婚禮開場微電影烘托氣氛“等等（下面我所繪制的用戶故事地圖只是想讓大家看起來更直觀，如果有不嚴(yán)謹(jǐn)之處還望大家見諒）。

4、大故事

從最重要的用戶類型下手，這里依然使用頭腦風(fēng)暴，可以按照時間順序挖掘，描述這個人在一天中使用產(chǎn)品的情景，“首先他會怎樣，然后怎樣，然后……“這些故事可以比較概括，如“用戶注冊”或“修改日程”，團(tuán)隊中安排專門的人負(fù)責(zé)記錄把每一件事都寫到一張便利貼中，按照時間順序從左到右排好便利貼。當(dāng)有遺漏的故事被挖掘出來時，可以隨時調(diào)整卡片順序。在這個過程中，做到了團(tuán)隊成員對所要做的東西達(dá)成了一致，產(chǎn)品創(chuàng)意精彩的細(xì)節(jié)部分被所有人所消化。

下圖以其中的一個用戶類型為例，寫出大故事：

5、深挖細(xì)節(jié)

在完成第五步的“大故事”后，“用戶故事地圖”的框架已經(jīng)結(jié)束，下面要做的是深挖細(xì)節(jié)。白板上的卡片已經(jīng)出現(xiàn)了第一列，這些都是大故事，我們要在每一個大故事上深挖，寫出包括的細(xì)節(jié)：

• 用戶在這一步具體要做什么事情？
• 用戶在這一步還有其他選擇么？
• 如何做才能更符合用戶的習(xí)慣？
• 出現(xiàn)問題時如何解決？

在完成以上等等問題后，記錄員要把每一個小細(xì)節(jié)都寫在便利貼上，豎向排列在“大故事”卡片的下面，如果有與大故事無關(guān)的其他細(xì)節(jié)，可以放在“用戶卡片”的上方區(qū)域。到此為止，一個巨大的恐龍骨骼一樣的“用戶故事地圖”出現(xiàn)在白板上，甚至，它可以占滿一面墻。

6、劃分MVP發(fā)布計劃

在第五步我們所創(chuàng)建的“用戶故事地圖”涵蓋了多個用戶故事和敘事主線，包含了項目人員所有的愿景，但是它太龐大了，如果同時研發(fā)這些功能點(diǎn)，可能幾年時間都做不完，“敏捷開發(fā)”也不允許我們這么做。所以，為了縮短項目周期，我們要在“用戶故事地圖”上進(jìn)行MVP的內(nèi)容篩選，把最重要的內(nèi)容放在前面。橫向移動用戶目標(biāo)，縱向移動深挖出的細(xì)節(jié)，然后用膠帶做出分隔，如下面這個例子，在第一個版本中，我只開發(fā)標(biāo)號為1的部分，隨著軟件的不斷迭代，用戶故事地圖也不斷向下推移。此時已經(jīng)完成了這個產(chǎn)品的發(fā)布路線圖。

三、說在最后

“用戶故事地圖”以直觀易變的方式進(jìn)行項目的良好溝通，大多數(shù)人看重的是地圖的形式部分，橫向是講述大故事的部分，縱向是逐步的細(xì)化，但是最關(guān)鍵的是產(chǎn)品的構(gòu)思框架，讓團(tuán)隊成員對想要做出的產(chǎn)品一目了然，大大提高了團(tuán)隊之間相互協(xié)作的默契度，但是要注意的一點(diǎn)就是，功能的開拓要適度，否則這幅用戶地圖永遠(yuǎn)都畫不完。正如《用戶故事地圖》的作者Jeff Patton所說：“如果不需要討論，就不必繪制用戶故事地圖?！?/p>

本文由 @孫昊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。