如何才能有效的引導需求方把需求敘述明白?

01-09

做PM不僅需要自己把需求細節理清楚，很多時候還要想辦法引導需求發起人把自己的需求敘述清楚，很累，誰叫很多時候天朝PM只是產品設計師而不是需求的原始發起人？
那麼問題來了，如何才能有效的引導需求方把需求敘述明白，而不是落入假大空的套路？經常遇到「基本的要求就是這樣，具體怎麼做就不多講了，這個是XXX應該考慮的問題」，然後等設計完成需求方又是各種這裡那裡不夠高大上的挑剔，淪為乙方實在有夠苦逼啊。

謝邀

1. 你要做到能夠有效的引導需求，首先就是你要是這個業務領域的業務專家，只有這樣才可能盡量多提偏封閉式的問題而非開放式的問題。

2. 引導需求來說任何時候的重點都在於兩個，一個是業務場景，一個是原型講解。

謝邀。

做過兩次乙方，其中一次甲方是蛋疼的政府部門，說說處理經驗吧。

政府的需求拿簡直是相當模糊，他們自己其實都描述不大清楚。負責對接的A和我們談需求，做出東西了A檢查要讓修改，A驗收了要交給領導B檢查，領導B給修改意見，我們修改了領導B驗收後又給領導C檢查給修改意見（領導必有修改意見，好像不給點意見會顯得自己沒文化似的）……

這簡直就是折騰無極限的活，後來我們是這樣處理這個事情的：

用腦圖和對接人梳理功能點，梳理到很細，然後把腦圖放進合同
簽好合同過後，負責這個項目的產品直接蹲在甲方那出DEMO，讓對方確認簽字蓋章
設計師按照DEMO出設計圖，對方確認了的必須給我們蓋章
工程師也按照DEMO開發，開發中途不和甲方溝通

按照這個流程把項目搞定了交給甲方驗收的時候，甲方必然會有一大堆修改需求（特別是領導肯定有意見），因為我們合同里把功能點列得很細，又有對方蓋章的DEMO和設計圖，所以不費什麼事的小需求我們給落實，難搞的需求要對方加錢才給開發，我們占理對方硬氣不起來。

基本甲方或者用戶提的需求都起於使用場景，當對方無法說清需求的時候，你就問產生需求的場景，在場景中遇到的問題，解決問題後預想的效果。如果這個也說不清楚，那就在了解到產生需求的場景後，去該場景親身體驗，反覆體驗。

如果連為啥會有這需求（產生需求的場景）都說不清。。。那還做個P啊，做了有啥用。

大部分時候，用戶不知他們要什麼，直到你直觀地呈現。

----------------------史蒂芬·保羅·喬布斯

遇到這樣的問題，其實往往是有潛台詞的：

首先誰是用戶沒有搞清楚，很多產品比較複雜，比如說有買單的人和使用的人不一致，滿足用戶需求，到底是滿足哪個「用戶」的需求？所以第一步是明確誰是用戶？

我的觀點：一個產品設計永遠只為一類用戶！如果用戶沒有搞清楚，需求永遠是混亂的！

所以這個問題第一步是定義清楚用戶。定義清楚用戶才能選擇用戶進入Primary Market Research階段。

接下來，我想說的是：需求方的描述永遠是呵呵。產品經理不是記錄員。不管你用哪種Research方法，無論是客戶拜訪、焦點小組、用戶需求研究、Competitive Intelligence和調查，我們核心調查的不是用戶說我要什麼，用戶知道要什麼，還要產品經理幹嘛？我們核心調查的是用戶環境、用戶在這個環境中的行為，然後發現她/他的痛點，梳理出他們的真正需求。

建議樓主可以系統學習一下新產品開發的流程和方法，推薦國際新產品開發與管理協會的NPDP認證，這是一個國際上認可度很高的產品開發認證：http://www.peixun.pro/

這是一個好問題。

我司（聯想）是華為的乙方，由於身處服務行業，所以也時常遇到題主的困惑。

甲方需求時而膠著時而隱晦，常常讓我們束手無策。無數個夜深人靜的深夜，我扣問自己，為什麼就不能好好引導甲方將需求言而簡之，簡而明之？

實不相瞞，入職初期，由於一直無法很好的看待甲方乙方這層關係，吃過很多人情虧（因為事情沒做錯，只是方法欠考量）。

但虧，讓我成長。

事後我慢慢發現，如何引導其實不難，說白兩點：

1、你想要什麼結果

（我不要聽你講過程，我不聽我不聽）

2、你想要我做什麼

（我不需你教我咋做，我會我會我會）

可話又說回來，只要自己足夠專業，甲方提筆四字：媽（馬）的巴（八）子。

你都能席地作一幅，《八駿圖》。

需求工作的核心是挖掘，而不是記錄。記錄是被動的，挖掘是主動的，當你發現你在做需求時一直很被動，那說明你對用戶的場景和行為思考的不夠，老生常談的4W1H確實是前人做的最精闢的總結了。共勉！

最完美的情況是你本身既是一個業務專家同時又是一個技術專家，那基本就不用引導了，perfect！

次完美的情況是訪談對象有豐富的被訪談的經驗，甚至他都知道用例是怎麼回事了，excited！

再下來就是傳統的問卷，訪談，熟悉業務，查看老系統等等這些手段，不過我覺得的，特別是在企業開發中，牢記一點。業務天生就在那裡的，不是因為你做了一個IT系統，就會產生什麼新業務。老的業務模式做不到，新的IT系統一樣做不到。

我去做需求，遇見搞不清的問題，我一般問他們以下問題：假如現在沒有IT系統，你打算怎麼做這個業務？假如現在停電了，老總要看報表，你怎麼給他出個報表？假如這個系統老總要求明天就上線，我只能完成A，B，C這三個功能中的一個，你選擇哪個？

一般迭代幾周問下來就差不多了。

首先要把零散的原始需求匯總，這個階段可以用腦圖整理，然後經過初步的理解分析，將大致的業務流程勾勒出來，這時候與客戶最好是面對面溝通，引導客戶來描述業務流程，這裡需要注意的就是，不要把自己理解的流程當作正確的，否則可能把客戶帶進溝里。這個過程中還要將流程中的5w1h 明確

接下來是重點，推薦使用UML來做具體的梳理，具體方法可以去搜索下，這個階段應該會產生很多問題，全部記錄後，再次和客戶溝通，注意提問時，要重點在how ，舉個例子，比如流程某個環節不通，AC兩人中間缺了一個角色，這時候不要問「是不是這裡要加個B」而是要問「A怎麼來把這個事情進行或推動到C」。這時候你可能會聽到很多種方法來完成A到C，其中包括增加一個B，如果你直接問是不是加個B，那麼客戶的回答一定是「對」，其他的方法甚至隱藏的需求就可能被疏漏了。

這個問題讓我笑死了，感覺真的好悲催好心酸

需求規格說明書SOW