1.需求采集

在實(shí)際項(xiàng)目中，采集需求的主要方式有自身產(chǎn)品定位，用戶調(diào)研，競品分析，建立用戶畫像，用戶反饋（上線后），產(chǎn)品數(shù)據(jù)（上線后）。

理論上較全的調(diào)研與采集方法，見下圖

2.需求分類

可分為：功能類需求，運(yùn)營類需求，數(shù)據(jù)類需求，設(shè)計(jì)類需求。也可細(xì)分為如下圖：

3.需求分析

從用戶提出的需求出發(fā)，找到用戶內(nèi)心真正的渴望，再轉(zhuǎn)化為產(chǎn)品需求的過程。

篩選不合理需求-----挖掘用戶目標(biāo)-----匹配產(chǎn)品定位------定義優(yōu)先級

3.1PSP法(P(person)、S(scenes)、P(Paths)，即角色-場景-路徑法。）

3.2如何定義優(yōu)先級

這里還是用最常用的判斷方法，緊急重要四象限法則

重要程度大致按這種排序（圍繞商業(yè)價值和用戶價值分析）：

不做會造成嚴(yán)重的問題和惡劣的影響的

做了會產(chǎn)生巨大好處和極佳效果的

跟重要合作對象或投資人有關(guān)的

跟核心用戶利益有關(guān)的

跟大部分用戶權(quán)益有關(guān)的

跟效率或成本有關(guān)的

跟用戶體驗(yàn)有關(guān)的

緊急程度按這個排序：

不做錯誤會持續(xù)發(fā)生，造成嚴(yán)重影響

在一定時間內(nèi)可控，但長期會有糟糕的影響

做了立刻能解決很多問題、產(chǎn)生正面的影響

做了在一段時間后可以有良好的效果

把能考慮到的因素想全，會標(biāo)上P1 - P4的優(yōu)先級。

1）第一象限：重要且緊急。首要解決這類事情是毋庸質(zhì)疑的了，但需要控制好的是該象限的需求數(shù)量。以你的重要性標(biāo)桿為主，需求提出方的標(biāo)桿為輔，如果本末倒置，就永遠(yuǎn)跳不出這個坑了。

2）第二象限：重要不緊急。對待這一類的需求，不建議立即開工。比“立即執(zhí)行”更重要的，是反復(fù)評估，盡量確保產(chǎn)品方案的嚴(yán)謹(jǐn)性。等時機(jī)成熟，能拿出一個盡量完善的方案支持開發(fā)，高效完成，避免反復(fù)。

3）第三象限：不重要但緊急。這個類型簡直太經(jīng)常遇到了。“反正是小事順手做了吧”、“我們很著急用這個功能，幫個忙嘛”……這個時候千萬要把持住！不要隨口答應(yīng)！千萬記得，再緊急，它也是不重要，既然不重要，就需要好好評估。最可怕的是因?yàn)樾枨筇岢龇街?#xff0c;自己也跟著急，結(jié)果沒有想清楚就提了開發(fā)需求，最后產(chǎn)品方案也不完善、功能又不重要、還浪費(fèi)了開發(fā)資源，最后出力不討好。

那么如何處理這個象限的需求呢？

第一，和需求提出方對重要性和緊迫性認(rèn)知的分歧，需要我們做出進(jìn)一步的溝通，以判斷是否仍然需要你的配合，是否可以轉(zhuǎn)移到其他象限；

第二，如果對方確認(rèn)仍需要向你提出需求，那就要考慮該需求和自己的其他項(xiàng)目是否有重疊，如果是可以一起開發(fā)支持，那就一并放到其他項(xiàng)目中；

第三，如果該需求確認(rèn)需要你配合，又和其他項(xiàng)目無重疊，又很緊急，那么這時候需要和需求提出方確認(rèn)下能夠接受的時間期限，盡量爭取自由度，即便需要臨時支持，也要給現(xiàn)行的項(xiàng)目足夠的緩沖。

4）第四象限：不重要不緊急。遇到這類的需求，就不要裝好人了，該推掉就推掉吧。如果對需求的認(rèn)知有歧義，那么就幫助需求提出方了解為什么是不重要又不緊急。總之，把你的精力放在其他需求上吧。

4.需求評審

有了確切方案，我們會盡快跟研發(fā)的同事做可行性評審。這一步必不可少。出現(xiàn)的「落不了地」和「頻繁更改」的問題，要著重在這個步驟里解決。

可行性評審上，完成的是對需求的大致評估，要做的有這么幾件事：

4.1.方案本身的可行性

在技術(shù)方案上，是不是能夠完成？就是讓技術(shù)部門評估這個問題。

4.2.有沒有更好的方案？

一定要跟技術(shù)部門灌輸清晰的需求背景，讓他們也想一些可行的方案。方案未必是完整、準(zhǔn)確的，但他們提供的思路，一般是可行性較高的。

4.3.涉及的產(chǎn)品和技術(shù)環(huán)節(jié)有哪些？

這個需要相關(guān)的同事仔細(xì)討論。尤其是很多公司產(chǎn)品線比較多，有可能存在牽一發(fā)動全身的情況，如果相關(guān)的產(chǎn)品同事和技術(shù)同事不知情，必然會延期，必然會扯皮，必然會造成麻煩，必然會有各種改動。即便是再小的產(chǎn)品，也要分前后端，讓技術(shù)的同事來判斷有哪些人需要知情和參與評估。

4.4.方案的成本如何？

看方案需要多少人、多少資源、多少時間來完成，也要看方案在技術(shù)層面耗費(fèi)的不太明顯的成本，比如服務(wù)器成本、帶寬成本，給用戶造成的流量成本等。

有了這樣的討論，會議輸出的，就是比較嚴(yán)謹(jǐn)?shù)目蓤?zhí)行方案（或草稿）了。

如果會上遇到各種問題，要確認(rèn)解決問題的時間節(jié)點(diǎn)。

5.花兩個月收集的需求資源大放送

百度云盤資源地址：http://pan.baidu.com/s/1eSkBAs6

密碼：5buz

作者：堅(jiān)果nut2008
鏈接：https://www.jianshu.com/p/2f06c6cdb2de
來源：簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

總結(jié)

以上是生活随笔為你收集整理的从一百篇文章中总结出的需求分析四步法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。