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

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

1、瀑布模型

圖（1）

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

2、敏捷開發的優勢

圖（2）

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

3、用戶故事地圖的誕生

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

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

二、如何創建用戶故事地圖？

1、前期準備

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

2、整理創意框架

在正式開始創建用戶故事之前，大家要在一起重新明確產品的創意框架，如：

• 明確產品的目標是什么？
• 能為用戶解決哪些問題？
• 公司、用戶都能獲得哪些收益？

然后大家統一答案，把明確的目標寫在便利貼上，按照優先級排好順序。

3、刻畫用戶畫像

下面針對優先級最高的目標開始討論，開始頭腦風暴：

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

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

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

4、大故事

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

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

5、深挖細節

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

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

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

6、劃分MVP發布計劃

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

三、說在最后

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

本文由 @孫昊 原創發布于人人都是產品經理。未經許可，禁止轉載。