1.需求采集

在實際項目中，采集需求的主要方式有自身產品定位，用戶調研，競品分析，建立用戶畫像，用戶反饋（上線后），產品數據（上線后）。

理論上較全的調研與采集方法，見下圖

2.需求分類

可分為：功能類需求，運營類需求，數據類需求，設計類需求。也可細分為如下圖：

3.需求分析

從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化為產品需求的過程。

篩選不合理需求-----挖掘用戶目標-----匹配產品定位------定義優先級

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

3.2如何定義優先級

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

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

不做會造成嚴重的問題和惡劣的影響的

做了會產生巨大好處和極佳效果的

跟重要合作對象或投資人有關的

跟核心用戶利益有關的

跟大部分用戶權益有關的

跟效率或成本有關的

跟用戶體驗有關的

緊急程度按這個排序：

不做錯誤會持續發生，造成嚴重影響

在一定時間內可控，但長期會有糟糕的影響

做了立刻能解決很多問題、產生正面的影響

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

把能考慮到的因素想全，會標上P1 - P4的優先級。

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

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

3）第三象限：不重要但緊急。這個類型簡直太經常遇到了。“反正是小事順手做了吧”、“我們很著急用這個功能，幫個忙嘛”……這個時候千萬要把持住！不要隨口答應！千萬記得，再緊急，它也是不重要，既然不重要，就需要好好評估。最可怕的是因為需求提出方著急，自己也跟著急，結果沒有想清楚就提了開發需求，最后產品方案也不完善、功能又不重要、還浪費了開發資源，最后出力不討好。

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

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

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

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

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

4.需求評審

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

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

4.1.方案本身的可行性

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

4.2.有沒有更好的方案？

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

4.3.涉及的產品和技術環節有哪些？

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

4.4.方案的成本如何？

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

有了這樣的討論，會議輸出的，就是比較嚴謹的可執行方案（或草稿）了。

如果會上遇到各種問題，要確認解決問題的時間節點。

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

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

密碼：5buz

作者：堅果nut2008
鏈接：https://www.jianshu.com/p/2f06c6cdb2de
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。