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

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

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

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

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

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

01. 用戶故事

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

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

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

或者本來可以有更好的實現(xiàn)方案，但是因為只看到功能需求，而沒了解到用戶需求，所以沒機會把更好的方案做出來。

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

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

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

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

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

02. 用戶故事怎么寫？

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

-用戶：是誰要用這個功能；

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

-價值：通過這個功能，用戶能獲得什么價值；

通常用這樣的格式表達：作為一個<用戶>，我想要<功能>，以便于<價值>

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

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

1、獨立的，如果兩個故事有依賴，則合并為一個大的故事

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

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

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

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

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

03. 用戶故事地圖

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

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

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

用戶故事地圖，有這樣幾個作用：

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

2、在團隊內(nèi)達成共識，讓項目成員有全局感，既見樹木，又見森林；

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

04. 創(chuàng)建方法

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

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

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

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

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

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

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

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

– 用戶還有其他選擇么?

– 用戶怎么做才能更爽?

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

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

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

05. 寫在最后

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

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

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

作者：刀哥 PMCAFF、PMTalk作家。