如何進行需求管理？

01-04

需求採集、需求分析、需求篩選、需求處理這4個步驟有什麼成體系的方法嗎？有適合的工具進行管理嗎？可以介紹一下工作中的具體方法嗎？

需求管理的一個重要目標是搞清楚

做什麼？

要搞明白「做什麼」，不如先搞明白「不做什麼」，所以需求管理的第一點是：

說NO，就是搞清楚哪些東西不做，讓真正重要的東西暴露出來

如果能做好這一點，我認為需求管理已經成功了一大半。

另外一個目標是做到什麼程度，本質上也是「做什麼」的延伸，這需要你有豐厚的領域知識和經驗，否則就比較難以決定需求實施到什麼程度，所以這需要你：

不斷地積累領域和專業知識，然後據此來判斷

工具的選取是整個團隊的事，要看你的具體場景自己做出選擇，通常情況下一個簡單的項目管理軟體即可。

需求管理，也可以稱為需求工程，是有理論體系可以參考的。甚至有些專業課程。

以下是一本書：http://book.douban.com/subject/3125032/軟體需求模式，應該可以參考一下。

你說的四個步驟大體上是不錯的，但我覺得需求篩選實際上應該包含在需求分析中，第三步應該作的是需求優先順序排序，然後將帶有優先順序序號的需求交給開發者。這其中每一步都需要很多的實踐積累，很難在這裡表述清楚。而且，需求管理和軟體開發模式相關，瀑布和敏捷開發模式中的需求管理過程是相差很大的。我現在在看的一本 http://book.douban.com/subject/4743056/，對敏捷開發中的需求搜集提出了一些很好的引導。

如果你做需求管理，第一步就是識別相關的干係人，就是你朝誰去搜需求。之後需要準備需求搜集的工具，可以是傳統文檔工具，也可以是需求搜集的軟體。將需求編號，記錄下來。

需求也有很多記錄的形式，可以是一句話，也可以是一個詳細的用例，並不一定是越詳細越好，但是一定要保證這個需求的確是真實的從用戶處得來，而且是對用戶有用的。

而後就是需求的討論分析，要結合很多方面進行考慮，這個環節靈活度較大，因項目而異，需要綜合考慮所有的因素，比如客戶的業務邏輯，競爭產品分析，公司的發展策略等。對需求進行詳細化了解，合併同類項、去掉不可能不合理的部分，做好了需求分析，應該就可以得出一套假設的解決方案。

如果需要需求文檔的話，基本上可以輸出MRD或者PRD，當然也可以兩者兼有，起到鏈接客戶和開發者的橋樑作用。也可以要求相關干係人對需求進行確認，比如審核簽字。

需求管理源於業務需要，始於需求挖掘，繼而需求分析，需求定義，需求驗證。周而復始。

一，業務需要說明需求產生的原因，可能是高層制定的目標，中層對工作流程的調整，基層碰到無法解決的問題，用戶需要，外部環境變化，競爭對手策略變化或者政府政策調整等。

需求人員在明確業務需要時，首先明確干係人，其次獲取干係人要求/需求。可以採用的方法包括：行業基準（競品），業務規則分析（產品分析），頭腦風暴，焦點小組，功能分解，根源分析等。

二，需求挖掘階段的目標是找出干係人的真實需求。單方面的口頭描述或者規範章程都可能與實際需求相差甚遠，因此需要需求人員收集各方面需要，交叉驗證，合理推導，發掘出用戶的實際需求。

工作步驟：確認干係人，收集實際情況，整合多方面信息，確認實際需要。方法包括：訪談，觀察，問卷，焦點小組，頭腦風暴，可用性測試，競品分析，數據分析，文檔分析，諮詢專家等。

三，需求分析階段則是對已經收集的真實需求進行規整，包括兩部分內容，組織整理需求和對需求排優先順序。

組織整理需求採用相同粒度描述需求，並描述需求間關係。主要方法包括：功能分解，業務規則分析，數據模型，流程模型，範圍模型，用戶經歷，場景和用例，組織模型。

需求優先順序劃分通過定義需求的優先順序，為計劃安排提供有價值的參考。可以參考的定義維度包括：時間，預算，業務價值，業務和技術風險，實施難度，成功可能性，規範和政策，與其他需求的關係，與干係人的協議，緊急程度等。可採用3/4級優先順序定義，或者MoSCoW模型定義，其中M=必須 S=應該 C=能夠W=將要。

四，需求定義主要工作為根據前期整理的相關文檔整理需求說明。輸出包括：業務需要，需求陳述，組織整理後的需求以及需求優先順序。需求說明主要包括：業務需要，業務需求和系統需求。·

五，需求驗證包括需求檢驗和需求確認，即需求過程中的檢查和需求完成的測試。

需求跟蹤矩陣是個好東西，可以在需求分析階段產出。

其實需求管理很重要的是管理需求變更～以下是我們的一些心得～

概述

如何制定一份縝密的項目計劃可能並不是項目中最難的事情，要應對計劃之外的情況，才是最令大家頭痛的地方。在項目實際推進過程中，不加控制的需求變更往往給項目帶來沉重的負擔和無法預料的風險。因此，設計一套合適的需求變更管理流程和規範，對項目和項目經理而言都是不可或缺的。

問題分析

首先對筆者所在項目做一個簡單介紹：產品層面，我們是一個C端產品，需求主要來源於運營和策劃，就產品階段而言正處於轉型期，現階段主要以新功能探索為主；項目層面，由於功能較為複雜龐大，可切割空間不大，因此每個版本周期都較長（每個版本的產品準備周期，研發周期分別都在15～20個工作日左右），從產品設計到研發並上線的主幹流程是具備的，如下：

筆者定義需求變更包含兩個層面，一是在產品設計階段：需求評審結束，PRD文檔定稿後再對需求稿進行更改，定義為需求變更；二是研發排期結束，定稿開發測試上線計劃，之後凡是計劃外的變化都定義為需求變更。

一開始項目上並沒有對需求變更的流程規範做清晰的定義，因此項目實際推進過程中會出現諸多由變更引發的問題，下面結合實際問題做逐一說明：

問題一.變更多：一開始，項目最大的問題是需求變更很多，如果只是猛的一頭扎進流程中去，反而浪費時間，所以我們嘗試去分析這些變更的原因，看看是否能在源頭堵住變更。經過判斷，發現相當一部分變更是因為需求設計不夠健壯或者交互對需求的理解不到位，在後續的階段發現，進而才開始修改或新增需求。

問題二.變更不規範：變更是在所難免的問題，大家坐下來聊一聊，如果感覺不錯那就把這個變更做了吧，這是我們之前的做法。但，由於缺乏一個明確的基本流程規範，一到變更的時候，處理事情往往丟三落四，進而會出現以下問題：

變更需求提出人太多，不知道聽誰的
變更提出的太晚，留給項目的時間不多了
變更到底做不做，什麼時候做等信息，在各個角色間的信息不同步

問題三.問題帶來風險：項目過多關注於討論變更本身以及變更的意義，往往忽略了實施變更往往會衝擊原有計劃，缺乏完整的風險分析；在變更執行的時候，沒有相對固定的套路和章法，執行過程很鬆散，缺乏一些有效的監控，過程風險演變不得而知。

解決方案

我們在給出解法的同時還需注意到，項目管理所依賴的流程和規範若太強則使項目運轉繁瑣低效；但過弱則又使項目鬆弛散漫。因此，設計對應辦法的時候需要充分考慮各種方案，選取最簡單的方式來實現規範管理。

針對問題一，我們決定優化原有的主幹流程，增加一個承上啟下的環節做需求確認；針對問題二和問題三，我們規範了變更如何審批，變更如何執行兩個過程；建立方式監控項目對變更工作量的承受情況。

主幹流程優化

項目上根據實踐經驗發現僅靠需求評審無法完全保證需求方清楚的澄清所有需求，以及交互方充分的理解需求方的要求，其本質原因在於PRD並不能完整的描述清楚整個場景，許多需求層面的細節和串聯即便在需求評審結束後依然可能覆蓋不全；只有隨著交互設計師把需求完善成結構嚴謹的邏輯圖和場景說明，往往才會發現一開始需求設計不到位的情況，在大版本的情況下，等到整個交互稿都拿出來了再去做變更，變更代價過大/感受也不好。

因此，對於較為複雜的設計，在交互評審之前會拆分一個環節出來，做一個交互主場景的評審。通過新增的環節，確保需求的健全和完善，減少流入後續階段的需求變更數量。

這個做法適用於策劃變更PRD頻繁，以及功能過於複雜伴隨較大的潛在變更風險兩個場景。PRD頻繁變更頻繁並不完全因為功能邏輯設計有漏洞，還有可能是產品規劃/商業分析論證等前置流程沒做好，這種背景下光是增加一個主場景的評審是沒用的，讀者需要仔細分析。

這樣一個交互主場景的評審，具體操作建議如下：

時點：這個環節安排在需求評審結束後，交互評審開始前，且建議在需求評審後儘快安排，大概2個工作日內安排；
內容：交互理解策劃PRD說明後，初步製作交互稿，粒度達到覆蓋主要的場景及完整的邏輯流程，然後召開主場景評審會與策劃/需求方進行確認，確保需求理解正確和需求的健全。
參與人：需求提出方（如運營，市場等），策劃，交互

變更規範明確

變更流程的規範涵蓋兩個主要方面，一是明確變更管理的基本理念；二是明確一旦要做變更，需要依序執行的步驟。

管理變更的理念&>&>

變更管理的核心在於評估需求變更的價值，然後決定做不做以及是否在當前版本做，我們嘗試從更多角度去思考，包括說產品的規劃，需求的特點。

首先分析產品階段特點：我們處在產品轉型這樣一個新舊交叉時期（簡單說就是一方面要維護原有功能，另一方面更需探索設計新的功能），因此這個時期的需求變更可以劃分成四個維度：原有核心功能，原有周邊功能，新功能核心功能，新功能周邊功能；變更也按上述維度進行分類，再考慮版本上線時間和質量，按照以下順序去考慮需求變更（筆者假設質量是恆定的，範圍和進度是變數，所以對範圍和進度進行優先順序排序）：新功能核心功能變更&>原有核心功能變更&>版本上線時間&>新功能周邊功能變更&>原有周邊功能變更。

同時，十分不建議因為緊急需求變更去延遲既定的上線時間，對於項目而言，上線時間是一個很嚴肅的事情，不能輕易的去改變，是大家共同守護的目標。因此，我們定義需求變更凍結時點，原則上在凍結點後不接受任何變更。關於需求凍結點如何設置，不同的項目需要根據實際情況做分析，比如我們的做法是：產品階段的凍結時點是交互場景評審結束後兩天內；研發階段的凍結時點是提測點前兩天左右（設置的原則就是做版本計劃的時候，開發在估算提測時間同時確認showcase時點作為凍結點，而這個時間一般就是提測點前兩天左右）。而實際上對這兩個凍結點，我們會側重於對後一個凍結點的管理。

在應對變更的整體思路上，除了以上的實踐經驗總結而來的基本思路，還建議有條件的項目盡量嘗試固定時間研發迭代時間，周期上如果能達到兩周一迭代是最理想的。我們也嘗試一周一迭代，這時候在應對需求變更的時候明顯更加從容，但適用場景有限，細碎的優化需求是周迭代處理的重點。

執行變更的步驟&>&>

其實變更如何執行，並沒有一個一成不變的套路，但結構上其實還是大同小異，筆者給出項目上的一些實踐供大家參考：

需求方提出變更（建議同一個角色集中由一個人來提變更，比如運營/市場需要分別指定唯一的輸出需求變更的介面人），策劃評估變更必要性，制定變更的方案（建議變更統一由當前版本負責的策劃來統一收集和輸出）；如果需要交互設計，需要和交互一起討論實現方案。
策劃通知開發，開發同學評估變更工作量，一般情況下，開發和策劃共同決定是否在當前版本實現變更，如果意見不能一致，需要提交可以負責的干係人審批決定，但這種情況往往較少，大部分情況還是要靠產品和開發撕出一個結論。
PK成功的變更將進入研發，站會周知，項目經理評估風險；PK失敗的變更進入需求池，在池子里重排優先順序。對於PK成功的變更，一般而言我們會拿掉一個優先順序較低的需求，保證迭代里工作量相對恆定；但，這只是原則上的做法，我們也會靈活的分析當前剩餘工作量，來決定是否可以直接添加變更，這種做法建議是盡量要少。
在變更執行過程中去監控狀態和風險：我們在項目過程中利用jira的dashboard去監控各個開發變更工作量和剩餘時間，利用每日站會去不斷review確認隊列中的變更，按照優先順序依次完成項目允許範圍內的變更。說明：項目上常常會有這樣的情況，大型的需求變更往往比較正式的走流程，風險比較好把控；對於細碎的小變更，在沒法打包統一處理的情況下，單個開發人員會陸續承受一個一個而來的多個小問題，而這些細小的問題你很難做去做時間承諾，只能大致的感受很簡單+可以改，最終結果可能就是這樣：不知不覺中，隊列中的變更會慢慢增多，一個個未經詳細估算的小點匯聚成較大的風險。

總結

最後總結一下，除了要梳理好策略和流程規範去管理變更和執行變更，還需要選取合適時機引導團隊復盤變更的原因，持續改進策略和流程規範。復盤中需要排除干擾因素，聚焦高頻變更並分析產生的本質。復盤除了支持持續改進，形成流程閉環，也有助於團隊就變更原因和解決方案達成共識，提高團隊管理變更和執行變更兩方面的執行力。

如何深入的做好變更管理，簡化變更的步驟，仍在探索優化中，歡迎大家與我交流。

作者：網易杭研項目管理/何雨（本篇文章僅限知乎內部分享，如需轉載，請取得作者同意授權。）

需求管理從我工作的總結來看有以下幾點

1.客戶的需求，

從客戶角度找到產品的核心的功能和用途，分析出客戶對產品的要求的模型，最關注和重視的是哪些功能，並且從現有的數據和反饋中篩分出真正的客戶需求，而不是從客戶反饋簡單判斷客戶是不是要這個東西，喜歡和討厭某個功能，為什麼喜歡和討厭。。。以及客戶的「建議」也需要去分析和判斷。

2，公司的需求，

包括公司的商業規劃，盈利的方式，盈利指標等等，以及公司高管和其他部門對產品的界面、功能、流程一些理解和要求。

3，其他部門的需求

其他部門對產品的工作量，技術門檻，資源是否滿足等，以及產品項目對他們本身的利益等需求。

4，同部門需求

同部門對該產品的認識和想法、建議，是否配合以及利益影響。

所有需求都是要經過反覆篩選，並辨別出真正的答案，才是能給產品設計與開發，運營提供清晰的方向方法。對需求的分析是要不斷追問為什麼，

需求來源於三個維度，一是市場維度（pest理論），二是商業維度（波特理論），三是技術維度。

三個維度的來源要做好乾系人管理

需求獲取的方式很多，但非常重要但缺失的一環是需求原始素材，而非分析後的結果；需求素材需要電子化、系統化、條目化。

需求分析的過程需要記錄和管控，可以有效識別和準確識別。

需求類屬需要分析管控，並能形成需求樹，利於管理和查缺補漏。

需求要根據價值和客戶關注度進行打分入庫。

需求版本和變更要有完整記錄。

需求要可跟蹤和回溯到需求原始素材，串聯人、物、事、料。

需求基線和產品設計相關，需要根據質量、成本、周期進行綜合衡量，最好是有質量屋管理體系。

要形成有效的需求效能報告和工作效能報告。

需求管理大體就這些。更仔細的內容可聯繫我深入交流。

需求來源於四大維度（社會維度、市場維度、商業維度、技術維度），在四大維度中，相互嵌套，你中有我，我中有你。其中市場、商業和技術都包含在了人性和次級需求裡面。

1、剛性需求（社會維度需求）

剛性需求就是必須要的，比如你生病了，哪怕醫院門面、體驗再垃圾也好，你還是會去，因為不去你就掛了好吧。。。這就是人們的剛性需求，剛性需求滿足人們的基本生存需求，生老病死、衣食住行！這些最基本的需求，也屬於最大的社會需求，但在現代社會來說，社會需求維度方面都已經滿足了。現在市場上在做的產品或方案，更多的是圍繞著剛性需求為核心做的擴展需求，也就是人性需求。

2、人性需求

什麼是人性需求，人性的特點是什麼，那就是永遠不滿足的慾望，得到這個想要那個，不斷的對內對外有更高的慾望和需要。大部分的產品落腳點就在人性需求上。我能吃飽飯了，我開始追求口味，追到口味了，我開始追求環境，追到環境了，我開始追求服務，追到服務了，我開始追求特色。。。。以前要出去外面吃，現在我想要隨時可以吃（外賣）等等，任何一個剛性需求上面，都有產品或服務圍繞人性需求來做開展，每一個節點又輻射出很多很多的痛點。。所有的商品、服務、顛覆，都在這個層面發生。

3、偽需求（意淫需求）

偽需求，顧名思義，就是你丫意淫的需求，或者是你把次級需求當成了剛性需求或者人性需求的高度，然後一直圍繞著這個點在做。那最終給現實啪啪啪打臉的，最終掛掉的也是這種產品。

4、次級需求

次級需求，是圍繞著人性需求後面的優化需求，也可以理解為功能需求、體驗需求等。只是比起人性需求，重要性要往後排，但是這個需求，卻是產品過程中最多最多的需求。也就是需求評估裡面的那些小婊砸！！

確定了自己所屬的在哪裡，那就可以根據不同的需求點進行優先排序了。

從輸出產物都角度來看，需求是：以終為始完成需求文檔的建模和輸出。也就是需求最終不是只為了得到一份文檔而設定的崗位（需求不是打字員）；需求是為了得到一份能夠給開發進一步分析和使用的文檔，需要在前期以專業的方法完成需求調研。

需求調研的首要任務在於找到干係人，也就是知道什麼樣的問題應該找什麼人負責。一般而言，一個IT項目包括了：戰略決策者、項目主導者、業務管理者、使用操作者。通常來說決策層需要負責認可需求的整體範圍，管理層負責業務流程，重要管理規則的正確、合理、完整；執行層參與操作流程，重要操作界面的直觀、效率的確認。但這也只是理論上的。如何尋找到這些人，並讓他們有耐心坐下來，將整個業務說清楚也是一個很大都話題。對了，與不同層次都人溝通也有不同的方法和技巧，需要不同程度的影響力、說服能力、組織協調能力。

再者，因為往往以上用戶並不能完全了解整個業務體系的所有內容，所以需求BA必須有能力引導用戶描述他所熟悉的那一部分，並甄別和確認用戶所屬說都是否為事實。通常來說，決策層需要負責認可需求的整體範圍，管理層負責業務流程，重要管理規則的正確、合理、完整；執行層參與操作流程，重要操作界面的直觀、效率都確認。

當然，需求還必須有辦法確認用戶是否完整描述了整個業務需求。需求必須保障和確定基礎術語的準確含義及誤解的可能、要識別核心需求和偽需求、要引導用戶思考出錯的糾正和排查方式以及許可權需求，要根據系統都複雜性分析操作日誌需求、數據邊界條件的檢查，同時，要學對需求的不同來源的交叉驗證。

總上所述，從責任界定來說：用戶需要負責準確的描述需求（但並不不保證完整），用戶不知道系統能做什麼，需要什麼收集什麼樣的需求、用戶沒有能力完成完整的業務梳理；用戶沒有義務主動的勾勒業務的細節；而需求分析師就需要依靠引導保證完成需求的全面性和條理性；雖然理論上，應該由雙方共同對需求的合理性和必要性負責，並且與管理思路有關的需求決策應該由用戶主導。但需求分析師有責任協助一同挖掘並分析問題的本質，以便於形成最佳解決方案。如果需求與用戶的業務初衷背離，第一責任人永遠是需求分析。

如果說需求分析需要對用戶負責，其實倒不如說需求分析要對整個IT項目負責，要對業務需求的真實性和全面性負責。

再細化來說，需求分析要實現職責，需要有一些需求管理方法論知識、需要在實踐中掌握必要的溝通方法和協調都技巧、需要有快速學習和掌握新領域知識都能力、需要一些項目管理及風險管理的知識。

推薦幾本適合精讀的書籍：

軟體需求最佳實踐 (豆瓣) ：其中的案例非常接地氣，作為入門讀物能夠比較快的了解需求分析的全貌

掌握需求過程 (豆瓣)：老外寫的不錯的需求書籍，也包括了不少案例，和上一本書結合來看，更多從項目管理的全貌來看待需求管理

探索需求 (豆瓣)：從需求引導和需求溝通的角度，總結和很多有意義的理論知識

軟體是這樣「煉」成的 (豆瓣)：非常厚重的一本書，以保險行業系統作為案例，其中對複雜系統抽象和需求建模的過程有一定的參考價值。

從個人的經驗，需求分析不同於開發技術，更重要是實踐，而不是當所有內容都學好之後才開始。在沒有經驗的時候閱讀這些書籍，和有了一些經驗再回過頭來看這些書籍感覺是完全不一樣的。

各位寫了很多,我想補充的是管理用戶(客戶)需求預期也很重要.目的是控制需求的範圍,提高用戶的滿意度.

分享一下我們公司的做法，作為產品經理，最大的痛苦可能就是產品需求的管理，既要廣泛的聽取用戶和小夥伴們對產品的意見，又要不時地應付老闆突如其來的奇思妙想。而這些還只是需求的收集，還有需要評審的，評審中的，評審過了等待開發的，開發完成了的等到測試的等等。此外還有版本的管理，bug的管理等。如果沒有對需求進行很好的管理很有可能造成工作上的疏漏甚至是產品重大功能的缺失，所以對需求的有效管理勢在必行。

第一步，廣泛的收集需求

#截圖來自teamin示例，略有修改，下同

需求的收集不是越多越好，但是在不知道是不是必需的時候全部搜收集過來，從裡面找到符合產品定位和功能需求的也不失為一個方法。把收集到的需求用列表的方式列出來，列的時候可以採用標籤的方式標明需求的來源，方便後期的管理。

第二步，需求分解

在把所有的需求列出來後，需要對收集到的需求進一步進行分解細化，比如常見的註冊登錄功能，用戶可以使用那些工具進行註冊，註冊完成後後可否與第三方賬號綁定，登錄時可以用那些方式進行登錄等這些都是需要產品經理去考慮，而且需求的粒度劃分的越細，對於後期開發的實現難度就越低，換句話說產品更容易做成功。

第三步，需求計劃安排

對收集到的需求進行評審，是否採用，採用的需要在哪個版本里實現，並將評審通過的需求添加到相應的實現產品版本里，沒有通過的放在另一邊。通過評審的需求可以指定不同的執行者來負責這條需求的最終實現，也可以給需求制定截止時間並通過添加標籤的形式來標明需求的重要緊急程度，以示區別。

第四步，需求跟蹤

需求評審通過後，需要技術哥哥去開發實現了，需求的開發進展是怎麼樣的呢，這個可以通過看板的方式來實現。這個流程也是可以自定義的，添加你認為是必須的環節，比如測試驗收，產品驗收環節等。通過這個看板，需求甚至是整個產品的進展一目了然，再也不用為紛繁複雜需求感到頭疼了。

1、要事第一，重要的需求提前做。

2、及時記錄。格式自己定義，但是要隨時記下來，定時整理。

3、重複第2條。

您好，我用過的在需求管理方面比較好用的軟體有統御項目管理軟體，其需求管理功能模塊幫助用戶實現項目需求條目化、版本化、層次化管理，支持建立需求跟蹤矩陣，輸出需求變更影響分析。每個需求文檔都嚴格的許可權控制，需求條目屬性可按需擴展，需求內部狀態可流轉，支持發起需求流程。需求文檔可以輸出成Word文檔，也能從Word或Excel導入需求到系統中。結合即時通訊工具叮咚，系統可在需求狀態變化或發生變更時自動通知到相關人員。希望對您有所幫助。

各位大神都寫的很詳細，作為一個有少許需求經驗的從業者，我覺得兩條比較重要：

1、需求確認，需求分析過程中確認與分析後確認，是否滿足原始需求。

2、需求變更控制，要控制需求變更，並與客戶提前溝通好變更代價，避免客戶重複變更。客戶要的東西永遠沒有止境，不控制就會導致需求不斷蔓延，最終需求變形。

需求管理卡片

什麼是需求管理？

通俗點講（「通俗點講」的意思是按我的理解）就是挖掘用戶需求，並對用戶需求進行評估，根據評估結果來推動產品側進行改進，直到需求被滿足，然後繼續下一個循環。

我在之前進行需求管理的時候通常會用到兩個需求管理卡片：

1. 單項需求卡片

https://pic2.zhimg.com/v2-339efb5a148cd838837148247249e515_b.png

2. 需求池管理卡片

https://pic2.zhimg.com/v2-6a4d87579a84dce0b2ff8a29cbabfb35_b.png

在利用需求卡片進行需求管理的過程中包括幾個關鍵節點：

挖掘用戶真實需求
對需求價值進行評估
怎麼滿足用戶需求
是否有數據可以評估需求滿足效果

挖掘用戶真實需求的時候通常採取場景帶入的方式：什麼人什麼時間在什麼情況下什麼樣的需求。

場景帶入的方式能讓我們快速地評估一項需求的真偽，但如果只是這樣判斷一項需求的真偽的話是遠遠不夠的，還需要了解把場景再明確一些：

需求從哪裡來？
來自哪部分用戶？
這部分用戶是否可以聯繫到？

對需求價值進行評估主要考慮需求強烈度，又可以分為兩個方面：用戶容量和需求價值。

用戶容量也就是指產生這項需求的用戶基數。產品經理在進行需求評估的時候通常情況下應首先滿足大多數人的需求，如果只是專家級的用戶或者一些對產品某個附加功能存在需求的時候，這時候可以考慮直接忽略，因為大部分的用戶可能根本不會去關注這些需求，比如蘋果公司在設計ipod的時候，有專家撰文寫該產品糟糕透了，不能聯網，容量也不大，但蘋果公司並沒有過多關注這些聲音，ipod一經上市就大獲成功，因為大部分用戶的需求是用來聽歌而不是用ipod來上網的。

判斷一項需求的價值同樣分為兩個方面：商業價值和用戶體驗價值。商業價值很容易理解，也就是能不能直接或者間接帶來收益或降低成本。用戶體驗價值指的是是否給用戶帶來了便利，是否採用更好的方式滿足了用戶的需求，用戶滿意度有無上升等等。

採取什麼樣的方式來滿足用戶需求，這個也是比較重要的。通常情況下，並不是所有人都有機會從一張白紙開始設計的，大部分產品經理更多時候是在原有產品的基礎上來進行更新優化迭代的，所以在設計具體的功能時（注意這裡說的是產品功能而不是指產品界面，產品功能更多是指產品的一個交互流程以及交互呈現結果，產品經理切忌把自己只當作界面設計經理），可以參照之前產品設計形式以及該形式的用戶反饋情況，也可以看一下競品是如何做的，有關這部分，在下一篇文章中說明。

通過數據來評估用戶需求是否得到滿足，凡是不能評估的需求也是不能被優化的，如果對該需求進行滿足卻無法判斷出滿足效果如何，那這個需求就是可以直接忽略掉的，作為產品人員一定要關注需求滿足之後，相關數據的表現。另外，數據只是指明了一個方向，數據怎麼用，用哪部分數據是產品人員更應該關注的。

以上，本文主要聊了如何進行用戶需求評估，感興趣的可以收藏下來。另外，我把自己之前用來進行單項需求管理卡片以及需求池管理卡片分享給大家，希望對你有用。

（獲取鏈接: http://pan.baidu.com/s/1dFioqYH 密碼: inun）

按照套路插播一條硬廣，個人公眾號：王豫強不定期分享個人關於產品和運營的感悟

第一、確定的需求：被定義為由你所掌控的或更高的資源已經確定了的、需要實現的需求。它的管理問題就跳轉成為制定迭代計劃的問題。

第二、未確定的需求：還未被確定的需求。它的管理問題就跳轉成你是不是需要將其變成「確定的需求」的問題，伴隨出現的是when,how much.....等問題，不是局外人可以回答了的。

歡迎參加需求管理主題活動分享會

活動時間：7.30下午1:00

活動地址：浦西開元酒店三樓四季軒

主題內容：

1、需求管理框架（Requirements Management Framework）

1.1 業務需求管理介紹

1.2 需求管理的重要性

2、分析項目利益相關者（Identify Stakeholders）

2.1 提取核心項目利益相關者的需求

2.2 需求管理人員與項目經理的角色區分

3、項目成功的標準（Success Factors for Projects）

3.1 滿足內外部客戶需求：六重約束之一

3.2 需求管理人員在項目全流程中的定位

4、來自醫藥行業（美敦力）資深BA-Ivy Hu分享「從一個通信研發開程師到專業BA的心路歷程」

5、來自金融與行業的學友 BA(business analysis)在金融行業中的應用。(BA Application in the Financial Industry)

6、解讀全球最佳業務需求管理實踐體系（PBACBAP)

想參加私信我~可以免費送票哦~~