一文搞懂需求分析(超全收藏版)
作為產品經理的基本功,需求分析的技能是每個產品經理都必須要掌握的。本文系統梳理了需求分析的方法和流程,并給出了模型等參考,供各位參考。
一、什么是需求分析
需求分析是指,產品經理從用戶/業務的需求出發,通過分析,確定用戶/業務的目的和目標,明確需求或問題的最底層邏輯,將用戶/業務需求轉化為產品需求,輸出解決方案。
簡單理解就是判斷一個需求為什么做,要解決什么問題,值不值得做,要做成什么樣子,要怎么來做才能實現產品目標以及價值最大化。
在做需求分析時,我們需要透過現象看本質,理解用戶的真實目的,提出產品的解決方案。
1. 需求分析的原則
- 以用戶為中心:要以你的用戶為中心,這是最核心的,所有的需求分析都要這樣,因為你的用戶才是你產品的使用者,對于你的產品才有最真實的話語權,你的產品要實現的目的也是服務于用戶。
- 實事求是:要客觀、準確,不能過度解讀,也不能太過于主觀,是什么就是什么。
- 要有整體思維:做需求分析不能只看這一個需求,要結合關聯內容,有整體思維,很多需求是牽一發而動全身的,所以要多考慮下。
- 符合市場趨勢:尤其是商業化項目,需求是需要符合市場趨勢,遵循市場規律的,你不能逆趨勢而行,那就是無用需求。
- 技術可實現性:一定要考慮技術可實現性,在上一篇方法論我們聊過,需求不應該是天馬行空的,要基于技術能實現,這個是很基本的。
- 考慮成本:任何涉及到錢的都是大事,我們分析需求,是要考慮成本的,不能用戶給你提個需求,我們得花很多資源和時間去實現,但是價值又很低,這個就很不劃算。
- 尊重用戶:如果是定制化需求,用戶付費的,那就是另外一個思維,盡量去滿足用戶,誰會跟錢過不去。
2. 需求分析的內容有哪些
- 用戶需求:這個是說得最多的,就是你的用戶反饋的需求,可能是公司的,可能是外界收集的,比如說做用戶訪談、調查,對用戶使用的場景進行整理,從而建立從用戶角度出發的需求。
- 產品需求:定義為產品需求,就是產品本身存在的需求,由IT團隊,或者公司層面戰略規劃主動發起的,這個反映了組織機構對系統、產品高層次的目標要求。
- 功能需求:其實前面兩個也算是功能需求,這個就是系統必須完成的那些事,即為了向它的用戶提供有用的功能,產品必須執行的動作,比如說權限管理,系統設置等。
- 非功能需求:比如性能、響應時間、可靠性、容錯性、擴展性等,這個屬于功能之外的需求。
- 界面需求:這個就是比較細的內容了,界面的設計,色彩搭配,布局等,或者說用戶視覺需求。
- 數據需求:比如說數據獲取,數據存儲,數據分析等,尤其是在AI時代,數據需求會變得更多,更加復雜,同時也會更加智能化。
- 兼容性需求:兼容性需求包括軟件與操作系統、硬件平臺、其他軟件等的兼容性問題。需要確保軟件能夠在目標環境中正常運行,并且不會與其他軟件發生沖突。
- 安全性需求:這些需求關注的是軟件在長時間運行或面臨各種異常情況時,能否保持穩定、可用和安全。需要考慮到各種可能的故障和攻擊場景,并制定相應的應對策略。
- 性能需求:性能需求關注的是軟件在運行時需要滿足的各項性能指標,如響應時間、吞吐量、并發用戶數等。這些指標直接影響用戶的使用體驗,因此需要進行詳細的評估和定義。
二、需求分析的步驟
1. 收集需求
在進入正題之前,先介紹一下常見的需求來源,也就是需求通常是從哪里來的:
- 通過問卷、訪談等用戶調研和分析得出
- 通過深入的行業調研和分析得出
- 通過現有的數據分析得出
- 通過競品調研(或類似功能調研)得出
……
當然,這都是比較理想的情況,現實中的需求往往是這么來滴:
- 老板提了一個想法
- 合作部門的某位同事拋了一個需求
- 某個客戶提了一點意見
- 產品經理發現現有系統需要優化的需求
……
所以,很多時候產品經理會身不由己,要去應付別人提的五花八門的需求,總的來說,需求來源可分為
1)用戶需求
這些需求通常通過用戶調研、用戶測試、用戶反饋等方式獲得。用戶需求關注的是用戶的使用體驗,包括產品的易用性、可靠性、安全性以及能否滿足用戶的特定需求。
2)業務需求
業務需求是企業或組織對產品或項目的期望和要求,通常與企業的戰略目標、業務流程、經濟效益等緊密相關,由來源于企業內部。業務需求可能包括提高市場份額、降低成本、增加收入、提高運營效率等。這些需求體現了企業對產品或項目的商業價值和回報的期望。
3)市場需求
市場需求反映了市場的整體需求水平和潛在機會,對于產品或項目的定位和市場策略至關重要。通過市場研究和分析,可以了解市場的需求和競爭態勢,為產品或項目的開發提供指導。
4)技術需求
這些需求可能包括特定的技術標準、技術架構、系統集成等。技術需求關注的是產品或項目的技術可行性和實現難度,對于項目的成功實施和交付具有重要影響。同時,新技術的出現和應用也可能帶來新的技術需求,推動產品或項目的創新和發展。
2. 需求整理
我們在收集了一堆需求后,如何從一大堆需求里挑出該做的需求呢?
1)基于業務場景進行整理
B端產品就關鍵就在于解決業務場景中遇到的問題。那么,我們可以基于真實的業務場景流程,梳理我們所收集的需求。
比如我設計的產品為企業數據安全,那么其針對的最典型的場景就是數據泄密?;跀祿姑艿膱鼍埃覀兛梢允崂沓鲈凇拘姑鼙O控】-【關鍵數據外發】-【泄密檢測】-【泄密告警】-【泄密舉證】-【線下處置反饋】-【持續泄密監控】這一泄密流程中所需要的一切功能和需求點,進而整理出該做的需求。
2)基于決策鏈進行整理
B端產品的決策鏈冗長而又復雜。我們在整理需求時,也可以從Key Person的角度出發,去整理一些針對決策鏈中關鍵人物的需求。比如企業數據安全產品,這款產品在企業中涉及到的關鍵人物如下圖:
基于這些關鍵的決策人物,我們就可以去整理產品的需求,例如:針對CTO,我們的產品所使用的技術一定要夠前沿,如使用神經網絡分析等等;針對IT運維主管,產品的部署和實施要盡可能簡單,最好能旁路部署等等。
3)基于緊急程度進行整理
這里可以采用大名鼎鼎的四象限法則進行整理,舉例如下:
4)基于整體性進行整理
基于整體性進行整理的意思是,我們在整理需求的時候,既要能夠看到產品的細節,也要能夠看到產品的宏觀。
你可以想象成隨時放大/縮小一款產品,這樣就不會被局限在某個小細節或者小需求中,能夠更全面地去考慮多個需求之間的關聯性。
3. 分析需求
用戶需求只是用戶自以為的需求,不夠專業,而且有時用戶說的并非心中所想,也可能不會表達內心真實需求。
分析需求,就是分析出,哪些用戶(who),在哪種場景(where)下,出于什么目的(what),有這樣的需求。
搞清楚這些,才能知道這個需求到底是否值得做,優先級是怎么樣的,后續應該怎么設計方案(how),除了需要挖掘用戶動機尋找真實需求,還需要考慮:
- 該用戶是否為目標用戶:如果不是產品針對的目標用戶,其建議或需求的參考價值可能沒那么大。
- 該需求是否符合產品定位:該需求的滿足可能會影響產品的核心服務,破壞用戶體驗。
- 該需求是否能實現:評估這個需求需要多少開發資源或運營能力,價值有多大?
1)辨別真偽
狹義上的偽需求是指不存在的需求,也就是錯把用戶訴求當成是需求來解決。
而廣義上的偽需求則是沒必要去解決的需求,比如不存在普遍性的需求;已有解決方案的需求;以及用戶不愿意解決的需求。
在實際應用中,我們可以以邏輯思維尋找歸納、演繹的漏洞
歸納法:從個別經驗歸納普遍規律
演繹法:從普遍性結論,推導出個別性結論
2)價值評估
價值評估是個很重要的環節了,不管是內部需求,還是商業化項目,既然要接,一定是有價值的,要不然投入那么資源和時間處理,就是浪費。價值可以按下面幾個評估:
- 實際產生收益
- 覆蓋面判斷:功能使用頻次、用戶群體、能否規模化等
- 數據重要性
- 是否影響流程、工作
- 降本增效情況
- 需求緊急程度
- 市場趨勢
- …
3)優先級評估
每家公司的資源都是有限的,需求實現的成本也需要可控,所以作為一個產品經理,學會管理需求,排定需求優先級,也是一個非常重要的能力。
確定需求優先級是個非常重要的環節,它最終決定了產品會提供哪些功能,產品會長成什么樣,優秀的產品經理應該在確定需求優先級上有自己清晰的思路。
判斷產品需求優先級的主要依據是產品需求的產出投入比,即產品需求的產出價值與投入成本之間的比例。產出投入比越高,代表產品需求的效益越大,產品需求越值得我們開發;反之,產出投入比越低,代表產品需求的效益越小,產品需求越不值得我們投入資源。
產出價值的評估是確認用戶使用該功能可以獲得什么利益,該功能滿足了用戶什么需求,有多少用戶有這個需求,用戶期望產品滿足這個需求的迫切程度;
投入成本是指實現產品需求需要投入多少成本,包括開發的人力成本、固定的硬件投入以及日常的運營成本等。
除了產出投入比以外,產品需求優先級的判斷還需要重點考慮需求的緊急程度。
我們會經常遇到一些從投入產出比來看不重要的需求,但是因為領導原因或市場變化而很緊急,這時候就需要授予該需求較高的優先級。
對于需求排序,我們可以用到兩個方法:四象限法則,P序列
四象限法則:根據重要和緊急程度劃分為四個維度,如下圖所示:
P序列:按照優先級劃分P0>P1>P2>P3>…>Pn,如下圖所示:在工作中產品經理經常會碰到多個需求,沒辦法絕對判斷出哪個需求是P1、哪個需求是P2的順序。
這種情況下,建議按照經驗執行就好,不要那么糾結,反而浪費時間。
4. 輸出分析結果
基于以上分析,輸出分析結果,需求分析的輸出結果是一個文檔,該文檔描述了項目的目標、功能、約束、用戶群體、操作流程等關鍵信息。
三、需求分析的方法
1. 5w2h分析法
需求分析中的5W2H分析法是一種實用的思考方法,可以幫助我們全面、系統地理解和分析問題。這種分析方法主要包括七個方面:
- What——是什么:明確需要解決的問題或實現的目標是什么。這涉及到對問題的定義和范圍的界定,是需求分析的起點。
- Why——為什么:探究問題產生的背景和原因。通過深入了解問題的根源,我們可以更準確地把握需求,提出更有效的解決方案。
- Who——是誰:確定問題的涉及者是誰,包括受影響的群體、利益相關者等。這有助于我們更好地理解他們的需求和期望,從而制定出更符合實際情況的解決方案。
- When——什么時候:分析問題發生的時間節點和時序關系。這有助于我們把握問題的緊迫性,合理安排解決方案的實施時間。
- Where——在哪里:確定問題發生的地點或范圍。了解問題的空間分布和影響因素,有助于我們提出更具針對性的解決方案。
- How——怎么做:思考解決問題的具體方法和途徑。這包括制定詳細的實施計劃、采取適當的措施等,以確保解決方案的有效性和可行性。
- How much——多少:評估解決問題的成本、效益和資源需求。這有助于我們在制定解決方案時充分考慮經濟性和可持續性,確保投入與產出的平衡。
2. HWM分析法
HMW,全稱“How Might We”,即“我們可以怎樣”,其中:
- How:表示我們假設問題是可以解決的,只是我們尚不知道如何解決
- Might:暗示現在討論的想法不用太完美,支出大概有哪些方向即可,問題有無數的解法,我們可以有很寬廣的創造空間
- We:強調團隊的重要性,不是單一成員的努力就可以解決問題,是需要整個團隊的力量才可以解決這個問題
How Might We(簡稱HWM)分析法是一種創新思維工具,通常用于設計思維或用戶研究中,幫助團隊從用戶的角度出發,重新定義問題并探索可能的解決方案。這種方法鼓勵團隊從用戶的角度出發,思考如何滿足他們的需求和期望。
可以改變我們固有的思維邏輯方式,防止自己圈定在一個圈層或者方向中,開拓自己的思維層面,不受單種方式的拘束,使得我們在同個問題上可以發散性地對多個方向進行剖析,確保創新者正在使用最佳的措辭提出正確的問題。
HWM分析法的核心步驟包括:
- 深入了解用戶:通過用戶訪談、觀察、問卷等方式,深入了解用戶的需求、痛點和期望。
- 定義問題:根據收集到的用戶信息,將問題或挑戰轉化為更具體和用戶導向的表述。拆解問題的方向:
- 否定(逆向思維):如何想辦法讓用戶放棄這個想法
- 積極(發揮積極影響):如何讓用戶提升自己來解決這個問題
- 轉移(移除消極影響/換其他方案):如何讓其他人解決問題,繼而解決這個用戶的問題
- 腦洞大開:發散思維,從需求或環境中創造類似的體驗,或改變現狀……
- 分解:將大問題拆分成很多小問題
- 生成HWM問題:基于定義的問題,創建一系列以“How Might We”開頭的開放性問題。這些問題旨在激發團隊的創新思維,探索可能的解決方案。
- 討論與頭腦風暴:團隊成員針對這些HWM問題進行討論和頭腦風暴,產生各種可能的解決方案或想法。
- 篩選與優化:評估并篩選出最具潛力和可行性的想法,進一步優化和完善這些解決方案。
3. 馬斯洛需求層次理論
馬斯洛需求層次理論是關于需求結構的理論,包括人類需求的五級模型,通常被描繪成金字塔內的等級,從低到高分為五個層次:生理需求、安全需求、社交需求、尊重需求和自我實現需求
這五個層次的需求像階梯一樣從低到高逐級上升,但這種順序并不是固定不變的。當低層次的需求得到滿足后,人們會追求更高層次的需求。同時,不同個體的需求層次也會有所差異,同一時期內可能存在多種層次的需求。
- 生理需求:這是人類最基本的需求,包括食物、水、空氣、睡眠等。這些需求是滿足人體基本生理機能所必需的,如果這些需求得不到滿足,人類的生存就會受到威脅。
- 安全需求:當生理需求得到滿足后,人們會追求安全感,以保障生命、財產和健康的安全。這種需求表現為對穩定、秩序和免除恐懼、威脅與痛苦的需求。
- 社交需求:當生理和安全需求得到滿足后,人們會開始追求社交歸屬感,希望與他人建立關系,如親情、友情和愛情等。如果社交需求得不到滿足,人們可能會感到孤獨和失落。
- 尊重需求:人們都希望自己的能力和成就得到社會的認可和尊重。這種需求分為內部尊重和外部尊重兩部分,內部尊重是指個人希望自己在各種情境中有實力、能勝任、充滿信心、能獨立自主;外部尊重是指個人希望有地位、有威信,受到他人的尊重和高度評價。
- 自我實現需求:這是最高層次的需求,人們希望發揮自己的潛能,實現自己的理想和目標,追求個人成長和自我價值的實現。如果這一層次的需求得不到滿足,人們可能會感到空虛和失落。
4. KANO模型
KANO模型是一個用于分析用戶需求的工具,由日本學者狩野紀昭(Noriaki Kano)在1984年提出。該模型旨在將用戶需求進行分類和優先排序,以幫助企業更好地滿足用戶需求,提高產品或服務的滿意度。
- 基本(必備)型需求:顧客對企業提供的產品/服務因素的基本要求。當需求沒有實現時,客戶很不滿意;當需求實現時,客戶會覺得理應如此。
- 期望(意愿)型需求:顧客的滿意狀況與需求的滿足程度成比例關系的需求。當需求沒有實現時,客戶很不滿意;當需求實現時,客戶滿意。
- 魅力因素:用戶意想不到的,如果不提供此需求,用戶滿意度不會降低,但當提供此需求,用戶滿意度會有很大提升。
- 無差異因素:無論提供或不提供此需求,用戶滿意度都不會有改變,用戶根本不在意。
- 反向因素:用戶根本都沒有此需求,提供后用戶滿意度反而會下降。
5. Y模型
Y模型是一種需求分析方法,主要用于將用戶需求轉化為產品功能,并深入挖掘需求的本質。
- 用戶需求:在具體業務場景下用戶提出的需求,這是用戶給出的解決方案。但要注意,這還只是表象,需要進一步挖掘背后的目標和動機。
- 產品需求:在用戶需求的基礎上,通過不斷地問“為什么”,挖掘出用戶的產品需求。這一步需要結合場景思考用戶需求,帶入用戶的角色,同時要考慮用戶目標和產品目標,確定合理的解決方案。
- 馬斯洛需求:在產品需求的基礎上,深入挖掘需求的第三種深度,即馬斯洛需求,或稱為需求的本質。這是從人性角度出發的需求分析。
- 產品功能:根據用戶需求深度剖析得出的解決方案,是實施人員能看懂的描述。
6. 用戶故事地圖
用戶故事地圖是一個視覺化的工具,它幫助團隊更好地理解用戶的需求和期望。
這個地圖是圍繞用戶的活動、任務和故事構建的,為團隊提供了一個清晰、有組織的視圖,以確保產品能夠滿足用戶的核心需求。
第一步,進行產品定義。我們要確定我們的用戶是誰?解決什么問題?用戶目標是什么?產品目標是什么?通過這些問題,可以基本框定整體的范圍。
第二步,梳理骨干故事。梳理故事要確定好一級故事、二級故事,保證故事的完整性,同時要廣度優先,而非深度。最后的效果就是看到故事群。
第三步,拆分故事。在剛剛梳理的每一個二級故事下面做停留,去拆分二級故事獲取更多細節內容。圍繞這個故事寫更多細節。
第四步,溝通確認。這一步是將前面豐滿而又臃腫的故事,通過對標標題、充分討論,把公認的留下來,無用的剔除掉,同時區分要做的故事細節的優先級。
在實際應用中,用戶故事地圖的作用主要體現在以下幾個方面:
- 幫助組織確定最佳實踐:通過用戶故事地圖,團隊可以清楚地看到用戶的實際使用場景和需求,從而決定如何最好地滿足這些需求,實現產品的最佳實踐。
- 用故事繪制關鍵要素:用戶故事地圖通過描繪用戶在使用產品過程中的各種活動和任務,幫助團隊識別并理解產品的關鍵要素,包括功能、性能、交互等。
- 創建用戶路徑跟蹤器:用戶故事地圖也是一種用戶路徑跟蹤器,它展示了用戶在產品使用過程中的整個流程,從而幫助團隊發現可能存在的問題和改進點。
用戶故事地圖通常包括角色、活動、任務和故事等元素。每個角色都有一系列相關的活動,每個活動又包含多個任務,而每個任務背后都有一個或多個用戶故事。
這些故事描繪了用戶想要實現的目標以及他們為何需要實現這些目標。
四、需求分析的技巧
需求分析前,先去了解這個需求的背景,多做點準備工作,這樣才能和用戶更好地交流。
注意一些詢問的技巧,要用用戶能聽懂的語言,也要聽他們的業務語言,切忌用系統語言或者技術語言去溝通。
要學會引導,讓用戶不單單停留在需求表面,要讓他們講出背后的邏輯,到底想要的內容是什么。
不要事先對需求進行假設,先代入,你的后續聆聽、分析,都會受到影響,要持開放態度。
可以借助一些可視化工具進行需求分析,比如圖表、流程圖等,這樣你分析的結果會更直觀,更容易讓你的用戶和IT團隊的小伙伴理解。
一定要有優先級排序,要學會合理使用資源,控制資源。
需求變更一定要有事先的說明,尤其是商業化項目,定制化需求,涉及到收費的,提前說好,最好是合同寫清楚,要求變更的后續內容,影響,都得同步到相關人員。
需求分析的結果要郵件同步,相關人員確認,避免后續一些不必要的官司。
作者:諾兒筆記本,公眾號:諾兒筆記本
本文由 @諾兒筆記本 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!