用戶故事作為一種圖形化的需求分析技術，在敏捷開發中被廣泛使用，本文作者對用戶故事展開了梳理分析，希望通過此文能夠加深你對用戶故事的認識。

一、什么是用戶故事？

故事地圖是一門在需求拆分過程中保持全景圖的藝術。—-Jeff Patton《用戶故事地圖》

1. 用戶故事

用戶故事是一種需求分析和產品分解落地的方法，在敏捷開發中被廣泛使用。敏捷開發會通過用戶故事看板工具，來解決團隊一致性的溝通問題、產品的分版本、分階段落地等問題。

用戶故事是一個可視化的過程，使用文字和圖片相結合的方式輔助討論，是一種在產品早期階段建立共識的機制。

2. 用戶故事地圖

用戶故事地圖是一個有風向的圖表，橫軸為時間線，放置延時間線的用戶故事，

縱軸為開發優先級，自上而下。用戶故事地圖覆蓋了所有用戶需求場景。

3. 用戶故事的組成

還記得以前寫作文事件的三要素：時間、地點、人物吧？用戶故事地圖也有三

要素：

1. 角色：誰要使用這個功能。

2. 活動：需要完成什么樣的功能。

3. 業務價值：為什么需要這個功能，這個功能帶來什么樣的價值。

舉例：

作為一個“零售門店店長”，我想要“統計每天有多少人到過我的店鋪”，以便于“我的門店是否有足夠多的客戶關注和客戶來源?！?/p>

4. 3C原則

由于用戶故事的描述信息以傳統的手寫方式寫在紙質卡片上，所以Ron Jeffries(2001)對這三個方面稱為3C：卡片(Card)、對話(Conversation)和確認(Confirmation)。

• 卡片（Card）：用戶故事一般在小卡片上寫著故事的簡短描述，工作量估算等。
• 交談（Conversation）：用戶故事背后的細節來源于和客戶或者產品負責人的交流溝通。
• 確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。

二、為什么使用用戶故事？

1. 避免陷入細節

用戶故事地圖通過講故事的方式和場景化技術可以讓產品經理更多關注用戶場景和用戶體驗，避免沉入技術細節之中。

2. 面向業務

用戶故事不但要說明要什么，還要思考為什么要，它的商業價值是什么？它可以幫助我們聚焦于成果，即產品發布后用戶能使用和感知的東西。

3. 易于理解

用戶故事使用了大家熟悉的“講故事”的表達方式，代入感很強，便于理解，而且全程都是可視化的。用戶故事可以降低溝通與達成共識的成本，可以讓團隊將關注力更多集中在產品上而非術語的理解。

4. 敏捷驅動

用戶故事地圖提供了一種從大故事(史詩故事)到小故事，從高層次場景到低層次場景的需求建模技術，整個過程遵循全場景交付、逐層細化的敏捷開發原則，可以讓開發團隊使用敏捷中的迭代和增量開放方法跟蹤、優化內容，確定版本計劃和目標。

三、如何編寫用戶故事？

編寫用戶故事地圖一般包括4個步驟：

1. 識別機會

在故事編寫準備階段，我們首先要識別用戶面臨的挑戰和大的機會是什么，也就是識別問題。通常由BA或PM 主導產出，主要有幾點內容：

• 這個大想法到底是什么？
• 客戶是誰？我們認為哪些故事會采購這款產品？
• 用戶是誰？采購這款產品的公司中，哪些人會用到該產品，他們會用它來解決什么問題？
• 購買和使用的動機？解決了那些客戶和用戶當前無法解決的問題？使用之后能獲得什么樣的收益？
• 為什么要開發這款產品？如果開發出兵獲得成功，我們的公司又會得到哪些收益？

2. 骨干故事

按照廣度優先而非深度優先的原則嘗試展示用戶故事的全景，包括所有的步驟，用戶的關切和痛點。

通?？梢杂脮r間軸為順序，將用戶的主要活動軌跡分解為幾個關鍵步驟，從而構建一個用戶活動全景圖。

例如，如果我們從“和女友吃西餐”這個故事開始：

首先，我瀏覽菜單和食物的圖片，然后再檢查價格。我希望服務員給我一些推薦，告訴我一些特色菜品。然后我會咨詢一下女友的建議，讓后我下訂單。

我們把這個故事分解為四個步驟：

瀏覽菜單-》選擇菜品-》匹配口味-》下單

按照這個順序，用戶的主要活動如下:

1. 我想要一個菜單，其中列出每個商品的說明、圖片和價格，以便我可以決定要哪些菜品，同時我希望服務員給我一些建議。
2. 我希望每天提供特殊的食物，以便我可以嘗試菜單上通常沒有的獨特菜肴。
3. 我想花點時間了解大家的口味偏好，這樣我會讓大家都感到滿意。
4. 我希望在下單后可以更新菜單，這樣我在點餐的過程中會更加舒心。

3. 拆分故事

向深度拓展，此時我們討論：用戶在這關鍵步驟還會做什么？怎樣才能更爽？出了問題以后怎么辦？

可以按照以下幾個維度對細節進行歸類，分別是：故事細節、想法、痛點、機會、情緒。其中情緒可以通過固定的問題獲得，也可以通過用戶想法、用戶的痛點結合主觀判斷。

繼續拆分“和女友吃西餐”這個故事：

1. 我想要一個菜單，我希望提供一些菜品搭配建議或套餐組合，以便我可以快速做出選擇。
2. 我希望菜單信息中包含了卡路里信息，我有健康飲食的習慣
3. 我希望可以提前預定一個蛋糕和現場有音樂伴奏，這樣可以給女友更多的驚喜。
4. 我希望可以可以在下單時提供多種支付選擇，這樣我會避免忘帶現金的尷尬

按照這樣的拆分方式我們可以細分出更多層級，層級的規模取決于主干故事的規模。

4. 溝通和確定

通過討論果斷去掉那些無助于取悅用戶用戶的東西，確定達成目標的最小解決方案(MVP)?？梢园磳崿F順序和優先級，將最小可行方案進一步切分。這些用戶故事加在一起就構成了產品需要做的主要功能。

四、如何實現一個電子版的用戶故事地圖？

通常我們可以將用戶故事的描述信息以傳統的手寫方式寫在紙質卡片上，這樣便于大家討論。作為便于記錄和保存，我們也可以使用Leangoo這樣的工具來實現一個可以協同工作的電子版用戶故事地圖。

Leangoo看板工具很容易實現，在看板中，我們有列表和泳道的概念，列表代表了縱向的緯度，泳道代表了橫向的緯度。

在Leangoo中，使用列表代表不同的發布，我們通常建立這么幾個列表：史詩級故事(主干故事)，Sprint1，Sprint2，Sprint3-N，已交付的故事。橫向的泳道代表的是史詩故事和史詩故事拆分的子故事的對應關系。如下圖所示：

1. 故事背景

在園區、景區、校區等業務環境中，我們經常會遇到故障上報的場景：故障接待員員在巡視過程中如果遇到各種異常，需要通過客戶端系統上報故障并提交故障信息，然后由項目經理安排故障處理員現場處理。

故障上報的主要活動步驟為：管理賬號-》上報故障-》安排人員處理-》處理故障。

2. 主干故事

0-1.作為系統管理員,我希望可以初始化報障接待員、項目經理、故障處理員的身份信息,以便我控制系統的用戶權限

0-2.作為報障接待員,我希望可以在遇到故障時填寫并提交故障登記表,以便我可以更有效的完成故障登記工作。

0-3.作為項目經理,我希望可以收到填好的故障登記表, 以便我可以對項目的故障處理進行安排。

0-4.作為故障處理員,我希望可以及時的處理設備發生的故障,以便我可以做好自己的工作。

3. 二級故事

1-1.作為系統管理員,我希望可以在遺失密碼時提供面找回功能，以便管理我的賬號

1-2.作為報障接待員,我希望可以在遇到故障時登記客戶信息,以便統計。

1-3.作為項目經理,我希望可以可以按項目查詢維修單和關閉無效任務單，以便維護和管理維修單。

1-4.作為故障處理員,我希望在故障處理后可以記錄故障原因和故障處理方法,以便歸納和總價故障案例。

4. 三級故事

2-1.作為系統管理員,我希望可以記錄操作日志，以便賬號安全

2-2.作為報障接待員,我希望可以在遇到故障時可以上報附件,以便增加現場原始記錄。

2-3.作為項目經理,我希望可以可以按時間/原因/客戶等維度查詢故障單，以便維護和管理維修單。

2-4.作為故障處理員,我希望在可以將任務單重定向到其他人，以便在指派錯誤的情況下，指派任務可以繼續履行

通過Leangoo將上述用戶故事記錄下來同時生成用戶故事看板：

通過Leangoo看板，我們可以非常方便的通過故事地圖把產品的需求全景圖展示出來，產品的規劃也一目了然，這對于我們持續地關注產品核心價值，更好地進行產品規劃非常有幫助。

#相關閱讀#

B端產品經理養成記（1）：業務場景

作者：濤哥，微信公眾號：濤哥筆談。前華為高級產品經理，TOGAF認證專家，PMP認證專家，PPV課數據科學社區創始人，數字化轉型實踐者

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

題圖來自Unsplash，基于CC0協議