做任何產品，不能直接了解需求，這樣容易陷入細節，而偏離整體項目。當你的目標不明確時，你需要了解清楚現狀：問題和機會是什麼？有什麼影響？再確定解決方案，有效進行需求分析。
「為什麼這次又延期上線？！」
「因為需求方又變更需求啊！」
「那具體什麼時間可以準確上線！」
「大概…」
「……」
看著業務方一臉憤慨，產品經理攤手表示無奈。
這個場景相信不少產品經理有遇見過。
如果是小需求變更倒還好，涉及核心流程的變更，相信程序猿已經磨刀霍霍向豬羊…
產品延期上線的大部分原因多半是需求變更頻繁，既定上線日期一拖再拖。那我們要如何去解決這個問題呢？
需求變更頻繁，大部分錯不在需求方，而是在於我們產品經理對需求分析與挖掘不夠全面與深入，因為需求方往往對自己的需求是模糊且想一是一。
那如何做有效的需求分析呢？以企業組織系統舉例，後續我用幾張篇幅給大家詳細說明。
做任何產品，不能從直接了解需求，這樣容易陷入細節，而偏離整體項目。
首先，我們要了解產品的價值需求這一條線，次之才是詳細需求線。
價值需求主線分為三大方面，目標與願景分析、干係人識別、干係人分析。
詳細需求主線分為系統分解線、功能線、數據線、質量線、其它方面。下面講述目標與分析的六個點。
一、需求=預期-現狀
我們在做產品調研時，大致會遇到三種情況。相關系統涉及的部門的同事有的表現積極、無所謂、不搭理的情況時有發生，其實這些就是他們現狀有所不同。
當他們在使用系統經常遇到讓他們無法理解或頭疼繁複的操作時，他們會對你的需求調研發現出熱情，恨不得把訴求一股腦拋給你。
反之，系統用著還行，這時你提出迭代優化，這種打破他們習慣的做法造成的不安全，他們會比較抵制你的調研。這時不要慌，我們需要去了解他們的工作流程與操作體驗，找出更為快捷高效率的思路，提高他們的預期，創造新的需求機會，這樣他們才會配合你的工作。
因此，我們進行需求分析時，首先要識別這是機會還是問題。兩種情況下了解需求的套路有所不一。
二、問題場景
出現問題場景，它有外部和內部兩種觸因。
外部觸因下常見的有三種情況。
第一種情況：主導看到別人的產品，察覺自身差距。需求分析思路：讓對方分享觀察後的收穫。一般情況，需求方有較為明確的思路，進行需求獲取較為輕鬆一些。
第二種情況：競品的動向，想模仿。需求分析思路：做競品分析。常見需求方沒明確的思路，只是看好的就想抄。此時產品人員需謹慎分析。
第三種情況：新技術的趨勢。需求分析思路：讓對方分享對所謂新技術的理解，了解背後的需求，以防有差。
內部觸因下，內部員工已經明確意識到現狀與預期的差距，但是無法詳細闡述。這時比較考驗產品人員的訪談技巧，我們的大致思路是還原表象-分享原因-共商決策。此處詳細的知識可以查看需求獲取的相關書籍
三、機會場景
對機會場景的分解可以從三個角度去分析。
第一、新業務。追標杆、賽同行、借鑑別的行業
第二、新技術。關注新技術的應用趨勢，尋找靈感。關注客戶的業務痛點以及系統缺陷
第三、新人群。假如一個產品的用戶年齡段雖然是固定的，但是若干年過去後，這個年齡段的人由於出身的社會背景有所不同，其個性和需求會有所不同。像壽命較長、垂直化產品更是要關注一點。
四、準確定義問題/機會
面對客戶，最核心一點是，先講場景再談數據。如果一開始，把問題用專業的語言進行描述，對方要麼一臉懵逼要麼理解偏差，影響溝通效果。
我們該如何描述一個問題？
業務態。每個產品經理剛入門時，對需求方講解系統時，直入主題講解系統功能與架構，對方多半是一臉懵逼狀。我們應該從對方關心的業務層次來講系統的作用。比如當需求方是企業管理層，我們應該從「問題、機會、成本、效益」這四方面去講述我們的系統，不要深陷技術實現的細節。客觀性。需求方給我們描述訴求時，往往模糊不準確。而我們產品人在了解完需求後，一定要準確、客觀地描述好；匹配性。項目的願景和目標往往是高層讀者，我們關注點應從經營層面、管理藐視、業務模式依次去描述問題
五、分析影響
明確指明問題影響到了誰，可以指明部門崗位分析帶來的影響與後果（注意讀者的層次）推理合理、層次清晰
六、分析問題和確定解決方案
分析問題。魚骨法、問題現狀樹法、問題現狀法、系統思考法等，涉及的技巧可以看相關書籍宏觀說明，強調具體策略，業務化語言描述。用「措施+效果」的結構一句話提煉目標場景本章節知識主要是適用於從0開始或者目標不明確的項目，不適用於內部有明確的方向和框架的項目。
本文由 @PM達雲霄 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。