用戶故事地圖，產(chǎn)品經(jīng)理必須掌握的分析利器

在產(chǎn)品工作中，有時(shí)候會(huì)遇到這樣一些問題：

1、做產(chǎn)品規(guī)劃時(shí)，會(huì)漏掉一些關(guān)鍵功能，沒有很好的需求分析方法論；

2、版本迭代時(shí)，只見樹木，不見森林，不停的做功能需求，卻忽略了產(chǎn)品全景；

3、研發(fā)拿到的是產(chǎn)品提交的功能需求，卻沒有弄清楚真實(shí)的用戶需求，開發(fā)出來的功能達(dá)不到預(yù)期。

最近get到一個(gè)新技能，用戶故事地圖，利用用戶故事地圖，就可以解決以上問題。

01. 用戶故事

在講用戶故事地圖之前，先來說下用戶故事。

用戶故事，最早由Kent Beck提出，Kent Beck是敏捷開發(fā)創(chuàng)始人，提出用戶故事的本意，是想解決共識(shí)的問題。

用戶基于某個(gè)場景，提出了自己的需求，產(chǎn)品經(jīng)理基于用戶的需求提出解決方案，將其轉(zhuǎn)為功能需求，研發(fā)基于產(chǎn)品的功能需求文檔進(jìn)行開發(fā)， 最終發(fā)現(xiàn)開發(fā)出來的功能根本就不是用戶想要的。

或者本來可以有更好的實(shí)現(xiàn)方案，但是因?yàn)橹豢吹焦δ苄枨?，而沒了解到用戶需求，所以沒機(jī)會(huì)把更好的方案做出來。

產(chǎn)品在產(chǎn)品的認(rèn)知范圍內(nèi)做決策，研發(fā)基于研發(fā)的認(rèn)知做決策，而產(chǎn)品的認(rèn)知和研發(fā)的認(rèn)知卻不一樣。

產(chǎn)品經(jīng)理不斷的細(xì)化需求文檔，寫得越來越標(biāo)準(zhǔn)，但不同的人，對(duì)相同的文檔，理解不一樣，共識(shí)問題想完全靠文檔解決，是不現(xiàn)實(shí)的。

那如果讓研發(fā)能知道用戶的真實(shí)需求，是不是就能解決這個(gè)問題呢？

于是Kent Beck 就提出用戶故事這個(gè)方法，大家都喜歡聽故事，從一開始，就只說用戶故事，而不是只說功能需求。

這樣，產(chǎn)品和研發(fā)對(duì)用戶需求的理解是一致的，能更好的達(dá)成共識(shí)。

02. 用戶故事怎么寫？

一個(gè)完整的用戶故事，應(yīng)該包含三部分內(nèi)容：用戶、功能、價(jià)值。

-用戶：是誰要用這個(gè)功能；

-功能：具體是什么功能；

-價(jià)值：通過這個(gè)功能，用戶能獲得什么價(jià)值；

通常用這樣的格式表達(dá)：作為一個(gè)<用戶>，我想要<功能>，以便于<價(jià)值>

例如：作為一個(gè)<在外務(wù)工的農(nóng)民工>，我想要<一匹馬>，以便我<春節(jié)可以回家過年，與親人團(tuán)聚>。對(duì)于這個(gè)用戶故事，由于產(chǎn)品經(jīng)理沒見過車，也不知道有車的東西，于是提供了馬這個(gè)解決方案，但是開發(fā)人員知道有車，就會(huì)提出車這個(gè)更好的解決方案。

寫用戶故事地圖，應(yīng)該遵循幾個(gè)原則：

1、獨(dú)立的，如果兩個(gè)故事有依賴，則合并為一個(gè)大的故事

2、可討論的，故事本身就是一個(gè)溝通的工具，用戶故事不是合同，不需要寫的過于詳細(xì)；

3、有價(jià)值的，這是用戶故事最重要的一條，要是沒有價(jià)值，還做他干什么呢？價(jià)值讓研發(fā)不僅做，還要知道為什么做；

4、可估算的，估算用戶故事，可以幫我們更好的判斷工期，評(píng)估是否有足夠的資源，有多少人辦多少事，如果不能估算，可能有幾種原因：①研發(fā)不了解業(yè)務(wù)；②研發(fā)缺少技術(shù)知識(shí)；③故事太大；

5、顆粒度小的，過大的用戶故事不便于評(píng)估，如果雙周迭代，3-5天的顆粒度是合適的；

6、可測試的，如果故事不可測試，就無法衡量是否達(dá)到預(yù)期，是沒有評(píng)判標(biāo)準(zhǔn)的；

03. 用戶故事地圖

上面說了用戶故事，再來說下用戶故事地圖。

用戶故事地圖，是由用戶故事組成的全景圖，用戶故事由活動(dòng)和用戶故事組成，活動(dòng)是完成用戶目標(biāo)的核心步驟，用戶故事是根據(jù)核心步驟拆分出來的小任務(wù)。

例如，用戶在電商產(chǎn)品，核心步驟可以分為：瀏覽商品——下單——付款——收貨——評(píng)價(jià)，在瀏覽商品這個(gè)步驟里，可以分為更細(xì)的任務(wù)，如查看首頁、搜索、對(duì)比、查看詳情、查看評(píng)論等。

用戶故事地圖，有這樣幾個(gè)作用：

1、和業(yè)務(wù)、研發(fā)，甚至用戶一起梳理需求，不遺漏關(guān)鍵功能；

2、在團(tuán)隊(duì)內(nèi)達(dá)成共識(shí)，讓項(xiàng)目成員有全局感，既見樹木，又見森林；

3、更好的規(guī)劃版本，每次新迭代，都是做的當(dāng)前最重要的功能，不浪費(fèi)研發(fā)資源；

04. 創(chuàng)建方法

繪制用戶故事地圖，需要召開一次用戶故事會(huì)議，參與會(huì)議的人必須是各崗位關(guān)鍵角色，包括產(chǎn)品負(fù)責(zé)人、項(xiàng)目負(fù)責(zé)人、業(yè)務(wù)負(fù)責(zé)人、技術(shù)和老板，人數(shù)控制在7人以內(nèi)，但不要少于3人。這些人都代表了平臺(tái)建設(shè)中的主要角色的看法。

同時(shí)，要提前準(zhǔn)備材料。和WorkShop一樣，我們?cè)陂_始之前，要準(zhǔn)備一個(gè)白板、不同顏色的便利貼、膠帶等等。同時(shí)還要明確產(chǎn)品目標(biāo)，要解決的用戶問題以及或許有的收益等等。

圖片來自網(wǎng)絡(luò)，侵刪

1、第一步，進(jìn)行產(chǎn)品定義。我們要確定我們的用戶是誰？解決什么問題？用戶目標(biāo)是什么？產(chǎn)品目標(biāo)是什么？通過這些問題，可以基本框定整體的范圍。

2、第二步，梳理骨干故事。梳理故事要確定好一級(jí)故事、二級(jí)故事，保證故事的完整性，同時(shí)要廣度優(yōu)先，而非深度。最后的效果就是看到故事群。

3、第三步，拆分故事。在剛剛梳理的每一個(gè)二級(jí)故事下面做停留，去拆分二級(jí)故事獲取更多細(xì)節(jié)內(nèi)容。項(xiàng)目組會(huì)圍繞這個(gè)故事寫出很多細(xì)節(jié)來。

在這個(gè)過程中，先讓大家在一定時(shí)間內(nèi)按照自己的想法寫出來，每一條寫在一張卡片上，做到相互不干擾，然后每個(gè)人出聲說出自己的卡片內(nèi)容，讓所有人了解并貼在墻上。

項(xiàng)目組人在寫想法的時(shí)候，相當(dāng)于腦暴的過程，這時(shí)可以通過一些問題來刺激大家腦暴出更多的內(nèi)容，比如：

- 用戶在這步具體做什么?

- 用戶還有其他選擇么?

- 用戶怎么做才能更爽?

- 出現(xiàn)問題如何處理?

在真實(shí)業(yè)務(wù)當(dāng)中，發(fā)生特殊情況該怎么辦？所以這一步我們將盡量多的關(guān)注到所有場景的故事。做完這步，我們已經(jīng)獲取到了足夠多的細(xì)節(jié)信息，整個(gè)項(xiàng)目組都會(huì)做到對(duì)產(chǎn)品又見森林又見樹木的狀態(tài)。

4、第四步，溝通確認(rèn)。這一步是將前面豐滿而又臃腫的故事，通過對(duì)標(biāo)標(biāo)題、充分討論，把公認(rèn)的留下來，無用的剔除掉，同時(shí)區(qū)分要做的故事細(xì)節(jié)的優(yōu)先級(jí)。完成所有故事梳理后，就出現(xiàn)了下面這張圖：用戶故事地圖。

圖片來自網(wǎng)絡(luò)，侵刪

05. 寫在最后

用戶故事是方便達(dá)成共識(shí)的一種溝通工具，用戶故事包含3個(gè)要素：用戶、功能、價(jià)值，寫用戶故事，應(yīng)該遵循6個(gè)原則：獨(dú)立的、可討論的、有價(jià)值的、顆粒度小的、可估算的、可驗(yàn)證（測試）的。

用戶故事地圖是由用戶故事組成，通過用戶故事地圖，可以更好的分析需求、版本規(guī)劃，做到既見樹木又見森林，創(chuàng)建用戶故事地圖，分為四步：產(chǎn)品定義、梳理骨干、拆分故事、溝通確認(rèn)。

用戶故事是敏捷開發(fā)的起始點(diǎn)，如果團(tuán)隊(duì)在用敏捷開發(fā)，而又不知道用戶故事，那就不是敏捷開發(fā)，利用好用戶故事和用戶故事地圖這2個(gè)工具，可以更好的踐行敏捷開發(fā)。

參考：

《用戶故事地圖》

如何做好用戶故事地圖？來看螞蟻金服的實(shí)戰(zhàn)案

https://www.uisdc.com/user-maps-design-ali-case