互聯(lián)網(wǎng)時代，似乎每個人都在談需求，剛需，痛點。作為產品經理，更是每天忙忙碌碌的圍著需求打轉。那又可曾停下來想過需求到底是什么，從哪里來，怎么分析，轉化成產品功能？
這篇文章就是我的一些思考，本篇文章也是由問題的形式展開，也是七個問題，大家可以在看文章前，思考下這些問題。
一、需求是什么？
心理學定義
需求是由個體在生理上或心理上感到某種欠缺而力求獲得滿足的一種內心狀態(tài)，它是個體進行各種活動的基本動力。
需求是一種狀態(tài)，其來源是生理和心理上的欠缺，不滿足。如孤獨，就是社交需求得不到滿足生成的一種心理狀態(tài)，它會促使你去聯(lián)系一些人，陌生的或熟悉的；饑餓，生理上的不滿足帶來的需求，促使你去吃東西。
而產品在這起到了什么作用呢？需求如果存在，那肯定有已存的解決方案（產品），但無論什么樣的解決方案限于環(huán)境，科技，設計等，隨著條件變化，都會存在改進的空間。需求一直在那，在變的是解決方案。如傳遞信息的需求，從古代的烽火，接著是書信，然后是固定電話，然后手機電話，然后是手機微信，后續(xù)可能是VR。
例如，在百度上輸入路由器等一些詞的時候，會關聯(lián)出各式各樣的詞，查看這些詞，代表著人們各種各樣的目標和原有解決方案的問題。
百度搜索
很多產品在討論需求的時候，會流于表面，最常見的一個問題就是把解決方案當成了需求，對需求的理解挖掘一定要到心理狀態(tài)這個程度。因為需求是一種心理狀態(tài)，其表現(xiàn)在外會受到認知結構，經驗等的影響，提出的一個個滿足需求的方法。
同時，需求的滿足過程會伴隨各式各樣的情緒體驗，需求的不滿足的怒，需求滿足的樂，需求被人破壞的怨，不斷追求需求的癡等等。情緒對需求動力性起了很大的促進作用，而人們常說的貪嗔癡，也只是需求的情緒體現(xiàn)而已。
需求分類
1、需求層次：馬斯洛需求層次理論
說到需求分類的時候總會把這個拿出來談上一談，其可分為兩大類基本需求和成長需求，基礎需求包括，生理需求，安全需求，歸屬與愛，自尊的需求；成長需求包括認知需求，審美需求和自我實現(xiàn)的需求。在學心理學的時候這個是被作為經典理論來學的，也就是這個理論已經出現(xiàn)很久，久到作者的徒子徒孫都把這個衍生和擴展了不少。這也反面說明了心理學和實際應用的脫節(jié)吧。但說回來，作為心理學的學生，不是研究這方向的也就是了解到這個地步，再往下的拓展，也想不起來多少。而且在現(xiàn)實的產品設計過程中也沒把這個應用起來，最多放放馬后炮，這個功能是因為滿足了某某需求。
大家也可以思考下，市面上的各個產品都是滿足了下面的哪種需求。生理需求對應的外賣類，購物類，團購app；歸屬與愛的需求，尊重的需求對應社交類app；認知的需求對應于閱讀，資訊類app；審美的需求對應于音樂類app，旅游類app；自我實現(xiàn)對應于健康類app?？梢钥吹皆绞堑讓拥男枨螅瑢挠脩羧巳壕驮酱?。
馬斯洛需求層次理論
2、需求起源：生理需求，社會需求
生理需求，人對維持生命和延續(xù)后代所必須具備的條件的反映。
社會性需求，人對維持社會的存在與發(fā)展而產生的需求的反映。
3、需求對象：物質需求，精神需求
物質需求：指人為了維持個體和社會的生存和發(fā)展，對物質產品的需求。
精神需求：指個體參與社會精神生活的需要。
4、需求滿足后的后繼發(fā)展：一次性需求，周期性需求，上升性需求
一次性需求，這類需求一旦獲得滿足，將會消失并且不會再次產生。
周期性需求，這類需求的產生與滿足呈現(xiàn)出周期性變化的特征。這個又可以細分為高頻需求，低頻需求。頻次可以再結合需求的層次分類來對需求做評估。
上升性需求，這類需求在獲得滿足后，不但不會消失，反而會出現(xiàn)不斷上升的發(fā)展變化趨勢。人總是不會滿足于現(xiàn)狀，無論哪個需求在滿足后，其帶來的正向情緒總會慢慢變得平淡。有心理學研究表明，中500w大獎的人在一段時間后幸福感并不比一般人高。也 正因為如此，人才能不斷前進。
5、真實需求，偽需求，表面需求
真實需求：反應了用戶內心真正的需求
偽需求：用戶把一些需求包裝成其他的需求，比如說開房去看書
表面需求：用戶依據(jù)自己的經驗，認知提出的需求，如更快的馬
需求特點
認識需求在產品開發(fā)中的作用
我認為需求不是創(chuàng)造的，就像馬車到汽車的飛躍，不變的是出行需求，變化的是需求的創(chuàng)造性的解決方案。
二、需求從哪里來？
產品經理每天都是未知需求打轉，經常感覺需求無窮無盡，但這些需求都是從哪里來的呢？我們又該如何去主動獲取需求，保證需求獲得的可靠性呢？
1、用戶研究
用戶研究在需求分析中所起的作用主要有發(fā)掘、驗證、明確用戶需求，跟需求來源相關的用戶研究方法主要有：
還有一些用戶研究方法如用戶體驗地圖，可用性測試，滿意度調查也就不贅述了。不過，作為產品要多注意把用研的結果結合到需求分析中。
2、用戶反饋
喜歡前幾天看的一篇文章，用戶反饋是建立產品與用戶情感聯(lián)系的極佳方式（建立用戶與產品的情感關聯(lián)，最有效的辦法是打造用戶反饋體系）用戶反饋的功能設計后續(xù)可以獨立作為一個產品設計框架來講，在這先說下處理的流程。：
馬化騰在騰訊研發(fā)部關于“產品設計與用戶體驗”內部講座中說到，騰訊有一個“10/100/1000法則”：產品經理每個月必須做10個用戶調查，關注100個用戶博客，收集反饋1000個用戶體驗。在bat中，騰訊的產品體驗是明顯優(yōu)于其他兩家，這并非沒有原因。
我們能收集到用戶反饋永遠只是停留在我們APP的用戶中的愿意反饋的一部分用戶的聲音。我們更需要的是沒有來用，用了就走了的用戶的聲音。過于關注已有用戶的聲音，為他們做需求，對于小眾的APP來說，會非常致命。這樣的迭代往往會讓產品越走越偏，吸引新用戶能力反而更差。在pc端的時候，在用戶卸載一個軟件時，總會跳出來一個提示框，讓用戶說明下卸載的原因，相信大家都是直接點叉走人。也說明了這個問題其實一直都在，這也需要我們能跳出自己的app的現(xiàn)有用戶范圍去收集更多的用戶信息，反饋。
3、數(shù)據(jù)分析
我現(xiàn)在的工作內容比較雜，數(shù)據(jù)分析的工作也要接觸，就整理了下流程，順便推薦大家看看這篇文章（數(shù)據(jù)驅動設計：數(shù)據(jù)處理流程、分析方法和實戰(zhàn)案例）：
上面這個流程是針對自己產品的數(shù)據(jù)工作，其他的數(shù)據(jù)來源就比較雜，咨詢公司出的分析報告，大公司的發(fā)布數(shù)據(jù)，各個應用平臺可見數(shù)據(jù)，還有像appannie，百度指數(shù)等等，也可以作為產品工作的一個參考。
很多時候，有數(shù)據(jù)作為支撐討論問題，評審需求都更有底氣，也能避免產品經理拍腦袋（雖然有時候也需要~）。
4、競品分析
對于競品分析，相信大家都做了不少，也形成了各自的一些競品分析方法。我在網(wǎng)上也看到了不少競品分析的文章和方法，各有側重。我現(xiàn)在寫的，也是一時之見，隨著將來水平的進步，肯定還會不段的優(yōu)化。但，只有不斷的寫，才能不斷的進步：
競品定義：
競品尋找方法：
分析流程：
上面是我的一些競品思路，更多的是注重產品思考，多問為什么和自己應該怎么做。
比較常見的競品分析思路還有是從產品的五要素出發(fā)（參見《用戶體驗要素》），從上而下（戰(zhàn)略層-表現(xiàn)層），結構清晰。但這種方式對于大產品會因為涉及的需求，功能太多，會容易流于表面，蜻蜓點水。
還有是從產品定位，核心功能，主要界面，這樣的方式去體驗，需要體驗者對產品有一定的了解。
還有就是針對產品的某個方面如，SWOT分析，功能羅列對比，波士頓矩陣。
另外再推薦幾篇覺得不錯的相關文章供大家思考：
再談競品分析——選擇重于分析，分析重于羅列
最好的競品分析報告的思路應該是這樣的
FACEBOOK產品設計總監(jiān)！設計APP時的14個必考題
5、公司內部
1）老板拍腦袋
作為產品，在創(chuàng)業(yè)公司，老板提的需求占了需求總量的不小一部分。畢竟在創(chuàng)業(yè)公司，老板才是最大的產品經理，這個產品可能也是老板以前一點一點想出來的。老板的大部分想法都比較靠譜，畢竟人家經驗豐富，站得高看的也遠。但作為老板，顧忌少，又不能很好的遵守需求的流程，但需求優(yōu)先級又很高。所以，很多坑就是這么來的。
就像最近策劃會議的時候，老板拋出來一大堆的功能，然后讓我們討論，這些功能應該怎么策劃（創(chuàng)業(yè)公司，老板永遠是最大的產品經理）。我一臉無奈，“老板功能是為了解決用戶的需求和問題，如果沒有確定用戶需求，那功能策劃只是無源之水，更不要說其后的功能評估了?！睜幷摿税胩?，把會議的主題轉到了需求評估上。然后發(fā)現(xiàn)老板的需求都來自和一些家長的聊天，還有自己平時的想法。但這不靠譜啊，所以，議題又轉到了怎么確定需求。最后，老板手一拍，我的需求就這樣了，你們回去思考分析下。然后散會。。。需求其實是產品設計的地基，后續(xù)的一切都建立在這上面，也是準繩，后續(xù)的功能評估也是依賴于此。這里一步錯，就是步步錯。
（后來老板還是直接跳過了需求確認會直接開始功能確定會議。。。）
多說幾句，以前剛來這個公司的時候，還得意自己能和老板拍桌子，討論需求，硬頂一些需求。后來，才發(fā)現(xiàn)，得不償失。吵得多了，老板就開始不局限于需求了，你的思路有問題，你的設計能力欠缺等等。很多時候，要把心態(tài)放低，多學習下溝通的藝術。
2）其他產品
是的，作為產品一起思考討論碰撞，還能冒出不少好點子，畢竟一人計短二人計長。尤其身邊有一個有經驗的產品真的很能起到指導的作用，如果沒有就主動走出去認識人。
3）運營人員
運營人員是公司中最直接接觸用戶的一批人，接觸頻率高，很多時候，運營人員能提供很多用戶的反饋，需求。
另一方面，運營也是需求的產生者，運營活動會產生一系列的相關需求。這方面的需求角度和其他的需求還不太一樣，運營一般是背有kpi的，所以更多的和一些運營數(shù)據(jù)相關。在這里產品需要起到設計并把關的作用。
4）技術測試
是的，技術，技術的同學總能站在技術的角度提出一些你從來沒想過的問題，思考問題的角度不同，有時候還是能提出一些獨到的見解。就像是我們的技術經理說的，有一個愿意給你提意見的技術，總比默默給你寫bug的技術好。愿意提意見，需求，說明技術真的在思考產品，可以反過來促進產品經理進一步思考產品的需求。但是有所為有所不為，因為產品和技術在爭論需求時經常處于弱勢，這就要求產品要真正的站在用戶角度提出需求。而不是說老板說的，運營要求的等等，這絕對是致命一擊。
一個產品經理背后總有一堆指點江山的大神，畢竟產品的門檻低，誰都能說上兩句。但作為產品還是應該積極應對，通過完善的需求獲取方式，把大神們的需求納入到流程規(guī)范當中。要說服別人同意你的意見，也要做到有理可依，有據(jù)可查。決不能淪落為功能實現(xiàn)經理，畫圖經理，機械地執(zhí)行任務。
三、需求怎么評估
需求的評估細分下來還可以分為兩個問題，需求做不做和需求的優(yōu)先級問題。
To do or not to do，這永遠是擺在產品面前的一道難題。咋看來是無從下手，但還是有一些明確的方法可以借鑒。
1、邏輯分析法
正如上文需求分類和來源中提到的，我們發(fā)現(xiàn)的需求并不一定是毫無問題的。數(shù)據(jù)分析可能會有偏差，用戶研究可能會有人為因素，但綜合多個來源產生的需求，互相印證，綜合分析，走歪的可能性就大為降低了。很多需求，產品是可以通過經驗和邏輯判斷能力直接去除的。這也是為什么很多產品經理招聘的要求里有邏輯分析能力強的一個原因。
從一個需求是否需要滿足，可以砍掉一些價值不大的，沒有什么使用場景的，和無法實現(xiàn)的需求。
對需求進行進一步深挖，把一些表面/偽需求/需求解決方法轉化為真實的需求。
2、產品定位法
產品定位主要包括三方面，目標用戶，主要功能，產品特色。對需求按照這三方面來檢驗，是否是目標用戶的需求，是否和主要功能緊密相關，是否符合產品特色。
就像網(wǎng)易云音樂，分享聽音樂時的感受這個需求，符合云音樂的目標用戶（大眾音樂愛好者），跟主要功能（找歌聽歌）比較相關，也符合云音樂的社交音樂app的產品特色，所以這個需求是可以做的（音樂評論）。（《【聚焦產品核心能力系列】價值鏈導向的產品決策》這篇文章也是類似的角度，講的也挺精彩的，推薦下）
對于產品定位的探討，可以再另外寫一篇文章來探討。
3、KANO模型法
KANO模型把需求分為如圖三類：
基本型需求：
如果此類需求沒有得到滿足或表現(xiàn)欠佳，用戶的不滿情緒會急劇增加，并且此類需求得到滿足后，可以消除用戶的不滿，但并不能帶來用戶滿意度的增加。產品的基本需求往往屬于此類。對于這類需求，產品的做法應該是注重不要在這方面失分。
期望型需求：
此類需求得到滿足或表現(xiàn)良好的話，用戶滿意度會顯著增加，當此類需求得不到滿足或表現(xiàn)不好的話，用戶的不滿也會顯著增加。這是處于成長期的需求，用戶、競爭對手和產品自身都關注的需求，也是體現(xiàn)競爭能力的需求。對于這類需求，產品的做法應該是注重提高這方面的質量，要力爭超過競爭對手。
魅力型需求：
此類需求一經滿足，即使表現(xiàn)并不完善，也能到來用戶滿意度急劇提高，同時此類需求如果得不到滿足，往往不會帶來用戶的不滿。這類需求往往是代表用戶的潛在需求，產品的做法就是去尋找發(fā)掘這樣的需求，領先對手。（定義來自于百度，略改）
這表可以通過用戶思考功能實現(xiàn)和不實現(xiàn)時感覺獲得，一共25種可能分類。
字母代表對此功能，實現(xiàn)和不實現(xiàn)情況下的情緒反應對應的人數(shù)比例。
同時，E表示興奮型需求，L表示期望型需求，M表示基本型需求；R表示相反的需求，I表示無關緊要的需求，Q表示存疑的需求。
公式中字母代表該需求，選擇這個類型的人數(shù)總和。
A=（E+L)/(E+L+M+I)越接近于1，說明增加這功能用戶得到的滿意度提升
B=（L+M）/（E+L+M+I),越接近于1，說明不增加這功能導致的不滿意度上升
A低B高說明是基本型需求，A高B低說明是興奮型需求，A高B高說明是期望型需求，A低B低說明這個需求無關緊要，不需要做。
評估要不要做后，接下來就應該考慮的是，哪個先做，就是需求優(yōu)先級排序。
經過上述的一步步，你手里可能已經有了一堆的需求列表，那什么該先做，什么該后做，也許這就決定了你這個產品的生死。如果你是神級產品，按照你的經驗直覺來就好，不過估計也不需要來看我這篇文章了。作為菜鳥產品，就老實按照方法來，積累經驗。
首先，要考慮產品是否已上線，如已上線，需要考慮幾個點：
考慮了種種要求后，可以得出一個需求優(yōu)先級排序列表。
如果產品還未上線，12數(shù)據(jù)的獲得都是需要產品主動的去獲取，各種競品，分析報告。5中需求類型也優(yōu)先做基本需求。但整體的步驟相差不大，對產品的要求也更高。
做產品有一個體會就是，越在上游做的多，下游就越輕松，寧愿在這一步多花一些功夫也不要在產品上線后才發(fā)現(xiàn)功能不如預期。
以前待過一家公司，那時候剛去，每周五會進行一次產品演示，把已經開發(fā)好的app功能通過大屏幕展現(xiàn)出來，然后讓幾個合伙人看產品是否符合需求。如果有問題就要從頭開始設計，這樣導致的問題就是項目進度非常慢，在我去之前，已經花了兩個多月的時間來反復修改。這樣做了兩個星期我就忍不住了，這樣的返工效率實在太低，就加入了需求評審和交互稿評審的環(huán)節(jié)。到了界面開發(fā)這個階段，就不再做大的改動，才大大提高了項目進度。
四、需求文檔該怎么寫
產品要寫的需求文檔不少，但我們一般說起來的，用的最多的，應該還是prd文檔。
prd該怎么寫呢？
要回答這個問題，首先要考慮的是，這是給誰看的。
同級的產品，交互，UI，技術，測試，運營看的，需要夠詳細，夠清楚，才能讓他們知道怎么按照需求文檔做。是的，這一大幫子人，都是要依賴這份文檔來下一步工作，這份文檔的基礎性，重要性不言而喻。
那這份文檔應該包含什么呢，有什么規(guī)范和注意事項。
下面的文字主要來自于我自己工作學習中的感悟，只能說適合我的需要，而且也還在不斷的摸索改進中，大家可以看看作為參考。文后也貼了些一些其他人的文章，大家可以對照的看，以找到合適自己的需求文檔寫作方式。
1、需求記錄
對我來說，這個文檔是我與其他相關人員（老板，產品組，交互，視覺，技術，測試，運營）溝通和pk的主要工具。每一次的溝通結果都要在這有一定的體現(xiàn)和記錄，只有如此，后續(xù)的工作才能有效的展開。而需求記錄在這起到的作用就是對這個過程有個記錄，并且每個看到這個記錄的人都能知道這個文檔的進展，不會做無用功，重復功?？梢韵胂?，如果不做詳盡的記錄，文檔的每一次變化，相關人員看到的時候都會不知從何下手，不知道哪里有變化，上次討論的結果最后如何做等等。需求文檔是一個統(tǒng)一思想，同步進度的工具，而需求記錄就在其中起著至關重要的作用。
做好了這個記錄，需求變更，需求追蹤都會變得輕而易舉，是我們產品與其他人員“撕逼”一大利器。
需求記錄
2、需求背景
介紹市場情況，產品定位，競品分析，用戶研究，需求來源，需求分析等，這些工作都要做的扎實，可以參考前面的內容。要讓文檔面向的對象明白為什么要做，做的大致方向，起到統(tǒng)一思想的作用。這里的功夫更多的是在文檔外。
3、總體介紹
對需求總體進行介紹，在這我一般采用思維導圖的形式，對需求進行介紹，涉及的模塊，功能范圍。讓大家對需求有個總體的認識。
不要過早的進入細節(jié)，這點還是很有好處的。只有大家的思維站在了同一高度，才不會在后續(xù)的需求討論時局限于細節(jié)，而這點也是在各個評審會上最令人頭疼的一點。
4、需求描述
需求描述
關于流程圖，很多產品不怎么畫，但對我來說，在需求的完善階段，一個好的流程圖，能起到查缺補漏的作用，而且可以讓你不要過早的進入到交互，界面，導航的考慮上。這里想得越清楚，后面的需求變更會少很多。
用這個和開發(fā)進行溝通其實挺有幫助的，測試也不需要追在后面不停的問，這里有個情況怎么處理。
5、相關原型
原型的做法往細了講，太占篇幅，主要分為低保真，中保真，高保真。在工作中，我一般做到中保真的程度，足夠傳遞界面，交互細節(jié)。
這里還有個特點就是為了便于討論，最好把需要討論的頁面都做出來。
具體一些細節(jié)，因為是討論需求的，就不過多討論了。有機會在原型篇章再做討論吧。
五、需求評審怎么過？
需求到了文檔這一階段，就不再是存在于產品腦海中的事物了，需要通過溝通把需求傳遞給相關人員，這就是需求評審會。
需求評審涉及的人員極多，老板，產品，交互，視覺，開發(fā)，測試，運營，每個人所站的角度都不同，對需求的理解水平也相差極大。
所以需求評審會，是產品推進的一道坎，這一條坎過的好壞，直接影響后續(xù)工作的推進。
那需求評審應該怎么進行？功夫都在會外。
1、提前發(fā)出
把需求文檔，原型提前一定時間發(fā)出，確定參會人員有時間查看，思考。要考慮項目的時間進度，發(fā)出的時間不能太早或太晚。太早，有的人看的早，忘得也早，有的人覺得時間還早，晚點看，就忘了。太晚，大家不一定抽的出足夠的時間來看，來思考。
2、提前溝通
會前需要找關鍵人員進行一對一的溝通，這個主要有三個好處，
一個是確保大家都看了文檔，這樣不會一頭霧水的進入會議室，這樣就會導致會議的效率大大降低，相信我，這樣的會議會出各種幺蛾子。
二是提前溝通，可以讓大家有什么疑問可以提前提出，如果你已經有思考過，可以提前解釋，節(jié)省會議的時間；如果沒有想到（這是很有可能的，畢竟一人計短）那就可以提前做好準備，思考完善。
再者開會時，你是一對多，而且是不同職位的同事，在會議上進行有效說服的成本會很大。一個人提出一個質疑，經常會引起其他人的共鳴，這樣你就要努力說服多個人，這是很痛苦的一件事。
因為一個理由可能只能說服一個人，每個人的思考角度不同，出發(fā)點不同，攪在一起，是很難理清的。當然，口才好的，覺得自己能舌戰(zhàn)群雄的同學可以無視這個。
我不希望產品的通過口才來說服同事。很多時候，一個一般的需求也能在產品的妙語如珠下通過。這個真的不是好事，因為產品不能靠口才來打動不能見面的用戶。
在闡明了強有力的理由后，通過事實來說服同事，把信息傳遞給同事，這個才是需求評審的意義。竊以為，這點也是為什么很多優(yōu)秀的產品經理都是內向的，因為內向的產品經理，只能通過更加完善的需求來打動同事。
3、確定會議時間，參會人員
開會前的準備工作還有就是，協(xié)調參會人員，參會時間，參會地址，確認大家都知道這些信息?？梢栽跁h開始前再通知一次，不然到了點再催就是組織上出了問題。
同時，開會前也要確定下，相關的會議室，設備和材料準備完全。這些事都是細節(jié)，但還是挺有用的。
4、會議過程
講解的流程我一般按照需求文檔的內容，可以參見上文《需求文檔該怎么寫》。如果前面的工作做到位，會議更多的是統(tǒng)一思想同步進度。但需要注意以下的幾個易犯的問題：
1）離題萬里
需求會議一看，大家經常會由一個點，無限的延伸開去。這點其實是好事，說明大家對產品的參與感強，是把產品當做自己的事。但時機不對，導致需求會議是要確定需求，優(yōu)先級。新的需求不是在這里產生的，不經過仔細的思考，研究，拍腦袋的需求大都會誤導大家的思路。
產品經理作為會議組織人，要發(fā)現(xiàn)這個的苗頭，做個掃興的人，在大家談性正高的時候，把會議拉回正題。但需要一定的技巧，比如，”大家的建議都很有價值，我這邊都記錄下來了，以后可以專門做些調研，研究。接著我們再確定下個需求吧?！?/p>
2）糾結細節(jié)
對于交互，界面，大家都有自己的使用習慣，理解，反映出來就是大家都能對這些提一些主觀的看法。很多時候，這個也代表一部分用戶的意見，很有參考意義。但也只能作為一個參考意見，產品如果在這里過于糾結就會因小失大。
這時候，還是得讓產品說出自己這么做的理由，并總結他人的理由，做出最后的決定。
3）難以確定
在一些需求上，大家最后都有自己的看法，無法統(tǒng)一，這時候再怎么糾結也不能做出最后決定。產品可以站出來，擱置需求，會后產品綜合意見，溝通后再做確定。一定要確保會議的順利進行，不能浪費大家的時間。
4）維護自己權威
在看需求會議的時候，在講的一個個需求都是產品經理經過不斷思考，挖掘的需求，可以說每行文字都有產品經理的心血所在。當產品聽到別人的質疑時，總是想說服別人，維護自己的觀點和權威。產品有一定的權威有利于產品項目的推進，但不是靠固執(zhí)，執(zhí)拗，反對聽取他人的意見來維護。
在需求會議上，產品一定要記得帶上耳朵和開發(fā)的心態(tài)，讓大家一起參與到需求確定上來。大家的每一個看法都是促進產品完善，用戶體驗上升的機會。
5）問題反復
當一個需求確認后，已經推進到下個需求，然后又說著說著又回到了上個需求。這時候，要及時制止，把會議拉回到進度上。還有意見，會后再議。
6）、會議結束
會議結束后，要及時整理會議的記錄，并把大家的意見收集到需求文檔中，附上最后的處理方式，相關修改。
有些懸而未決的問題也要及時找對應的人員確定。
確定的需求也要及時的推進到交互，視覺和開發(fā)人員，確定估時，排期。
六、需求變更怎么辦
需求變更這種事，大家都不想的啦，無辜臉~千辛萬苦的把需求推進下來，這里面產品花的心血也不少。但作為掌控需求的人，需求變更的鍋只能產品經理背。
1、需求變更的原因
1）產品戰(zhàn)略，市場環(huán)境，外部條件變化。這種客觀條件的變化，大部分時候不以產品經理的意志為轉移，只能適應，只是要注意傳達好原因，不要因此影響了團隊士氣。
2）老板又開始拍腦袋。人家是發(fā)工資的，很多時候，你費盡九牛二虎之力也說服不了老板要改主意。既然反抗不了，那就閉上眼睛享受吧。
如果無法說服老板，或者被老板說服，你就要盡可能的執(zhí)行，完善。即使老板的想法你覺得非常不對，但講清楚你的意見后，你還是得順從。在公司，不要把產品經理這頭銜太當真，惡了老板那就去坐冷板凳吧。
3）產品前期工作沒做扎實，尤其是需求分析這一步。這一點雖然坑，但對于新手產品其實是必然要踩的一個坑。對于有經驗的，也只能說盡量避免。產品與技術的矛盾很多時候就來源于此。
4）產品設計出問題。這個也挺常見，一些邏輯流程，交互設計，邊際狀況沒考慮好，或者覺得有更優(yōu)的方式。到了上線前的測試階段也會出現(xiàn)一些。這種變更就要評估改動的成本和帶來的效益了。
5）在需求確認會，開發(fā)覺得能做，隨后也估了時。然后某天，開發(fā)溜過來，
“嘿，我覺得這個需求這樣不好，用戶肯定不會這么用戶我們的產品，這樣做對用戶體驗不好”
“說人話”
“原先的方案有問題，這個需求實現(xiàn)起來會非常麻煩，需要改需求”
一番探討后，擼起膀子改需求唄。
2、需求變更的應對
1）重新分析需求
當變更的時候，不要著急改變，重新思考原有需求的思路，對比新舊需求的變化，變化原因。要對自己原有的思路有信心。對新需求一定要慎重，再慎重！如果新需求提出后再對其變更，非常損害團體的士氣，對后續(xù)的工作展開會非常麻煩。
2）更新需求文檔
按照需求流程及時更新相關內容，并在文檔注明索引，方便大家查找和后續(xù)追溯。并且根據(jù)需求變更大小，通知相應人員同步信息。這里的人員不要僅限于開發(fā)，還有測試，運營，視覺等。要做到信息的及時同步！相信我，這里有坑，淚目。
3）項目進度更新
需求變更大都會帶來項目進度的問題，在需求變更后，需要及時對其產生的進度影響做評估。
4）需求變更的復盤
這一步其實是產品自身的提高所必須的，前車之鑒后事之師。
講真，需求變更其實是產品與開發(fā)最容易產生問題的地方，盜的一張圖，大家可以引以為鑒。
七、需求怎么管理
我們收集來的需求，按照各自的版本迭代順序，會慢慢上線，但肯定有優(yōu)先級和時間前后，那應該怎么管理呢？
要做好需求的管理，需要建立需求庫和做好版本規(guī)劃。
1、需求入庫
建立好需求庫，分析好的需求按照下表進行記錄分類，優(yōu)先級，描述等，然后放入到需求庫。如果已明確對應版本，直接放入。
2、需求跟蹤
隨著項目進行及時更新項目狀態(tài)，從新建-進行中（記錄目標版本）-已解決（上線），特殊情況如關閉，重開，延期。并在上線后做好需求對應的功能上線后情況，做好數(shù)據(jù)和用戶反饋跟蹤。
產品到一定程度后，需求庫，及每個版本的需求量都是極大的，一般都是采用一些管理系統(tǒng)來管理，如redmine，禪道等。這之間的差別倒也不大，只要成員之間用的來就行。
不過需要注意，這個只是工具，充分有效的溝通才是最有用的，這里更多的是一個記錄提醒作用。
這篇文章寫了好久，在寫和查找資料的過程中也總是會冒出一些新的想法，不斷的添加修改。最后，總算覺得再改下去就不知道寫到什么時候了，而且以我的水平，也只能寫成這樣了。估計要再修煉一段時間才能站在新的高度來審視需求，這個產品經理的核心能力。
接下來應該會再寫一篇，市場分析方面的文章，現(xiàn)在還在思考和收集資料階段，估計又是痛苦的歷程~
大家有興趣也可以關注我的簡書賬號，靜默之思。里面也寫了不少產品設計方面的產品框架的文章，請大家多指教~
一些參考的文章和書籍，大家可以看下。
書籍
《產品心經》
《破繭成蝶》
《互聯(lián)網(wǎng)產品從設計到運營》
《用戶體驗設計師的成長之路》
文章
產品經理必須學會的會議管理技巧
真實案例：用KANO模型和PSM價格敏感度確定產品功能和定價
心理學之需求和動機
用戶研究的舊瓶裝新酒
產品經理：不要成為作圖經理
【聚焦產品核心能力系列】價值鏈導向的產品決策
作為產品經理，如何給用戶需求排序
你還在犯草根產品經理在犯的錯嗎？
論需求和功能：如何分析需求并設計成功能
產品新人如何開需求評審會？
從哪采集需求？這十方面就夠了
『三分法』搞定產品需求分析
PM大招：百度貼吧前負責人首爆9條心得
任督二脈的啟示錄 陋習 快速上手
*著作權歸作者所有，轉載請聯(lián)系作者獲得授權。
聯(lián)系客服
