產品經理的日常主要工作就是與需求打交道，如何能夠快速準確地洞察用戶或客戶的需求，讓功能直擊用戶痛點是很多產品經理的愿望。而筆者就發現，利用用戶故事，可以有效幫助產品經理解決產品需求策劃的問題。

前段時間看了一本書《敏捷軟件開發：用戶故事實戰》，顧名思義，整本書大概講的是在敏捷軟件開發中，如何運用用戶故事來開發和迭代客戶需求。

“故事”在百度百科的定義是：通過敘述的方式講一個帶有寓意的事件，或是陳述一件往事，側重于事件發展時的描述。應用到軟件開發流程中，用戶故事，就可以理解為是敘述用戶在使用軟件功能時的過程。

整本書所表達的思想就是：如何在敏捷項目中用用戶故事思維做產品開發。所以，用戶故事的方法適用于敏捷項目。

換句話說，針對產品需求和目標明確的敏捷開發項目，使用用戶故事更有益于開發出符合客戶需求的功能。

目前個人在實際產品工作中，處理需求的過程，會經常涉及需求場景梳理，看完本書后，感覺用戶故事的一些思路和方法，有助于日常需求場景的梳理。下面就結合書中的理解，說說用戶故事在實際開發過程中的流程以及使用方法。

一、本書的思想：運用到實際項目中的具體流程

敏捷項目-用戶故事開發流程

1. 識別用戶角色

通過梳理識別該需求的用戶，然后針對該需求角色進行用戶角色建模，簡單講就是通過先發散再收斂的方法識別初始角色，然后聚合分類、去重，最后形成幾個典型的用戶角色，同時抽象出對應的用戶畫像。

2. 梳理用戶故事

根據整理出來的用戶畫像，梳理各用戶角色的用戶故事，編寫用戶故事的過程其實也是發散到收斂的過程。

如果公司有客戶拜訪和調研的條件，可以直接與客戶進行溝通，那用戶故事自然相對客觀；如果不具備客戶訪談的條件，那就只能發揮場景想象力來頭腦風暴了。

3. 故事評估

此階段主要是評估用戶故事，對梳理出來的故事清單進行評估，主要針對故事的理想實現時間、復雜性以及對于團隊和客戶的價值等方面。

評估時可以賦予每個故事一定的估算值，來客觀顯示這些故事點的重要性。此階段故事評估時使用的估算值，既可以排優先級，還可以估算速率。

4. 計劃發布

在創建發布計劃時，需要確定故事優先級和迭代速率。優先級評估的方法和評估需求優先級的方法類似。書中講的四種評估優先級為必須要有、應該有的、可以有的、不需要有，當然這不是隨便決定的，而是根據故事評估階段每個故事的估算值來排序，同時結合估算的迭代速率，即通過計算估算值來決定每次迭代多少個故事點。

5. 驗收測試

驗收測試階段主要測試發布的故事有沒有完成，書中建議是最好客戶可以參與驗收，但實際對于大多數公司來講，是不具備這個條件的。

除講述運用用戶故事貫穿整個開發流程外，本書還順便提到了技術開發時，可以使用結對編程，可大大減少返工率，并最大程度優化代碼架構。

總之，本書中描述的開發流程與互聯網從0-1的產品開發是有區別，因為是敏捷開發項目，因此流程是建立在產品需求和目標明確的前提下，沒有需求挖掘的過程，直接通過調研和規劃用戶故事的方法進行計劃迭代。

二、用戶故事幫助完善產品用戶場景

產品經理的日常主要工作就是與需求打交道，如何能夠快速準確地洞察用戶或客戶的需求，開發的功能直擊用戶痛點是很多產品經理的愿望。

平時在分析需求時，大多按照需求的三要素，用戶/角色、場景、任務路徑來梳理目標用戶的核心需求。

可產品目標用戶的真實需求，往往就誕生在真實的業務場景里，這點體驗在B端產品里尤為明顯。因此接到需求后，在進入功能策劃階段之前，梳理完善的、核心的場景就顯得至關重要。

那么如何運用用戶故事來幫我們梳理完善的場景呢？可以分三步走。

1. 結合目標用戶畫像，梳理目標用戶對應的核心使用場景

C端產品通常都有幾個典型的用戶畫像，B端產品也不例外，也可以梳理出來自家產品對應的幾個典型客戶畫像。

按照2/8定律，雖然這幾類典型的用戶/客戶可能只占全部注冊用戶的20%，但通?？梢愿采w產品中80%的功能，或者說可以貢獻產品收益的80%。

因此在梳理產品用戶的核心場景時，首先要針對此類用戶的使用場景進行調研。

2. 根據典型用戶的核心場景拆分需求

梳理完核心場景后，再將核心需求從場景中提煉出來，此時的需求應該就是最接近用戶/客戶的真實期望了。將場景用文字描述出來，可以整理成表格清單，便于后續整理。

表格清單示例

3. 需求點轉化為用戶故事

從核心場景提煉出來的需求點，還可以進一步細化為單個或多個故事點。

產品需求在一定程度上可以理解為故事，用戶在描述需求時，其實就是在描述用戶期望的使用場景，可以理解為用戶是在敘述他是在何種情境下，通過/使用何種物質，如何完成某個行為的。

但我們在提煉出需求的時候，往往有很多一句話需求，關于這個需求的細節無法很好地體現出來。甚至很多需求點不一定就是功能點，往往需求只是目的，達到目的的方法卻不止一個。

因此就需要通過用戶故事的方法來細化需求場景，便于充分拆解當前的需求，同時也有利于充實用戶場景，在需求策劃階段的決策更有依據，功能設計也更加全面。

三、結合書中理解，說說用戶故事如何編寫

1. 用戶故事的價值

確定目標用戶畫像和核心使用場景后，在策劃具體功能之前，應梳理用戶在使用該功能時的場景，然后以用戶故事的形式羅列出來。用戶故事可以用于針對某個需求功能做計劃和提示，有助于充實使用場景的細節。后續可對用戶故事清單進行優先級排序，用于決策哪些用戶故事應該優先被實現。

2. 用戶故事的特點

1. 獨立的：每個故事盡可能相互獨立，相互依賴的故事可以合并成一個更大但更獨立的故事；
2. 對用戶或客戶有價值的：是客戶真正關注的，可以真正解決用戶問題，滿足用戶需求的故事；
3. 可估算的：用于后續產品開發進行工作量估算，必要時要拆分故事點，便于項目管控；
4. 可測試的：測試人員可根據用戶故事，直接測試該故事點是否已被成功開發；
5. 小的：單個用戶故事盡可能可以被量化和評估，保證每個故事盡可能小，便于窮盡故事細節。

3. 用戶故事示例

了解了用戶故事的價值和特點后，以“115”產品中的記錄功能做個示例，當我們從核心場景中提煉出一些需求點后，就需要進一步將這些需求點展開，便于后續需求規劃和原型策劃。

“記錄”功能的用戶故事：

1. 用戶可在115上快速新增記錄，可直接選擇某個記錄分類進行添加；
2. 用戶可自定義創建記錄分類，添加記錄后可歸類到某個分類下；
3. 用戶在記錄時支持文字編輯和本地圖片上傳；
4. 用戶在編輯記錄時，可添加記錄時用戶的位置信息；
5. 用戶在編輯記錄時，可選擇拍攝照片上傳；
6. 用戶添加的記錄支持備注標簽，并且可根據標簽查找記錄；
7. 用戶可以將記錄的文本內容進行復制、粘貼；
8. 用戶可選擇部分文本記錄內容，快速轉為待辦項或日程；
9. 用戶可將單個記錄進行重點標記或星標；
10. 編輯記錄時，用戶可在文本框實時查看當前已編輯的文本字數。

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

題圖來自Unsplash，基于CC0協議