產品經理進階：7大層面教你吃透需求 | 產品壹佰

06-20

互聯網時代，似乎每個人都在談需求，剛需，痛點。作為產品經理，更是每天忙忙碌碌的圍著需求打轉。那又可曾停下來想過需求到底是什麼，從哪裡來，怎麼分析，轉化成產品功能？

這篇文章就是我的一些思考，本篇文章也是由問題的形式展開，也是七個問題，大家可以在看文章前，思考下這些問題。

需求是什麼
需求從哪裡來
需求怎麼評估
需求文檔該怎麼寫
需求評審怎麼過
需求變更怎麼辦
需求怎麼管理

一、需求是什麼？

心理學定義

需求是由個體在生理上或心理上感到某種欠缺而力求獲得滿足的一種內心狀態，它是個體進行各種活動的基本動力。

需求是一種狀態，其來源是生理和心理上的欠缺，不滿足。如孤獨，就是社交需求得不到滿足生成的一種心理狀態，它會促使你去聯繫一些人，陌生的或熟悉的；飢餓，生理上的不滿足帶來的需求，促使你去吃東西。

而產品在這起到了什麼作用呢？需求如果存在，那肯定有已存的解決方案（產品），但無論什麼樣的解決方案限於環境，科技，設計等，隨著條件變化，都會存在改進的空間。需求一直在那，在變的是解決方案。如傳遞信息的需求，從古代的烽火，接著是書信，然後是固定電話，然後手機電話，然後是手機微信，後續可能是VR。

例如，在百度上輸入路由器等一些詞的時候，會關聯出各式各樣的詞，查看這些詞，代表著人們各種各樣的目標和原有解決方案的問題。

百度搜索

很多產品在討論需求的時候，會流於表面，最常見的一個問題就是把解決方案當成了需求，對需求的理解挖掘一定要到心理狀態這個程度。因為需求是一種心理狀態，其表現在外會受到認知結構，經驗等的影響，提出的一個個滿足需求的方法。

同時，需求的滿足過程會伴隨各式各樣的情緒體驗，需求的不滿足的怒，需求滿足的樂，需求被人破壞的怨，不斷追求需求的痴等等。情緒對需求動力性起了很大的促進作用，而人們常說的貪嗔痴，也只是需求的情緒體現而已。

需求分類

1、需求層次：馬斯洛需求層次理論

說到需求分類的時候總會把這個拿出來談上一談，其可分為兩大類基本需求和成長需求，基礎需求包括，生理需求，安全需求，歸屬與愛，自尊的需求；成長需求包括認知需求，審美需求和自我實現的需求。在學心理學的時候這個是被作為經典理論來學的，也就是這個理論已經出現很久，久到作者的徒子徒孫都把這個衍生和擴展了不少。這也反面說明了心理學和實際應用的脫節吧。但說回來，作為心理學的學生，不是研究這方向的也就是了解到這個地步，再往下的拓展，也想不起來多少。而且在現實的產品設計過程中也沒把這個應用起來，最多放放馬後炮，這個功能是因為滿足了某某需求。

大家也可以思考下，市面上的各個產品都是滿足了下面的哪種需求。生理需求對應的外賣類，購物類，團購app；歸屬與愛的需求，尊重的需求對應社交類app；認知的需求對應於閱讀，資訊類app；審美的需求對應於音樂類app，旅遊類app；自我實現對應於健康類app。可以看到越是底層的需求，對應的用戶人群就越大。

馬斯洛需求層次理論

2、需求起源：生理需求，社會需求

生理需求，人對維持生命和延續後代所必須具備的條件的反映。

社會性需求，人對維持社會的存在與發展而產生的需求的反映。

3、需求對象：物質需求，精神需求

物質需求：指人為了維持個體和社會的生存和發展，對物質產品的需求。

精神需求：指個體參與社會精神生活的需要。

4、需求滿足後的後繼發展：一次性需求，周期性需求，上升性需求

一次性需求，這類需求一旦獲得滿足，將會消失並且不會再次產生。

周期性需求，這類需求的產生與滿足呈現出周期性變化的特徵。這個又可以細分為高頻需求，低頻需求。頻次可以再結合需求的層次分類來對需求做評估。

上升性需求，這類需求在獲得滿足後，不但不會消失，反而會出現不斷上升的發展變化趨勢。人總是不會滿足於現狀，無論哪個需求在滿足後，其帶來的正向情緒總會慢慢變得平淡。有心理學研究表明，中500w大獎的人在一段時間後幸福感並不比一般人高。也正因為如此，人才能不斷前進。

5、真實需求，偽需求，表面需求

真實需求：反應了用戶內心真正的需求

偽需求：用戶把一些需求包裝成其他的需求，比如說開房去看書

表面需求：用戶依據自己的經驗，認知提出的需求，如更快的馬

需求特點

客觀現實性：如果一個需求存在，肯定是客觀的，有一批對應的用戶，且是可以實現的。不可實現的只是實現需求的方法，你想吃冰淇淋，可能只是因為身體缺少水分，那給你一瓶水也能滿足需求。
主觀差異性：一個需求，即使是大眾需求，但也會因人而異，區分出不同的細分用戶群體。如上例子，每個人口渴想喝的東西可能各不相同。
動力發展性：一個需求的產生會產生用戶心理的傾向，繼而在一定環境的作用下轉變為行為。需求只是一種心理狀態，只有設計合適的場景才能轉化為有效的行為。
整體關聯性：一個需求必然不是獨立存在的，其與人的關聯導致一個需求必然是和多個需求緊密關聯的，看待一個需求的時候，決不能從獨立單一的視覺是看去想去滿足。但這不是讓大家去做一個大而全的需求，只是在考慮需求的時候，從更加完整全面的角度去考慮。就像一個淘寶買衣服的過程，肯定有一個選衣服，比較，購買的過程，在這之外也肯定有為誰買，寄到哪等等各式各樣的需求。

認識需求在產品開發中的作用

是功能設計內容製作的出發點和方向，需求錯則步步錯；
對交互設計指導作用；
對最後的產品其評估作用，是否滿足了原本的需求，滿足程度如何。

我認為需求不是創造的，就像馬車到汽車的飛躍，不變的是出行需求，變化的是需求的創造性的解決方案。

二、需求從哪裡來？

產品經理每天都是未知需求打轉，經常感覺需求無窮無盡，但這些需求都是從哪裡來的呢？我們又該如何去主動獲取需求，保證需求獲得的可靠性呢？

1、用戶研究

用戶研究在需求分析中所起的作用主要有發掘、驗證、明確用戶需求，跟需求來源相關的用戶研究方法主要有：

用戶訪談：通過與用戶訪談的形式挖掘用戶背後的需求，一般有結構化和半結構化訪談的形式。
焦點小組：一個經過訓練的主持人以一種無結構的自然的形式與一個小組的被調查者交談。
問卷調查：通過精心設計的問卷，大樣本量的收集用戶數據。
用戶畫像：通過一系列的定性和定量用戶研究方法，從目標用戶群體中抽離出一些特徵細節，虛構出的一個用戶來代表一個用戶群。

還有一些用戶研究方法如用戶體驗地圖，可用性測試，滿意度調查也就不贅述了。不過，作為產品要多注意把用研的結果結合到需求分析中。

2、用戶反饋

喜歡前幾天看的一篇文章，用戶反饋是建立產品與用戶情感聯繫的極佳方式（建立用戶與產品的情感關聯，最有效的辦法是打造用戶反饋體系）用戶反饋的功能設計後續可以獨立作為一個產品設計框架來講，在這先說下處理的流程。：

收集：收集用戶反饋的方式有很多，主要有app內部反饋模塊，微博，微信服務號，qq用戶群，論壇，反饋郵箱，應用平台用戶評論，競品的應用市場評論。收集不僅僅包括用戶說出來的話，還要收集一些隱藏信息如版本，機型等等信息。在收集的同時，對應人員需要對用戶按照模板進行回復，可有一定的個人色彩。（ps.產品經理作為最了解產品的人，需要參與到這個步驟中，整理出用戶常見的問題和疑問，制定合適的回答模板，並且和對應人員實時溝通，解決疑問。）
整理歸類：對收集的用戶反饋根據app的特點進行歸類整理，統計頻次和時間段，並提交給相應的人員。功能建議，內容要求和bug等，都要有相應的人員跟蹤解決。
轉化：傳遞給產品人員的主要是功能需求，優化建議，體驗問題等，這時候產品就需要對用戶反饋進行分析轉化為產品需求加入需求庫，在合適的時機轉化為產品迭代中。

馬化騰在騰訊研發部關於「產品設計與用戶體驗」內部講座中說到，騰訊有一個「10/100/1000法則」：產品經理每個月必須做10個用戶調查，關注100個用戶博客，收集反饋1000個用戶體驗。在bat中，騰訊的產品體驗是明顯優於其他兩家，這並非沒有原因。

我們能收集到用戶反饋永遠只是停留在我們APP的用戶中的願意反饋的一部分用戶的聲音。我們更需要的是沒有來用，用了就走了的用戶的聲音。過於關注已有用戶的聲音，為他們做需求，對於小眾的APP來說，會非常致命。這樣的迭代往往會讓產品越走越偏，吸引新用戶能力反而更差。在pc端的時候，在用戶卸載一個軟體時，總會跳出來一個提示框，讓用戶說明下卸載的原因，相信大家都是直接點叉走人。也說明了這個問題其實一直都在，這也需要我們能跳出自己的app的現有用戶範圍去收集更多的用戶信息，反饋。

3、數據分析

我現在的工作內容比較雜，數據分析的工作也要接觸，就整理了下流程，順便推薦大家看看這篇文章（數據驅動設計：數據處理流程、分析方法和實戰案例）：

確定目標：結合產品階段，迭代情況，版本上線設定數據分析的目標。只有知道了目標才能有的放矢，有針對性的去收集相關數據，一個數據往往不是孤立存在的。留存的上升，可能和某個功能的使用上升，活動頁面點擊增加等等。
確定指標：有了明確的目標後，把目標分解成各個相關指標，指標應該是完備的，可以充分的說明目標的情況，變化。舉個例子，搜索功能，要考慮各個頁面的搜索入口顯示/點擊/用戶數，搜索按鈕顯示/點擊/用戶數，搜索結果顯示/點擊/用戶數，熱搜顯示/點擊/用戶數，再次搜索數等等，搜索失敗次數/原因，熱門搜索關鍵字等。
收集數據：有些數據能從後台直接獲取，有些數據需要在版本上線前（APP）提前說明，埋點，返回欄位。
數據整理：獲得了數據之後，可以從指標（用戶數，留存數，活躍數，充值數）X維度（渠道，版本，地域等）的角度來進行拆分整理。
數據分析：對整理的數據進行分析解釋，闡明原因，提供建議
數據傳達：把數據整理和分析的結果以合適的形式，ppt，圖標，excel的形式傳達給相關的人員，進行討論。

上面這個流程是針對自己產品的數據工作，其他的數據來源就比較雜，諮詢公司出的分析報告，大公司的發布數據，各個應用平台可見數據，還有像appannie，百度指數等等，也可以作為產品工作的一個參考。

很多時候，有數據作為支撐討論問題，評審需求都更有底氣，也能避免產品經理拍腦袋（雖然有時候也需要~）。

4、競品分析

對於競品分析，相信大家都做了不少，也形成了各自的一些競品分析方法。我在網上也看到了不少競品分析的文章和方法，各有側重。我現在寫的，也是一時之見，隨著將來水平的進步，肯定還會不段的優化。但，只有不斷的寫，才能不斷的進步：

競品定義：

直接競品：相同核心功能，用同樣的產品功能來滿足用戶如qq音樂與酷狗音樂。
間接競品：針對的是相同的用戶群體，如nice，same等這類社交軟體。
潛在競品：橫向行業相關的產品，或者上下游產品，如支付寶與銀聯。

競品尋找方法：

關鍵片語合搜索
應用平台分類排行
各種分析報告

分析流程：

目的：主要分為兩種，一是尋找目標產品對自己產品的優缺點，威脅和機會等，方便工作；二是為了學習，那也要有一定的側重點，是功能，界面，交互視覺，盈利模式，不一而足。明確自己的目的還能更好有所取捨的做好分析，不然一篇分析文章下來，長篇大論，卻漫無目的。
行業分析：查看一些網上的分析報告，文章，知道該行業的市場大小，主要用戶群體，代表產品及其信息。不過，我不太喜歡往分析報告里放太多的行業背景分析，主要是限於自己的水平，這些內容肯定還是從網上摘抄，人云亦云，反而會影響自己的思路。
如果我是產品經理：先思考需分析產品的目標用戶，滿足的用戶需求。在這個前提下，思考，如果是我自己來做會設計哪些功能，需要哪些內容，擁有哪些特色。再思考一下大致的產品結構。帶著自己的思考再開始產品分析會經常帶來驚喜。
化身小白：把自己當作小白用戶，從icon開始，把產品的核心流程，主要界面都走幾遍，記錄自己的使用體驗。
細化分析：根據粗體驗的結果思考是否需要進一步分析。如果需要，做出產品結構圖，然後再分析核心流程體驗，主要界面。在分析這些的時候需要緊扣用戶需求，考慮在這個流程，界面用戶想要什麼，場景是怎麼樣的，怎麼要，產品又是怎麼滿足的。
重新思考3（自己思考）與5（實際產品）之間的區別，思考做的功能和內容為什麼做，不做的為什麼沒做。如果我來做，接下來應該做啥。
查看各個應用平台的評論（是否和自己在4中的想法一致），迭代情況（理解產品迭代的思路和猜測下一步迭代的方向）

上面是我的一些競品思路，更多的是注重產品思考，多問為什麼和自己應該怎麼做。

比較常見的競品分析思路還有是從產品的五要素出發（參見《用戶體驗要素》），從上而下（戰略層-表現層），結構清晰。但這種方式對於大產品會因為涉及的需求，功能太多，會容易流於表面，蜻蜓點水。

還有是從產品定位，核心功能，主要界面，這樣的方式去體驗，需要體驗者對產品有一定的了解。

還有就是針對產品的某個方面如，SWOT分析，功能羅列對比，波士頓矩陣。

另外再推薦幾篇覺得不錯的相關文章供大家思考：

再談競品分析——選擇重於分析，分析重於羅列

最好的競品分析報告的思路應該是這樣的

FACEBOOK產品設計總監！設計APP時的14個必考題

5、公司內部

1）老闆拍腦袋

作為產品，在創業公司，老闆提的需求佔了需求總量的不小一部分。畢竟在創業公司，老闆才是最大的產品經理，這個產品可能也是老闆以前一點一點想出來的。老闆的大部分想法都比較靠譜，畢竟人家經驗豐富，站得高看的也遠。但作為老闆，顧忌少，又不能很好的遵守需求的流程，但需求優先順序又很高。所以，很多坑就是這麼來的。

就像最近策劃會議的時候，老闆拋出來一大堆的功能，然後讓我們討論，這些功能應該怎麼策劃（創業公司，老闆永遠是最大的產品經理）。我一臉無奈，「老闆功能是為了解決用戶的需求和問題，如果沒有確定用戶需求，那功能策劃只是無源之水，更不要說其後的功能評估了。」爭論了半天，把會議的主題轉到了需求評估上。然後發現老闆的需求都來自和一些家長的聊天，還有自己平時的想法。但這不靠譜啊，所以，議題又轉到了怎麼確定需求。最後，老闆手一拍，我的需求就這樣了，你們回去思考分析下。然後散會。。。需求其實是產品設計的地基，後續的一切都建立在這上面，也是準繩，後續的功能評估也是依賴於此。這裡一步錯，就是步步錯。

（後來老闆還是直接跳過了需求確認會直接開始功能確定會議。。。）

多說幾句，以前剛來這個公司的時候，還得意自己能和老闆拍桌子，討論需求，硬頂一些需求。後來，才發現，得不償失。吵得多了，老闆就開始不局限於需求了，你的思路有問題，你的設計能力欠缺等等。很多時候，要把心態放低，多學習下溝通的藝術。

2）其他產品

是的，作為產品一起思考討論碰撞，還能冒出不少好點子，畢竟一人計短二人計長。尤其身邊有一個有經驗的產品真的很能起到指導的作用，如果沒有就主動走出去認識人。

3）運營人員

運營人員是公司中最直接接觸用戶的一批人，接觸頻率高，很多時候，運營人員能提供很多用戶的反饋，需求。

另一方面，運營也是需求的產生者，運營活動會產生一系列的相關需求。這方面的需求角度和其他的需求還不太一樣，運營一般是背有kpi的，所以更多的和一些運營數據相關。在這裡產品需要起到設計並把關的作用。

4）技術測試

是的，技術，技術的同學總能站在技術的角度提出一些你從來沒想過的問題，思考問題的角度不同，有時候還是能提出一些獨到的見解。就像是我們的技術經理說的，有一個願意給你提意見的技術，總比默默給你寫bug的技術好。願意提意見，需求，說明技術真的在思考產品，可以反過來促進產品經理進一步思考產品的需求。但是有所為有所不為，因為產品和技術在爭論需求時經常處於弱勢，這就要求產品要真正的站在用戶角度提出需求。而不是說老闆說的，運營要求的等等，這絕對是致命一擊。

一個產品經理背後總有一堆指點江山的大神，畢竟產品的門檻低，誰都能說上兩句。但作為產品還是應該積極應對，通過完善的需求獲取方式，把大神們的需求納入到流程規範當中。要說服別人同意你的意見，也要做到有理可依，有據可查。決不能淪落為功能實現經理，畫圖經理，機械地執行任務。

三、需求怎麼評估

需求的評估細分下來還可以分為兩個問題，需求做不做和需求的優先順序問題。

To do or not to do，這永遠是擺在產品面前的一道難題。咋看來是無從下手，但還是有一些明確的方法可以借鑒。

1、邏輯分析法

正如上文需求分類和來源中提到的，我們發現的需求並不一定是毫無問題的。數據分析可能會有偏差，用戶研究可能會有人為因素，但綜合多個來源產生的需求，互相印證，綜合分析，走歪的可能性就大為降低了。很多需求，產品是可以通過經驗和邏輯判斷能力直接去除的。這也是為什麼很多產品經理招聘的要求里有邏輯分析能力強的一個原因。

從一個需求是否需要滿足，可以砍掉一些價值不大的，沒有什麼使用場景的，和無法實現的需求。

對需求進行進一步深挖，把一些表面/偽需求/需求解決方法轉化為真實的需求。

2、產品定位法

產品定位主要包括三方面，目標用戶，主要功能，產品特色。對需求按照這三方面來檢驗，是否是目標用戶的需求，是否和主要功能緊密相關，是否符合產品特色。

就像網易雲音樂，分享聽音樂時的感受這個需求，符合雲音樂的目標用戶（大眾音樂愛好者），跟主要功能（找歌聽歌）比較相關，也符合雲音樂的社交音樂app的產品特色，所以這個需求是可以做的（音樂評論）。（《【聚焦產品核心能力系列】價值鏈導向的產品決策》這篇文章也是類似的角度，講的也挺精彩的，推薦下）

對於產品定位的探討，可以再另外寫一篇文章來探討。

3、KANO模型法

KANO模型把需求分為如圖三類：

基本型需求：

如果此類需求沒有得到滿足或表現欠佳，用戶的不滿情緒會急劇增加，並且此類需求得到滿足後，可以消除用戶的不滿，但並不能帶來用戶滿意度的增加。產品的基本需求往往屬於此類。對於這類需求，產品的做法應該是注重不要在這方面失分。

期望型需求：

此類需求得到滿足或表現良好的話，用戶滿意度會顯著增加，當此類需求得不到滿足或表現不好的話，用戶的不滿也會顯著增加。這是處於成長期的需求，用戶、競爭對手和產品自身都關注的需求，也是體現競爭能力的需求。對於這類需求，產品的做法應該是注重提高這方面的質量，要力爭超過競爭對手。

魅力型需求：

此類需求一經滿足，即使表現並不完善，也能到來用戶滿意度急劇提高，同時此類需求如果得不到滿足，往往不會帶來用戶的不滿。這類需求往往是代表用戶的潛在需求，產品的做法就是去尋找發掘這樣的需求，領先對手。（定義來自於百度，略改）

這表可以通過用戶思考功能實現和不實現時感覺獲得，一共25種可能分類。

字母代表對此功能，實現和不實現情況下的情緒反應對應的人數比例。

同時，E表示興奮型需求，L表示期望型需求，M表示基本型需求；R表示相反的需求，I表示無關緊要的需求，Q表示存疑的需求。

公式中字母代表該需求，選擇這個類型的人數總和。

A=（E+L)/(E+L+M+I)越接近於1，說明增加這功能用戶得到的滿意度提升

B=（L+M）/（E+L+M+I),越接近於1，說明不增加這功能導致的不滿意度上升

A低B高說明是基本型需求，A高B低說明是興奮型需求，A高B高說明是期望型需求，A低B低說明這個需求無關緊要，不需要做。

評估要不要做後，接下來就應該考慮的是，哪個先做，就是需求優先順序排序。

經過上述的一步步，你手裡可能已經有了一堆的需求列表，那什麼該先做，什麼該後做，也許這就決定了你這個產品的生死。如果你是神級產品，按照你的經驗直覺來就好，不過估計也不需要來看我這篇文章了。作為菜鳥產品，就老實按照方法來，積累經驗。

首先，要考慮產品是否已上線，如已上線，需要考慮幾個點：

用戶屬性：是哪一類用戶的需求，核心用戶，次要核心，非核心用戶等；需求用戶數量，來源後台的數據統計，或者用戶反饋的頻次等。我們優先滿足的最大數量的核心用戶的需求。
需求頻率：這個需求（可能）被使用的次數，次數越高，優先順序越高。
需求價值：在12的基礎上結合現階段的產品目標評估需求對用戶價值和商業價值的作用，獲得一個五點評分。
需求成本：考慮需求實現的資源成本（UI，技術，測試等等）
在1234的基礎上得出每個需求的大致性價比，如有些小需求價值不高但實現成本也低，每個版本順手也就做點。
需求類型：這個要看產品對需求的判斷，來源於對用戶的了解，場景的思考。可以考慮採用KANO模型分析，基本需求優先做，期望型需求次之挑選著做，興奮型需求要有一兩個，作為亮點和差異化競爭的點，但產品迭代前期可以先不做。
需求依賴：考慮下需求的依賴關係，前置後置等。產品是一個整體，一個需求也不會是獨立存在的，所以要從一個完整的角度去考慮。像朋友圈，用的人多，頻率高，類型也算興奮型需求，但是要建立在有一定的朋友關係基礎沉澱上。那就需要前置的需求如通訊錄，聊天，還有搖一搖（建立朋友關係)。

考慮了種種要求後，可以得出一個需求優先順序排序列表。

如果產品還未上線，12數據的獲得都是需要產品主動的去獲取，各種競品，分析報告。5中需求類型也優先做基本需求。但整體的步驟相差不大，對產品的要求也更高。

做產品有一個體會就是，越在上游做的多，下游就越輕鬆，寧願在這一步多花一些功夫也不要在產品上線後才發現功能不如預期。

以前待過一家公司，那時候剛去，每周五會進行一次產品演示，把已經開發好的app功能通過大屏幕展現出來，然後讓幾個合伙人看產品是否符合需求。如果有問題就要從頭開始設計，這樣導致的問題就是項目進度非常慢，在我去之前，已經花了兩個多月的時間來反覆修改。這樣做了兩個星期我就忍不住了，這樣的返工效率實在太低，就加入了需求評審和交互稿評審的環節。到了界面開發這個階段，就不再做大的改動，才大大提高了項目進度。

四、需求文檔該怎麼寫

產品要寫的需求文檔不少，但我們一般說起來的，用的最多的，應該還是prd文檔。

prd該怎麼寫呢？

要回答這個問題，首先要考慮的是，這是給誰看的。

同級的產品，交互，UI，技術，測試，運營看的，需要夠詳細，夠清楚，才能讓他們知道怎麼按照需求文檔做。是的，這一大幫子人，都是要依賴這份文檔來下一步工作，這份文檔的基礎性，重要性不言而喻。

那這份文檔應該包含什麼呢，有什麼規範和注意事項。

下面的文字主要來自於我自己工作學習中的感悟，只能說適合我的需要，而且也還在不斷的摸索改進中，大家可以看看作為參考。文後也貼了些一些其他人的文章，大家可以對照的看，以找到合適自己的需求文檔寫作方式。

1、需求記錄

對我來說，這個文檔是我與其他相關人員（老闆，產品組，交互，視覺，技術，測試，運營）溝通和pk的主要工具。每一次的溝通結果都要在這有一定的體現和記錄，只有如此，後續的工作才能有效的展開。而需求記錄在這起到的作用就是對這個過程有個記錄，並且每個看到這個記錄的人都能知道這個文檔的進展，不會做無用功，重複功。可以想像，如果不做詳盡的記錄，文檔的每一次變化，相關人員看到的時候都會不知從何下手，不知道哪裡有變化，上次討論的結果最後如何做等等。需求文檔是一個統一思想，同步進度的工具，而需求記錄就在其中起著至關重要的作用。

做好了這個記錄，需求變更，需求追蹤都會變得輕而易舉，是我們產品與其他人員「撕逼」一大利器。

需求記錄

2、需求背景

介紹市場情況，產品定位，競品分析，用戶研究，需求來源，需求分析等，這些工作都要做的紮實，可以參考前面的內容。要讓文檔面向的對象明白為什麼要做，做的大致方向，起到統一思想的作用。這裡的功夫更多的是在文檔外。

3、總體介紹

對需求總體進行介紹，在這我一般採用思維導圖的形式，對需求進行介紹，涉及的模塊，功能範圍。讓大家對需求有個總體的認識。

不要過早的進入細節，這點還是很有好處的。只有大家的思維站在了同一高度，才不會在後續的需求討論時局限於細節，而這點也是在各個評審會上最令人頭疼的一點。

4、需求描述

需求描述

關於流程圖，很多產品不怎麼畫，但對我來說，在需求的完善階段，一個好的流程圖，能起到查缺補漏的作用，而且可以讓你不要過早的進入到交互，界面，導航的考慮上。這裡想得越清楚，後面的需求變更會少很多。

用這個和開發進行溝通其實挺有幫助的，測試也不需要追在後面不停的問，這裡有個情況怎麼處理。

5、相關原型

原型的做法往細了講，太占篇幅，主要分為低保真，中保真，高保真。在工作中，我一般做到中保真的程度，足夠傳遞界面，交互細節。

這裡還有個特點就是為了便於討論，最好把需要討論的頁面都做出來。

具體一些細節，因為是討論需求的，就不過多討論了。有機會在原型篇章再做討論吧。

五、需求評審怎麼過？

需求到了文檔這一階段，就不再是存在於產品腦海中的事物了，需要通過溝通把需求傳遞給相關人員，這就是需求評審會。

需求評審涉及的人員極多，老闆，產品，交互，視覺，開發，測試，運營，每個人所站的角度都不同，對需求的理解水平也相差極大。

所以需求評審會，是產品推進的一道坎，這一條坎過的好壞，直接影響後續工作的推進。

那需求評審應該怎麼進行？功夫都在會外。

1、提前發出

把需求文檔，原型提前一定時間發出，確定參會人員有時間查看，思考。要考慮項目的時間進度，發出的時間不能太早或太晚。太早，有的人看的早，忘得也早，有的人覺得時間還早，晚點看，就忘了。太晚，大家不一定抽的出足夠的時間來看，來思考。

2、提前溝通

會前需要找關鍵人員進行一對一的溝通，這個主要有三個好處，

一個是確保大家都看了文檔，這樣不會一頭霧水的進入會議室，這樣就會導致會議的效率大大降低，相信我，這樣的會議會出各種幺蛾子。

二是提前溝通，可以讓大家有什麼疑問可以提前提出，如果你已經有思考過，可以提前解釋，節省會議的時間；如果沒有想到（這是很有可能的，畢竟一人計短）那就可以提前做好準備，思考完善。

再者開會時，你是一對多，而且是不同職位的同事，在會議上進行有效說服的成本會很大。一個人提出一個質疑，經常會引起其他人的共鳴，這樣你就要努力說服多個人，這是很痛苦的一件事。

因為一個理由可能只能說服一個人，每個人的思考角度不同，出發點不同，攪在一起，是很難理清的。當然，口才好的，覺得自己能舌戰群雄的同學可以無視這個。

我不希望產品的通過口才來說服同事。很多時候，一個一般的需求也能在產品的妙語如珠下通過。這個真的不是好事，因為產品不能靠口才來打動不能見面的用戶。

在闡明了強有力的理由後，通過事實來說服同事，把信息傳遞給同事，這個才是需求評審的意義。竊以為，這點也是為什麼很多優秀的產品經理都是內向的，因為內向的產品經理，只能通過更加完善的需求來打動同事。

3、確定會議時間，參會人員

開會前的準備工作還有就是，協調參會人員，參會時間，參會地址，確認大家都知道這些信息。可以在會議開始前再通知一次，不然到了點再催就是組織上出了問題。

同時，開會前也要確定下，相關的會議室，設備和材料準備完全。這些事都是細節，但還是挺有用的。

4、會議過程

講解的流程我一般按照需求文檔的內容，可以參見上文《需求文檔該怎麼寫》。如果前面的工作做到位，會議更多的是統一思想同步進度。但需要注意以下的幾個易犯的問題：

1）離題萬里

需求會議一看，大家經常會由一個點，無限的延伸開去。這點其實是好事，說明大家對產品的參與感強，是把產品當做自己的事。但時機不對，導致需求會議是要確定需求，優先順序。新的需求不是在這裡產生的，不經過仔細的思考，研究，拍腦袋的需求大都會誤導大家的思路。

產品經理作為會議組織人，要發現這個的苗頭，做個掃興的人，在大家談性正高的時候，把會議拉回正題。但需要一定的技巧，比如，」大家的建議都很有價值，我這邊都記錄下來了，以後可以專門做些調研，研究。接著我們再確定下個需求吧。「

2）糾結細節

對於交互，界面，大家都有自己的使用習慣，理解，反映出來就是大家都能對這些提一些主觀的看法。很多時候，這個也代表一部分用戶的意見，很有參考意義。但也只能作為一個參考意見，產品如果在這裡過於糾結就會因小失大。

這時候，還是得讓產品說出自己這麼做的理由，並總結他人的理由，做出最後的決定。

3）難以確定

在一些需求上，大家最後都有自己的看法，無法統一，這時候再怎麼糾結也不能做出最後決定。產品可以站出來，擱置需求，會後產品綜合意見，溝通後再做確定。一定要確保會議的順利進行，不能浪費大家的時間。

4）維護自己權威

在看需求會議的時候，在講的一個個需求都是產品經理經過不斷思考，挖掘的需求，可以說每行文字都有產品經理的心血所在。當產品聽到別人的質疑時，總是想說服別人，維護自己的觀點和權威。產品有一定的權威有利於產品項目的推進，但不是靠固執，執拗，反對聽取他人的意見來維護。

在需求會議上，產品一定要記得帶上耳朵和開發的心態，讓大家一起參與到需求確定上來。大家的每一個看法都是促進產品完善，用戶體驗上升的機會。

5）問題反覆

當一個需求確認後，已經推進到下個需求，然後又說著說著又回到了上個需求。這時候，要及時制止，把會議拉回到進度上。還有意見，會後再議。

6）、會議結束

會議結束後，要及時整理會議的記錄，並把大家的意見收集到需求文檔中，附上最後的處理方式，相關修改。

有些懸而未決的問題也要及時找對應的人員確定。

確定的需求也要及時的推進到交互，視覺和開發人員，確定估時，排期。

六、需求變更怎麼辦

需求變更這種事，大家都不想的啦，無辜臉~千辛萬苦的把需求推進下來，這裡面產品花的心血也不少。但作為掌控需求的人，需求變更的鍋只能產品經理背。

1、需求變更的原因

1）產品戰略，市場環境，外部條件變化。這種客觀條件的變化，大部分時候不以產品經理的意志為轉移，只能適應，只是要注意傳達好原因，不要因此影響了團隊士氣。

2）老闆又開始拍腦袋。人家是發工資的，很多時候，你費盡九牛二虎之力也說服不了老闆要改主意。既然反抗不了，那就閉上眼睛享受吧。

如果無法說服老闆，或者被老闆說服，你就要儘可能的執行，完善。即使老闆的想法你覺得非常不對，但講清楚你的意見後，你還是得順從。在公司，不要把產品經理這頭銜太當真，惡了老闆那就去坐冷板凳吧。

3）產品前期工作沒做紮實，尤其是需求分析這一步。這一點雖然坑，但對於新手產品其實是必然要踩的一個坑。對於有經驗的，也只能說盡量避免。產品與技術的矛盾很多時候就來源於此。

4）產品設計出問題。這個也挺常見，一些邏輯流程，交互設計，邊際狀況沒考慮好，或者覺得有更優的方式。到了上線前的測試階段也會出現一些。這種變更就要評估改動的成本和帶來的效益了。

5）在需求確認會，開發覺得能做，隨後也估了時。然後某天，開發溜過來，

「嘿，我覺得這個需求這樣不好，用戶肯定不會這麼用戶我們的產品，這樣做對用戶體驗不好」

「說人話」

「原先的方案有問題，這個需求實現起來會非常麻煩，需要改需求」

一番探討後，擼起膀子改需求唄。

2、需求變更的應對

1）重新分析需求

當變更的時候，不要著急改變，重新思考原有需求的思路，對比新舊需求的變化，變化原因。要對自己原有的思路有信心。對新需求一定要慎重，再慎重！如果新需求提出後再對其變更，非常損害團體的士氣，對後續的工作展開會非常麻煩。

2）更新需求文檔

按照需求流程及時更新相關內容，並在文檔註明索引，方便大家查找和後續追溯。並且根據需求變更大小，通知相應人員同步信息。這裡的人員不要僅限於開發，還有測試，運營，視覺等。要做到信息的及時同步！相信我，這裡有坑，淚目。

3）項目進度更新

需求變更大都會帶來項目進度的問題，在需求變更後，需要及時對其產生的進度影響做評估。

4）需求變更的復盤

這一步其實是產品自身的提高所必須的，前車之鑒後事之師。

講真，需求變更其實是產品與開發最容易產生問題的地方，盜的一張圖，大家可以引以為鑒。

七、需求怎麼管理

我們收集來的需求，按照各自的版本迭代順序，會慢慢上線，但肯定有優先順序和時間前後，那應該怎麼管理呢？

要做好需求的管理，需要建立需求庫和做好版本規劃。

1、需求入庫

建立好需求庫，分析好的需求按照下表進行記錄分類，優先順序，描述等，然後放入到需求庫。如果已明確對應版本，直接放入。

2、需求跟蹤

隨著項目進行及時更新項目狀態，從新建-進行中（記錄目標版本）-已解決（上線），特殊情況如關閉，重開，延期。並在上線後做好需求對應的功能上線後情況，做好數據和用戶反饋跟蹤。

產品到一定程度後，需求庫，及每個版本的需求量都是極大的，一般都是採用一些管理系統來管理，如redmine，禪道等。這之間的差別倒也不大，只要成員之間用的來就行。

不過需要注意，這個只是工具，充分有效的溝通才是最有用的，這裡更多的是一個記錄提醒作用。

這篇文章寫了好久，在寫和查找資料的過程中也總是會冒出一些新的想法，不斷的添加修改。最後，總算覺得再改下去就不知道寫到什麼時候了，而且以我的水平，也只能寫成這樣了。估計要再修鍊一段時間才能站在新的高度來審視需求，這個產品經理的核心能力。

接下來應該會再寫一篇，市場分析方面的文章，現在還在思考和收集資料階段，估計又是痛苦的歷程~

大家有興趣也可以關注我的簡書賬號，靜默之思。裡面也寫了不少產品設計方面的產品框架的文章，請大家多指教~

一些參考的文章和書籍，大家可以看下。

書籍

《產品心經》

《破繭成蝶》

《互聯網產品從設計到運營》

《用戶體驗設計師的成長之路》

文章

產品經理必須學會的會議管理技巧

真實案例：用KANO模型和PSM價格敏感度確定產品功能和定價

心理學之需求和動機

用戶研究的舊瓶裝新酒

產品經理：不要成為作圖經理

【聚焦產品核心能力系列】價值鏈導向的產品決策

作為產品經理，如何給用戶需求排序

你還在犯草根產品經理在犯的錯嗎？

論需求和功能：如何分析需求並設計成功能

產品新人如何開需求評審會？

從哪採集需求？這十方面就夠了

『三分法』搞定產品需求分析

PM大招：百度貼吧前負責人首爆9條心得

任督二脈的啟示錄陋習快速上手

*著作權歸作者所有，轉載請聯繫作者獲得授權。