從最初的瀑布模式開始，需求就貫穿了產(chǎn)品與項目的始終，是一個產(chǎn)品搭建的重要信息來源，無論是有明確用戶需求的企業(yè)級產(chǎn)品也好，還是沒有明確用戶需求的互聯(lián)網(wǎng)app產(chǎn)品也罷，需求調(diào)研都是產(chǎn)品閉環(huán)的源頭，調(diào)研的優(yōu)劣直接關(guān)系到產(chǎn)品的成敗。

記得最初去一家電信公司做項目，他們的需求都不是自己提，而是集團幫著提，有一套厚厚的集團規(guī)范，讀起來非常的拗口、費解。就和方言一樣，可能A和B讀完，會有各自不同的理解，總之那時候的產(chǎn)品說不好做也不好做，因為需求難理解，客戶也不知道自己為什么要用系統(tǒng)，也不知道要做什么；然而說好做也好做，因為客戶也不需要真正使用系統(tǒng)，有時候就是裝裝樣子，糊弄一下集團的規(guī)范。

后來就有了敏捷（中間跨度還是很大的，只不過一筆帶過），敏捷以水的柔性，充分化解了之前瀑布模式死板和教條的化的項目流程，但是很多企業(yè)以為敏捷就是解決項目與產(chǎn)品問題的萬能良藥，為了敏捷而敏捷，只不過以前寫需求文檔，現(xiàn)在改寫用戶故事，換湯不換藥，把敏捷當成菩薩一下，以為供一供就能保佑項目順利上線……。

答案當然是：NO

敏捷的用戶故事，絕對不是這么LOW的，一個好的用戶故事么，不是套用一個模版，把用戶說的寫上去就算完事了，前期還是需要大量的準備工作的，后面也得加入產(chǎn)品經(jīng)歷自己的分析和評判。

一個用戶故事，必須來自用戶，但是可能又不是客戶自己說出來的，有點費解，舉個例子來說：

一個家裝客戶，可能經(jīng)常會跟設(shè)計師說，我家客廳比較暗，我看別人家又一個燈特別好看，我也想裝一款，這個需求看似很合理，但是答應(yīng)客戶需求之前還是得自己質(zhì)疑一下這個需求。

客戶真的是需要燈么？裝一個燈在客廳就能解決問題么？會不會有其他問題，比如容易磕頭？安全問題？

在通過與客戶深入溝通后，發(fā)現(xiàn)問題的本質(zhì)，客戶只是覺得那里太暗了，采光不是很好，那這個問題就從選擇燈的類型變成了選擇何種光源來解決客廳暗的問題，可能解決的方式就會有很大差別。

所以一個需求調(diào)研是否清楚，直接影響后面產(chǎn)品的設(shè)計的思路，影響產(chǎn)品的最終形態(tài)。

那用戶故事究竟該如何收集呢？

1、一定要傾聽，打開用戶的話匣子讓他噴，引導他說（其實就是多問問為什么，你期望什么之類）；不要強加干涉、不要喧賓奪主的自己說太多

2、一定要把握好調(diào)研的節(jié)奏，明確目標，不要讓調(diào)研變成你給客戶的推銷或培訓，更不要讓調(diào)研變成客戶的抱怨，一定要產(chǎn)生有價值的信息。

3、一定要明確場景，不同的場景可能用戶的需求是不一樣的，可能會演變成多個用戶故事

4、一定要問用戶、客戶兩種角色的需求，用戶是最終使用的人，而客戶是付錢的人，兩種人會有兩種截然不同的需求（但多數(shù)情況是只問客戶的，畢竟人家給錢了，沒給錢的，嘿嘿，那就等著接受我們復雜的系統(tǒng)和無休止的培訓吧）

5、一定要多問客戶或用戶期望的目標是什么，描述他們希望達到的目標的場景。

只有收集上述信息后，經(jīng)過整理和分類，才能形成最終的用戶故事，變成產(chǎn)品經(jīng)理熟知的用戶故事：

xxxx用戶在xxxxxx場景下，通過xxxxx操作，實現(xiàn)xxxxxx，目的是xxxxxxx

再引申一下，結(jié)合之前講的思維方式培訓，其實需求調(diào)研就是在印證你的思路是否正確，是否可以和用戶同頻；在目標明確，目的相同的基礎(chǔ)上，反向推演是否可以把產(chǎn)品和業(yè)務(wù)邏輯，套用進客戶的需求中，滿足客戶基礎(chǔ)需求，甚者給他們一些驚喜，如果是，那么你的產(chǎn)品至少是能拿的出手了。