筆者從自身經驗出發，就什麼是用戶故事、如何收集用戶故事兩個問題進行了分析討論，一起來看看吧。
從最初的瀑布模式開始，需求就貫穿了產品與項目的始終，是一個產品搭建的重要信息來源，無論是有明確用戶需求的企業級產品也好，還是沒有明確用戶需求的網際網路app產品也罷，需求調研都是產品閉環的源頭，調研的優劣直接關係到產品的成敗。
記得最初去一家電信公司做項目，他們的需求都不是自己提，而是集團幫著提，有一套厚厚的集團規範，讀起來非常的拗口、費解。
就和方言一樣，可能A和B讀完，會有各自不同的理解，總之那時候的產品說不好做也不好做，因為需求難理解，客戶也不知道自己為什麼要用系統，也不知道要做什麼；
然而說好做也好做，因為客戶也不需要真正使用系統，有時候就是裝裝樣子，糊弄一下集團的規範。
後來就有了敏捷（中間跨度還是很大的，只不過一筆帶過），敏捷以水的柔性，充分化解了之前瀑布模式死板和教條的化的項目流程。
但是很多企業以為敏捷就是解決項目與產品問題的萬能良藥，為了敏捷而敏捷，只不過以前寫需求文檔，現在改寫用戶故事，換湯不換藥，把敏捷當成菩薩一下，以為供一供就能保佑項目順利上線……
答案當然是：NO！
敏捷的用戶故事，絕對不是這麼LOW的，一個好的用戶故事麼，不是套用一個模版，把用戶說的寫上去就算完事了，前期還是需要大量的準備工作的，後面也得加入產品經歷自己的分析和評判。
需求調研
一個用戶故事，必須來自用戶，但是可能又不是客戶自己說出來的，有點費解，舉個例子來說：一個家裝客戶，可能經常會跟設計師說，我家客廳比較暗，我看別人家又一個燈特別好看，我也想裝一款，這個需求看似很合理，但是答應客戶需求之前還是得自己質疑一下這個需求。
客戶真的是需要燈麼？裝一個燈在客廳就能解決問題麼？會不會有其他問題，比如容易磕頭？安全問題？
在通過與客戶深入溝通後，發現問題的本質，客戶只是覺得那裡太暗了，採光不是很好，那這個問題就從選擇燈的類型變成了選擇何種光源來解決客廳暗的問題，可能解決的方式就會有很大差別。
所以一個需求調研是否清楚，直接影響後面產品的設計的思路，影響產品的最終形態。
如何收集？
那用戶故事究竟該如何收集呢？
一定要傾聽，打開用戶的話匣子讓他噴，引導他說（其實就是多問問為什麼，你期望什麼之類）；不要強加幹涉、不要喧賓奪主的自己說太多；一定要把握好調研的節奏，明確目標，不要讓調研變成你給客戶的推銷或培訓，更不要讓調研變成客戶的抱怨，一定要產生有價值的信息；一定要明確場景，不同的場景可能用戶的需求是不一樣的，可能會演變成多個用戶故事；一定要問用戶、客戶兩種角色的需求，用戶是最終使用的人，而客戶是付錢的人，兩種人會有兩種截然不同的需求（但多數情況是只問客戶的，畢竟人家給錢了，沒給錢的，嘿嘿，那就等著接受我們複雜的系統和無休止的培訓吧）；一定要多問客戶或用戶期望的目標是什麼，描述他們希望達到的目標的場景。只有收集上述信息後，經過整理和分類，才能形成最終的用戶故事，變成產品經理熟知的用戶故事：xx用戶在xx場景下，通過xxx操作，實現xxx，目的是xxx。
再引申一下，結合之前講的思維方式培訓，其實需求調研就是在印證你的思路是否正確，是否可以和用戶同頻；
在目標明確，目的相同的基礎上，反向推演是否可以把產品和業務邏輯，套用進客戶的需求中，滿足客戶基礎需求，甚者給他們一些驚喜，如果是，那麼你的產品至少是能拿的出手了。
本文由 @zywudi 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於 CC0 協議