無論是做產(chǎn)品還是做運營谢床，需求分析都是一個很重要的環(huán)節(jié)。用戶故事地圖作為一種有效的需求工具稽物，越來越廣泛地應用于開發(fā)實踐中。

一款產(chǎn)品的成功折欠，在于比競爭對手更好地滿足了用戶需求贝或，而這并不是一件容易的事吼过。這是因為，你或多或少總會在以下3件事上掉坑里：

• 讀懂需求本身咪奖，能夠抓住核心痛點
• 選擇用自己獨特的方式來滿足
• 將需求實現(xiàn)拆分成大小不同的故事盗忱，比競爭對手速度更快、做得更漂亮

接下來我們聚焦于尤其適用于多需求羊赵、復合型產(chǎn)品的第三個坑售淡。

掌握故事地圖的方法之后你會發(fā)現(xiàn)，無論你是一個喜歡觀察用戶行為慷垮、提取用戶行為模式的交互型產(chǎn)品經(jīng)理揖闸，一個注重用戶體驗、尋找用戶high點的用戶運營料身，還是其他任何會參與到業(yè)務流程當中汤纸、和其他部門發(fā)生協(xié)作的角色，這都是一種在需求拆分過程中保持全景的視角的技術(shù)芹血，一種在部門協(xié)作時更有效的溝通方式贮泞。

關于MVP

最小可行產(chǎn)品（MVP），是指可以產(chǎn)生預期成果的最小產(chǎn)品發(fā)布幔烛。這里需要說清楚啃擦，“最小”是針對哪些用戶而言的？這些用戶需要通過軟件達成哪些目標饿悬？

另外令蛉，很少有哪個產(chǎn)品是全新的，往往實在現(xiàn)有產(chǎn)品上增加新的功能或者提升現(xiàn)有功能狡恬。所以珠叔，又可以講最小可行方案：最小可行方案是指可以產(chǎn)生預期成果的最小發(fā)布方案。

關于MVP的更多介紹這里不多陳述弟劲，感興趣的可以看這篇文章：《MVP的四級臺階》

如何找到MVP祷安？

很多時候，一個完美產(chǎn)品要做的事情多到我們很快就不堪重負兔乞。全部功能的完成汇鞭，看起來非常重要，但是當我們時候回過頭來思考那些特定用戶以及用戶實現(xiàn)其目標的基本功能時庸追，會發(fā)現(xiàn)這些用戶和訴求可以用一兩句精煉的話來概括霍骄。

首先，創(chuàng)建用戶故事地圖

通常大家來自不同的團隊锚国，每個團隊都專注于各自不同的領域腕巡，但是要交付的是一個產(chǎn)品。大家必須齊心協(xié)力交付這個產(chǎn)品血筑，不可以根據(jù)各自團隊的視角來制定發(fā)布計劃绘沉，必須以可視化的方式展示出所有的依賴煎楣。

而用戶故事地圖已經(jīng)成為敏捷需求規(guī)劃中的一個流行方法，它可以將你的backlog（產(chǎn)品功能列表）變成一張二維地圖车伞，而不是傳統(tǒng)的簡單列表择懂。

簡而言之，故事地圖用來建立共識另玖，幫助團隊以可視化的方式展示依賴關系困曙。

它可以解決以下問題：

• 讓你更容易看清backlog的全貌
• 為新功能篩選（grooming）和劃定優(yōu)先級提供了更好的工具，幫助你做出決策
• 便于使用靜默頭腦風暴模式和其他協(xié)作方式來產(chǎn)生用戶故事
• 幫助你更好的進行迭代增量式開發(fā)谦去，同時確保早期的發(fā)布可以驗證整體架構(gòu)和解決方案
• 為傳統(tǒng)的項目計劃提供了一個更好的替代工具
• 有助于激發(fā)討論和管理項目范圍
• 允許你從多個維度進行項目規(guī)劃慷丽，并確保不同的想法都可以得到采納

總之，創(chuàng)建故事地圖的過程可以幫助發(fā)現(xiàn)設計中的坑鳄哭，甚至有些設計中遺漏的重點特性之間的關鍵環(huán)節(jié)要糊，也可以提前發(fā)現(xiàn)。

那么妆丘，召開一個用戶故事地圖的討論會議吧锄俄！

你需要做的準備是：

• 一個相對不被打擾的空間
• 一塊白板（如果產(chǎn)品復雜，涉及到的用戶行為動作較多勺拣，可以用地板奶赠、玻璃墻等。）
• 3-5個人左右的討論組（產(chǎn)品药有、業(yè)務毅戈、交互設計、運營等塑猖，注意人數(shù)不宜過少和過多竹祷，因為更少的人意味著你無法獲得足夠的建議，而更多人則會因為討論和協(xié)調(diào)降低會議效率羊苟。）
• 便利貼若干（最好有不同顏色）

這個會議，就是讓所有參與者一起用便簽感憾，一張一個動作蜡励，從左至右按照時間線，描繪用戶在產(chǎn)品使用場景下所發(fā)生的所有用戶行為阻桅。

建議使用靜默頭腦風暴模式凉倚，讓每個人在便簽紙上寫下自己認為重要的“所要做的事情”也就是用戶任務（user task）。每個人都用同樣顏色的便簽來書寫自己的用戶任務描述嫂沉，這個階段不要互相討論稽寒。

一旦大家都基本完成了準備，讓每個人輪流大聲讀出自己的內(nèi)容趟章，并把便簽紙全部放置在桌面上杏糙，這時如果出現(xiàn)重復的內(nèi)容就可以省略掉：

• 根據(jù)你的產(chǎn)品規(guī)模慎王，這個過程可能需要3-10分鐘的時間；你可以觀察大家的行為來判斷是否需要停止宏侍。
• 盡量每張便簽以一個動詞開頭赖淤，如：發(fā)送郵件、創(chuàng)建聯(lián)系人谅河、添加用戶等咱旱。
• 這些便簽組成了一級用戶故事，Jeff Patton稱為用戶任務（user tasks）绷耍，它們組成了用戶故事地圖上的 “行走的骨骼” （the walking skeleton）部分吐限。
• 這時可以提示參與者：我們只用了很少的時間就完成了需求的收集過程，而且有些內(nèi)容你可能沒有想到褂始，而其他人幫你想到了诸典。

同一時間發(fā)生的，就寫在同一位置的下方病袄。出現(xiàn)同一場景不同可能的動作時搂赋，可能會形成不同的分支動作，直到重回主線或者結(jié)束支線益缠。

然后脑奠，讓大家將桌面上所有的便簽進行分組，將類似的任務分為一組幅慌。如果發(fā)現(xiàn)重復的內(nèi)容宋欺，就略過。

需要提醒的是胰伍，這是一個自下而上的齿诞、不給自己建立任何預先假設的方法。它讓你忘記自己曾經(jīng)把某個行為判定為“必需”還是“非必需”骂租。

當全景圖出現(xiàn)的時候祷杈，你再來合并掉同時的、無關的渗饮，你會看到在路線的關鍵節(jié)點上但汞，哪些用戶體驗非常重要。從用戶故事圖景出發(fā)互站，來看自己的產(chǎn)品私蕾，會有一種豁然開朗的全局感。

故事地圖完成后胡桃，我們會發(fā)現(xiàn)踩叭，要做的事情太多了，要完成所有的事情，項目日期幾乎看不到頭容贝。這時候需要問：“要達到XXX效果自脯，我們需要用到所有的功能碼？”

也就是說嗤疯，我們需要聚焦于系統(tǒng)外的預期成果來決定系統(tǒng)內(nèi)需要什么功能冤今！

其次，劃分MVP發(fā)布計劃

在用戶故事地圖上劃分出第一個發(fā)布需要做的內(nèi)容茂缚，其他的在之后的版本中完成戏罢。

思考過程是這樣的：“如果能在XX預期里達到Y(jié)Y成果，那么產(chǎn)品亮相時看起來會不錯脚囊。發(fā)布計劃中的所有功能都是用戶的基本需求龟糕，并且是驚艷的，可以讓人眼前一亮悔耘〗菜辏”

聚焦于成果，即發(fā)布后用戶能使用和感知的東西衬以，切分發(fā)布計劃應該以成果為導向缓艳。

接著，劃分發(fā)布路線圖

整個故事地圖包含許多的東西看峻，但是完成所有功能所需的時間通常是無法接受的阶淘。這就需要我們聚焦于最首要的一個目標成果，識別出第一個發(fā)布要包含哪些內(nèi)容互妓。

我們水平劃分用戶故事地圖上的便簽溪窒，在劃分的每一個發(fā)布的左邊貼上便簽，上面寫上少量文字描述預期能產(chǎn)生的成果冯勉。

然后在各個發(fā)布之間移動卡片澈蚌，盡可能匹配各個發(fā)布的成果預期。這樣灼狰，在整個地圖的左側(cè)宛瞄，是發(fā)布的名稱列表，這些名稱標識著目標成果交胚，這就是發(fā)布路線圖坛悉。

聚焦于特定的目標成果，這是排定開發(fā)工作優(yōu)先級的秘密承绸。

最后，為成果排列優(yōu)先級挣轨，而非功能军熏。

拆分大型輸出的秘密在于聚焦于小的、特定的成果卷扮。成果的背后是參與特定活動的特定用戶之特定行為的改變荡澎。

通過聚焦于即將發(fā)生的活動均践，選擇參與活動的用戶。但是摩幔，聚焦于活動用戶彤委，無法同時滿足其他用戶的需求，這些用戶在比較長的一段時間內(nèi)還是繼續(xù)通過現(xiàn)有系統(tǒng)來滿足需求或衡。你無法一次性取悅于所有人焦影。

用戶故事地圖樣例

電子郵件系統(tǒng)的用戶故事地圖

• 第一行對這些操作郵件的事情進行了分組。

• 第二行所包含的內(nèi)容就是“大家在電子郵件系統(tǒng)所要做的事情”封断，包括類似：書寫郵件斯辰，發(fā)送郵件，創(chuàng)建約會等等坡疼。

• 黃色的便簽的第一行包含了最小化的用戶故事彬呻，如：寫郵件只包括發(fā)件人，收件人柄瑰，標題闸氮，內(nèi)容和發(fā)送取消按鈕。其他如支持RTF教沾，HTML格式蒲跨，添加附件，從通訊部獲取聯(lián)系人郵件地址等详囤，都不在此行财骨，放入更靠下的便簽中。

• 黃色便簽右上角更小的藍色和橘黃色便簽表示了不同的狀態(tài)藏姐，比如：藍色代表完成隆箩，橘黃色代表進行中（wip），這樣你就可以看到項目的進展羔杨。

現(xiàn)在如果我們專注于從左到右完成第一行的黃色便簽捌臊，我們就可以確保很快發(fā)布一款包含了最最基本功能的郵件系統(tǒng)。這樣我們就可以驗證我們的郵件系統(tǒng)整體架構(gòu)（發(fā)送郵件同時確保其可以被閱讀）可行兜材。

同時理澎，也可以幫助我們對系統(tǒng)的功能進行端到端的測試，確保我們可以從用戶處獲取到反饋曙寡，知道我們是否解決了它們的問題（提供了商業(yè)價值）糠爬。注意我們在第一行沒有包含“刪除郵件”這一功能，因為并不一定要完成所有用戶任務的開發(fā)举庶。

用戶故事地圖規(guī)范

• 第2個步驟中的便簽表示 用戶任務（user tasks）执隧，藍色便簽
  我們可以把這理解為用戶的大故事，這個是用戶故事地圖的框架。
• 第3-4個步驟中的便簽表示 用戶行為（user activies）镀琉，橘色便簽峦嗤。Jeff 稱這兩行的內(nèi)容為 “行走的骨骼”（walking skeleton）和 “主干”（backbone）
• 用戶故事（user stories），黃色便簽在每個用戶任務下自上而下排列屋摔，便于我們確定優(yōu)先級
  我們可以把這理解為用戶的小故事烁设，是用戶故事地圖的細節(jié)。記錄員要把每一個小細節(jié)都寫在便利貼上钓试，豎向排列在“大故事”卡片的下面装黑。如果有與大故事無關的其他細節(jié)，可以放在“用戶卡片”的上方區(qū)域亚侠。

到此為止曹体，一個巨大的恐龍骨骼一樣的“用戶故事地圖”出現(xiàn)在白板上，甚至硝烂，它可以占滿一面墻箕别。一般來說用戶會按照從左到右的順序來使用你的系統(tǒng)（用戶故事地圖）。

最后滞谢，正如我們上文所言串稀，為了縮短項目周期，我們要在“用戶故事地圖”上進行MVP的內(nèi)容篩選狮杨，把最重要的內(nèi)容放在前面母截。橫向移動用戶目標，縱向移動深挖出的細節(jié)橄教，然后用膠帶或其它工具做出分隔清寇，以此劃分不同版本。

隨著軟件的不斷迭代护蝶，用戶故事地圖也會不斷向下推移华烟。此時，我們就完成了這個產(chǎn)品的發(fā)布路線圖持灰。

小結(jié)

“用戶故事地圖”以直觀易變的方式進行項目的良好溝通盔夜，大多數(shù)人看重的是地圖的形式部分，橫向是講述大故事的部分堤魁，縱向是逐步的細化喂链。

但是最關鍵的是產(chǎn)品的構(gòu)思框架，讓團隊成員對想要做出的產(chǎn)品一目了然妥泉，大大提高了團隊之間相互協(xié)作的默契度椭微。

要注意的一點就是，功能的開拓要適度盲链，否則這幅用戶地圖永遠都畫不完赏表。