產品修鍊課4：產品經理和用戶故事user story
來自專欄產品經理的修鍊課
2 人贊了文章
用user story來代替prd，不僅清晰直觀，還能提升團隊的溝通效率；玉米大人分享一些寫故事和切故事的方法及注意事項。
我跟用戶故事的淵源
記得13年初有參加過敏捷諮詢師Daniel Teng一個工作坊，導師給我們布置的任務就是每組從自己日常生活的痛點出發，自由發散的去想一個創意點；之後團隊成員自己分角色扮演不同的用戶類型，上去講故事；然後從故事裡抽離出產品需求，根據需求在卡片上畫低保真的原型；每個團隊依次把原型卡片貼在白板上，按用戶體驗流程去講；最後大家投票評選出公認的價值點高的產品。
當時只覺得整個過程很有趣，並沒有真正放在心上。我真正開始寫用戶故事，是在去年使用快速迭代的開發方式後，每次完成幾個獨立的用戶故事，快速上線給用戶驗證，及時發現問題，快速調整。使用下來不僅不用寫長長的prd文檔了，團隊溝通效率更高了，用戶和公司高層都能更快的看到我們的產品的更新迭代。
論講故事的重要性
- 什麼是用戶故事？
用戶故事（user story）是從敏捷開發scrum中提出來的。是從用戶的角度來描述用戶渴望得到的功能，它是一個獨立完整的、可直接上線交付的、有一定業務價值的最小粒度的產品。
舉個微信的栗子：
微信1.0上線了樓層式的單人會話，用戶可以在手機上給好友發送文字和照片，以實現在手機端即時免費聊天的目的。1.2版本上線了多人會話，用戶可以在手機上發起一個群聊，並邀請相關好友入群，以實現在手機上展開小群組的討論的目的。這2種會話方式 是針對同類用戶的不同場景，每個故事都是相對獨立的，又給用戶完整的體驗，當然業務價值也是顯而易見的。
- 用戶故事的價值體現：
告別prd，通過講故事來提升團隊效率
早些年我們寫需求文檔，前面幾頁都是標準的模板，關於項目背景、目標、風險等的描述。但現實中開發要麼不看文檔，要麼打開導航，直接跳著找跟自己相關的，漂一眼界面原型圖和大概流程，就開幹了；而且在需求評審會上，把這10p+的prd文檔講完，沒個2小時真搞不定。
上圖是我們之前寫的prd模板↑
我們寫prd的目的是什麼？告知團隊成員我這個需求的背景或者問題是什麼、用戶群體有哪些、要實現的目標是什麼，解決方案是什麼；這些都可以通過一個個短小精悍的用戶故事來闡述。
故事+意義=品牌，通過故事來觸達人心
不但產品需求可以通過講故事來簡化，後續的營銷也離不開故事。記得17年底的時候，順豐官網的大banner是個微視頻，一個老父親小心翼翼的把戶口本遞給順豐小哥，小哥雙手接過並微微點頭；畫面一轉，看到一對新人滿臉笑容的拿著戶口本和結婚證從民政局出來。然後配合順豐的slogan「承諾，為每一份託付」。
怎麼寫故事
- 用戶故事的顆粒度
敏捷中有提到epic，即史詩級的故事，然後才是user story，其實故事粒度還可以更大，大到為什麼做這個產品。在梳理產品需求的時候可以由粗到細，先列出粗顆粒的epic，然後切分成小顆粒的user story，用戶故事一定要切分的夠細，最後是進行分組和排序，產出用戶故事地圖，也就是我們常見的迭代版本清單。
- 寫故事四字法：起承轉合：
其實我們小時候寫作文也是用的這個方法，先介紹故事的主人翁及故事背景，然後在這樣的背景下，主人翁想要什麼或者想達到什麼樣的目的【前面都是起】，但是現實中遇到了哪些問題或困難導致很難實現目的【承】，後來他做了什麼事或者哪些努力【轉】 ，最終歷盡千辛萬苦實現了目標【合】。
接下來我們結合產品經理梳理需求的思路來提煉重點：
主人翁---user（角色）
故事背景---scene（場景）
想要什麼或者想達到什麼樣的目的---Want（目的）
遇到了哪些問題---defect（問題/不爽）
他做了什麼事或者哪些努力---Action（行動）
舉個栗子：
小c的工作需要經常出差，有次忘記定酒店了，當時已經很晚了，跑了一天也很累，晚上還要發工作彙報郵件，小c想快速的找個最近的酒店安頓下來。當他在手機上找酒店的時候，還要點開詳情頁，去看看當晚還有沒有空房，有些有空房的價格又高出很多，最後還要到酒店設施里確認下有沒有wifi。於是小c就背著電腦包在馬路邊盯著手機找了好久，找到酒店後我還要把酒店地址貼到百度地圖裡，最終跟著導航找到了酒店。
- 用戶故事的標準模板：
As a , I want to , so that .
作為一個xxx（某類用戶），我要xxx（做一件事），從而達到xxx（某一結果或動機）。
套用這個模板的示例：作為出差在外卻沒有預定酒店的人，我要找到我現所在地點步行距離內的經濟酒店，從而能夠睡覺休息、上網處理郵件。
這裡有提到角色，其實角色就是交互設計里經常提到的用戶畫像persona，後面我會單獨一章來分享我對persona的理解。不過在之前的文章《產品設計中數據觀點和用戶畫像--課程內容整理》中，有一小部分是對persona的描述，感興趣的可以先看下~
- 總結：
個人覺得四字法更適合粗顆粒的史詩級故事，而故事模板更適合細粒度的用戶故事。或者說四字法更適合需求梳理初期，可以直觀的看到用戶使用場景和痛點，而痛點就是我們要解決的問題，而故事模板則更適合技術團隊溝通。
如何切故事
- 為什麼要切分故事？
其實user story就是被切分後的epic。在實際項目中，越是高優先順序的故事，顆粒度要越小，描述越具體，這樣做的好處是：小的故事大家在理解上不容易產生偏差，而且更容易完成，故事越大不確定性就越大（比如外部依賴，前置關聯，臨時需求插入，團隊人員請假等）。
- 如何切故事？
按工作流程：比如請假流程，可以把簡單的首尾故事先切分出來，創建請假單，審批請假單，然後中間各個環節的審批流轉作為獨立的故事。
按功能操作：比如一般的後台報表都有增刪改查的功能，可以按增刪改查來切分。
按功能類型：比如接在線支付，微信、支付寶、銀聯可以拆分為3個故事來完成，當然每個下面還可以再切。
按內容範圍：比如酒店詳情頁，先支持查看酒店基本信息和價格，再支持查看周邊交通，地圖位置等。
按用戶需求層次：把性能和穩定性方面的考慮拆分成獨立的新故事；
（說明：這些切分方法部分來自於Richard Lawrence，想了解更多切分方法的可以自己去看下）。
注意事項
- 從用戶是視角來講故事；
- 把握好用戶故事的粒度：
自己在前期梳理故事，或者給高層講故事時，故事粒度可以粗一些；但是給技術團隊講故事，粒度要足夠細，足夠具體。
- 故事並不是越多越好：
一般一個迭代5-10個故事，維護2-3個迭代周期的故事就可以了，讓那些價值不高的故事從你的待辦清單里消失吧~（數據僅供參考，具體還要看迭代周期的長短和團隊資源的配比，我這個是5天一個周期，2個開發人員的工作量，當然我的故事拆的非常小）。
- 要有驗收條件：
即符合什麼要求的故事才算可交付的，也是給測試人員一個測試依據。
寫在最後
關於用戶故事我也是最近1年才開始使用，踩的坑還不夠多，寫這篇文章前我又把相關的書和資料都看了一遍，修修改改的寫了1整天，希望有經驗的小夥伴可以一起交流探討~~~
關注公眾號【零點零壹】 ，和玉米大人一起 每天進步一點點；
http://weixin.qq.com/r/eS6BmYbE7tuRrcL693tr (二維碼自動識別)
推薦閱讀：