用戶故事:如何在敏捷開發中助力產品需求策劃?
產品經理的日常主要工作就是與需求打交道,如何能夠快速準確地洞察用戶或客戶的需求,讓功能直擊用戶痛點是很多產品經理的愿望。而筆者就發現,利用用戶故事,可以有效幫助產品經理解決產品需求策劃的問題。
前段時間看了一本書《敏捷軟件開發:用戶故事實戰》,顧名思義,整本書大概講的是在敏捷軟件開發中,如何運用用戶故事來開發和迭代客戶需求。
“故事”在百度百科的定義是:通過敘述的方式講一個帶有寓意的事件,或是陳述一件往事,側重于事件發展時的描述。應用到軟件開發流程中,用戶故事,就可以理解為是敘述用戶在使用軟件功能時的過程。
整本書所表達的思想就是:如何在敏捷項目中用用戶故事思維做產品開發。所以,用戶故事的方法適用于敏捷項目。
換句話說,針對產品需求和目標明確的敏捷開發項目,使用用戶故事更有益于開發出符合客戶需求的功能。
目前個人在實際產品工作中,處理需求的過程,會經常涉及需求場景梳理,看完本書后,感覺用戶故事的一些思路和方法,有助于日常需求場景的梳理。下面就結合書中的理解,說說用戶故事在實際開發過程中的流程以及使用方法。
一、本書的思想:運用到實際項目中的具體流程
敏捷項目-用戶故事開發流程
1. 識別用戶角色
通過梳理識別該需求的用戶,然后針對該需求角色進行用戶角色建模,簡單講就是通過先發散再收斂的方法識別初始角色,然后聚合分類、去重,最后形成幾個典型的用戶角色,同時抽象出對應的用戶畫像。
2. 梳理用戶故事
根據整理出來的用戶畫像,梳理各用戶角色的用戶故事,編寫用戶故事的過程其實也是發散到收斂的過程。
如果公司有客戶拜訪和調研的條件,可以直接與客戶進行溝通,那用戶故事自然相對客觀;如果不具備客戶訪談的條件,那就只能發揮場景想象力來頭腦風暴了。
3. 故事評估
此階段主要是評估用戶故事,對梳理出來的故事清單進行評估,主要針對故事的理想實現時間、復雜性以及對于團隊和客戶的價值等方面。
評估時可以賦予每個故事一定的估算值,來客觀顯示這些故事點的重要性。此階段故事評估時使用的估算值,既可以排優先級,還可以估算速率。
4. 計劃發布
在創建發布計劃時,需要確定故事優先級和迭代速率。優先級評估的方法和評估需求優先級的方法類似。書中講的四種評估優先級為必須要有、應該有的、可以有的、不需要有,當然這不是隨便決定的,而是根據故事評估階段每個故事的估算值來排序,同時結合估算的迭代速率,即通過計算估算值來決定每次迭代多少個故事點。
5. 驗收測試
驗收測試階段主要測試發布的故事有沒有完成,書中建議是最好客戶可以參與驗收,但實際對于大多數公司來講,是不具備這個條件的。
除講述運用用戶故事貫穿整個開發流程外,本書還順便提到了技術開發時,可以使用結對編程,可大大減少返工率,并最大程度優化代碼架構。
總之,本書中描述的開發流程與互聯網從0-1的產品開發是有區別,因為是敏捷開發項目,因此流程是建立在產品需求和目標明確的前提下,沒有需求挖掘的過程,直接通過調研和規劃用戶故事的方法進行計劃迭代。
二、用戶故事幫助完善產品用戶場景
產品經理的日常主要工作就是與需求打交道,如何能夠快速準確地洞察用戶或客戶的需求,開發的功能直擊用戶痛點是很多產品經理的愿望。
平時在分析需求時,大多按照需求的三要素,用戶/角色、場景、任務路徑來梳理目標用戶的核心需求。
可產品目標用戶的真實需求,往往就誕生在真實的業務場景里,這點體驗在B端產品里尤為明顯。因此接到需求后,在進入功能策劃階段之前,梳理完善的、核心的場景就顯得至關重要。
那么如何運用用戶故事來幫我們梳理完善的場景呢?可以分三步走。
1. 結合目標用戶畫像,梳理目標用戶對應的核心使用場景
C端產品通常都有幾個典型的用戶畫像,B端產品也不例外,也可以梳理出來自家產品對應的幾個典型客戶畫像。
按照2/8定律,雖然這幾類典型的用戶/客戶可能只占全部注冊用戶的20%,但通常可以覆蓋產品中80%的功能,或者說可以貢獻產品收益的80%。
因此在梳理產品用戶的核心場景時,首先要針對此類用戶的使用場景進行調研。
2. 根據典型用戶的核心場景拆分需求
梳理完核心場景后,再將核心需求從場景中提煉出來,此時的需求應該就是最接近用戶/客戶的真實期望了。將場景用文字描述出來,可以整理成表格清單,便于后續整理。
表格清單示例
3. 需求點轉化為用戶故事
從核心場景提煉出來的需求點,還可以進一步細化為單個或多個故事點。
產品需求在一定程度上可以理解為故事,用戶在描述需求時,其實就是在描述用戶期望的使用場景,可以理解為用戶是在敘述他是在何種情境下,通過/使用何種物質,如何完成某個行為的。
但我們在提煉出需求的時候,往往有很多一句話需求,關于這個需求的細節無法很好地體現出來。甚至很多需求點不一定就是功能點,往往需求只是目的,達到目的的方法卻不止一個。
因此就需要通過用戶故事的方法來細化需求場景,便于充分拆解當前的需求,同時也有利于充實用戶場景,在需求策劃階段的決策更有依據,功能設計也更加全面。
三、結合書中理解,說說用戶故事如何編寫
1. 用戶故事的價值
確定目標用戶畫像和核心使用場景后,在策劃具體功能之前,應梳理用戶在使用該功能時的場景,然后以用戶故事的形式羅列出來。用戶故事可以用于針對某個需求功能做計劃和提示,有助于充實使用場景的細節。后續可對用戶故事清單進行優先級排序,用于決策哪些用戶故事應該優先被實現。
2. 用戶故事的特點
- 獨立的:每個故事盡可能相互獨立,相互依賴的故事可以合并成一個更大但更獨立的故事;
- 對用戶或客戶有價值的:是客戶真正關注的,可以真正解決用戶問題,滿足用戶需求的故事;
- 可估算的:用于后續產品開發進行工作量估算,必要時要拆分故事點,便于項目管控;
- 可測試的:測試人員可根據用戶故事,直接測試該故事點是否已被成功開發;
- 小的:單個用戶故事盡可能可以被量化和評估,保證每個故事盡可能小,便于窮盡故事細節。
3. 用戶故事示例
了解了用戶故事的價值和特點后,以“115”產品中的記錄功能做個示例,當我們從核心場景中提煉出一些需求點后,就需要進一步將這些需求點展開,便于后續需求規劃和原型策劃。
“記錄”功能的用戶故事:
- 用戶可在115上快速新增記錄,可直接選擇某個記錄分類進行添加;
- 用戶可自定義創建記錄分類,添加記錄后可歸類到某個分類下;
- 用戶在記錄時支持文字編輯和本地圖片上傳;
- 用戶在編輯記錄時,可添加記錄時用戶的位置信息;
- 用戶在編輯記錄時,可選擇拍攝照片上傳;
- 用戶添加的記錄支持備注標簽,并且可根據標簽查找記錄;
- 用戶可以將記錄的文本內容進行復制、粘貼;
- 用戶可選擇部分文本記錄內容,快速轉為待辦項或日程;
- 用戶可將單個記錄進行重點標記或星標;
- 編輯記錄時,用戶可在文本框實時查看當前已編輯的文本字數。
本文由 @王曙 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
- 目前還沒評論,等你發揮!