“接需求”是產(chǎn)品經(jīng)理（下文簡稱“PM”）工作中必不可少的一環(huán)，文章中筆者會結(jié)合自己的親身經(jīng)歷，講述做好需求分析的幾個關(guān)鍵點，希望能給剛?cè)胄泻痛蛩闳胄械呐笥褌円稽c兒啟發(fā)。需求分析在產(chǎn)品生命周期中占有重要的地位，決定著產(chǎn)品做出后被用戶接納的程度。通過對接觸過的PM進行觀察，我發(fā)現(xiàn)大部分人進行需求分析時做的事情大同小異。故總結(jié)出幾個關(guān)鍵點，形成一個可以應(yīng)對大多數(shù)需求的操作方法。 說明：由于筆者一直從事ToB產(chǎn)品的工作，故本文所述的方法只針對此類產(chǎn)品，不保證對ToC產(chǎn)品適用。
一、需求從哪里來的
需求是某些用戶在特定場景下為了得到某種服務(wù)或功能而提出的訴求或建議，它是產(chǎn)品的組成部分，也是產(chǎn)品最終要達到的目的。它可以是老板的一句話，可以是用戶使用過程中的一聲抱怨，也可以是對一堆數(shù)據(jù)分析后得出的結(jié)論。 根據(jù)筆者的觀察，需求的來源有以下幾種：1. 老板
對于老板提出的需求，一定要重視，并非因為需求方是老板，而是因為它同時包含著機會和陷阱，而且很難拒絕。 （1）機會- 通過老板的需求，了解老板的思路，借此一窺公司戰(zhàn)略發(fā)展方向；
- 將自己對產(chǎn)品的理解和老板的對照，找出其中的區(qū)別并思考原因；
- 和老板交流下自己的產(chǎn)品思路，發(fā)現(xiàn)自己和老板的差距；
- 把老板交代的事做好了，得到老板的賞識（這個大家都懂）。
- 并非所有的老板都了解產(chǎn)品開發(fā)流程，了解業(yè)務(wù)發(fā)展，會出現(xiàn)瞎指揮的情況；
- 某些需求會打亂團隊的產(chǎn)品規(guī)劃及開發(fā)節(jié)奏，PM處理不好將會里外不是人。
2. 用戶（內(nèi)部同事）
筆者面對的用戶是公司內(nèi)部的同事，大部分是使用系統(tǒng)的部門同事，小部分是其他的PM。 從部門同事的需求中看出，他們在意的是系統(tǒng)能否滿足他們的某項要求，通常會在提出需求的同時給出他們的解決方案。但是并不意味著就是真實需求，一個很著名的案例是想要快馬但是福特提供了汽車（不知道的朋友請自行查詢）。因此，PM在溝通中需要引導(dǎo)他們表述出自己的真實需求。 負責其他系統(tǒng)（業(yè)務(wù)線）的PM也會提出需求，來滿足一些需要跨系統(tǒng)實現(xiàn)的功能。這種情況的溝通會比較順暢，因為彼此對系統(tǒng)、開發(fā)流程、技術(shù)邊界都比較了解。3. 自我驅(qū)動
這類需求通常會基于以下三種原因產(chǎn)生：- 通過數(shù)據(jù)分析得出的。
- PM在使用系統(tǒng)時發(fā)現(xiàn)的問題（通常用戶無感知）。例如：筆者做風控系統(tǒng)時發(fā)現(xiàn)的問題，需要對推送的進件增加控制開關(guān)。作用是在風控模型調(diào)整或新功能上線后，控制推送進件的數(shù)量，待驗證無問題后再打開，允許大量進件。
- 根據(jù)產(chǎn)品感提出的。產(chǎn)品感是指基于PM對產(chǎn)品的理解，對市場的分析，提出了一些對于產(chǎn)品未來發(fā)展有益的需求。
二、對需求提出方式做規(guī)定是有必要的
每個需求的提出者，通常會站在自己的角度提需求，或基于交互，或基于效率，或基于KPI等。這對PM把握需求的重要程度，了解需求內(nèi)容的準確性增加了難度。例如：筆者曾經(jīng)對接過和我不在一個城市工作的業(yè)務(wù)部門。對接過程中，出現(xiàn)了同一個部門多人同時提需求且優(yōu)先級不明確，需求上線后使用者（非需求提出者）反饋需求實用性不高，或者需求上線后很多等待使用的人不知道等問題。筆者通常會分三步進行操作：
1. 確定接口人并明確其職責
接口人：和需求方部門Leader溝通，讓他指定一名接口人，所有人的需求都在接口人處匯總，再提給PM。 職責：- 收集部門同事的需求；
- 過濾掉不合理和不必要的需求；
- 給出需求的優(yōu)先級；
- 將需求提交給PM；
- 跟進需求進度；
2. 確定需求提出方式
郵件提出，確保周知所有相關(guān)人，并能留存記錄。3. 部門Leader進行審批
必須由部門Leader審批，確保他了解并認可需求內(nèi)容和優(yōu)先級。三、需求收集方式
一句話概括，就是多提問、多溝通，了解業(yè)務(wù)和實際使用場景。1. 5W1H分析法
很多需求提出者不了解系統(tǒng)，他們只關(guān)心當前問題是否能夠解決，PM必須詳細了解需求的來龍去脈，以便能提出解決方案。在此推薦5W1H分析法，用來收集需求內(nèi)容。
（1）What（描述）
需求是什么？
（2）Why（原因）
為什么會有這樣的需求？之前的替代方案是什么？
（3）Who（使用者）
需求的使用者是誰，或者說是哪個部門？
（4）Where（場景）
需求的使用場景是什么？
（5）When（時機）
需求什么時候會被用到？被用到的頻率是怎樣的？
（6）How（檢驗）
如何確認需求已經(jīng)被滿足？
上述問題要求需求方描述清楚，可通過郵件，也可通過面談。需求的收集方法可按照自己的習慣選擇，重點在于對需求信息的收集。
2. 和需求方的溝通頻次
負責ToB產(chǎn)品的PM必須了解業(yè)務(wù)，筆者曾經(jīng)負責過財務(wù)系統(tǒng)的設(shè)計，由于不了解需求方對于結(jié)算、對賬、提現(xiàn)等操作使用場景的要求（需求方也不了解），導(dǎo)致設(shè)計出現(xiàn)問題，需要進行二次開發(fā)。 要想深入了解業(yè)務(wù)，就需要和需求方保持溝通。筆者認為，在接到需求后，至少應(yīng)該有三次溝通。- 第一次是在接到需求后。要遵循5W1H分析法，圍繞其中的問題進行溝通，收集需求詳細信息。
- 第二次是在收集信息并對需求進行分析后。PM會結(jié)合自己對系統(tǒng)的了解，挖掘出一些細節(jié)問題，其中有一些需要和需求方確認。這期間可能會有多次溝通。
- 第三次是在PRD完成后。要將文檔內(nèi)容講給需求方聽，在評審前最后一次確認自己是否準確理解需求。至于需求背景這類問題，必須在評審會前了解清楚，以便在會上講給所有人。
四、需求的分析與整理
1. 需求分析的步驟
判斷需求的真?zhèn)唯C>分析需求的業(yè)務(wù)價值–>評估需求的可行性–>給出需求的優(yōu)先級。 筆者將以自己的經(jīng)歷為例，說明如何進行這四步操作： （1）判斷需求的真?zhèn)?/strong> 該需求的5W1H分別為：- What：需求方是財務(wù)部門，需求內(nèi)容是在財務(wù)系統(tǒng)中新增列表，用來展示某項費用的明細，且該列表可以下載。
- Why：之前的替代方案是從系統(tǒng)中另一個列表下載，由于并不是專門展示此類數(shù)據(jù)（數(shù)據(jù)量較大），所以需要人為進行篩選和計算。篩選計算時間不長，筆者親測約為15分鐘。
- Who：使用者是財務(wù)部門的一名同事（只有一人），系統(tǒng)的其他使用者不會用到該列表。
- Where：使用場景是每月與合作方對賬時，需要下載該列表，然后在excel中對某幾項金額進行計算。
- When：每個月月初使用，統(tǒng)計上一個月各資金類型的交易量，使用頻率一個月一次。
- How：列表中能夠按時提供準確、完整的數(shù)據(jù)，即滿足需求。
- 重要性：指需求是否符合公司戰(zhàn)略發(fā)展、是否是產(chǎn)品線上的戰(zhàn)略項目、是否和公司的收益掛鉤、是否滿足產(chǎn)品的基礎(chǔ)服務(wù)等等?？傊?，在時間上不具有緊迫性，但是會對未來的發(fā)展產(chǎn)生重大影響。
- 緊急性：指需求是否必須立即解決，如不解決會持續(xù)產(chǎn)生或?qū)⒁a(chǎn)生不良影響。這類需求不一定很重要，但是在時間上有緊迫性。
KANO模型：
- 必備因素：在業(yè)務(wù)流程中必須具備的功能，用以保證流程能正常進行。功能缺失時，使用者會發(fā)現(xiàn)流程不能走通。故這類需求需要優(yōu)先考慮。例如：風控系統(tǒng)中跑反欺詐模型時，如果調(diào)用失敗后沒有重啟流程這個功能，就會存在調(diào)用失敗的進件卡在反欺詐模型環(huán)節(jié)，造成流程中斷。
- 期望因素：這類需求通常能節(jié)省使用者的時間，提升效率。存在的目的是為了讓系統(tǒng)操作起來更流暢。優(yōu)先級一般沒有必備因素高。例如：財務(wù)系統(tǒng)每月做報表時，如果系統(tǒng)能夠?qū)⑿枰獜亩嗵幉檎也⒂嬎愕臄?shù)據(jù)，統(tǒng)一到一處并展示計算后的結(jié)果，那樣能提高使用效率。
- 魅力因素：通常是一些使用者沒有想到的功能，能大幅提升使用者效率、優(yōu)化體驗和解決使用者線下難以解決的問題的需求。這類需求在ToB產(chǎn)品中不常見，通常是必備因素和期望因素占據(jù)主導(dǎo)地位。
2. 需求整理
需求的收集與整理需要用到需求池。需求池沒有固定的模板，建立的目的是為了幫助PM進行需求的評估和管理，模板內(nèi)容依照個人習慣建立即可。 需求池中的需求由PM錄入，記錄不需要像收集需求及分析時那樣細致，重點在于對需求的狀態(tài)、優(yōu)先級、排期進行記錄。 以下是我的需求池模板：
以上是基于筆者對需求分析的想法，可能存在一定的局限性，僅供參考，歡迎大家多交流學習！
作者：打醬油的熊，公眾號（打醬油的白熊）
愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導(dǎo)、進階學習的集聚平臺；
想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）
【轉(zhuǎn)載說明】 若上述素材出現(xiàn)侵權(quán)，請及時聯(lián)系我們刪除及進行處理：[email protected]
