我的產品方法論之需求分析
需求分析的文章很多，但這篇還是值得你一讀。為什麼呢？讀了你就知道。
1
最近我一直在思考一個問題：我們天天在講需求，到底什麼纔是需求？
作為互聯網人，這個名詞我們已經早已司空見慣，但卻很少有人去仔細琢磨這個概念。我們總是習慣性地認為，需求無非就是用戶對產品的反饋與建議，就是老闆提出的商業訴求，就是運營人員減少工作麻煩的想法。
然而，在經歷了大量工作實踐與產品學習之後，我發現自己對於需求的定義十分模糊，完全無法自圓其說，按照費曼技巧來看，從開頭上我就已經頭腦混亂了，如何把新學的知識用自己的語言說給別人聽，達到深入學習的目的纔是我繼續解決的問題。
因而，我開始有意識地打磨自己的產品方法論，理解需求這個概念至關重要。
首先，捫心自問，我們為什麼要用各種產品？
在我看來，產品無非能夠幫助我們實現以下兩個方面的目的：
其一，產品能夠解決我們在工作、生活、學習等具體場景中遇到的問題。
有道詞典解決了我們在閱讀時遇見生詞的尷尬，並且從聽說讀寫各個角度鞏固這個單詞的實際運用；MindNode 或是 Xmind 等各類思維導圖工具解決了我們在制定計劃或是分析問題時思路不清的困惑。
其二，產品滿足了我們在生理或者心理上的慾望與內心渴望。
探探滿足了單身青年尋求視覺衝擊與戀愛交往的需要；
微信朋友圈滿足了熟人交流與炫耀人生的需要。
從這些產品中我們不難得出，一個產品的終極目標就是為了滿足更多人的「需要」。
2
看到這裡，有人不禁要問：為什麼你用「需要」而不是「需求」？這裡有必要將兩個概念完全理順。
我們先從需求的定義開始分析：
從經濟學角度來看，經濟學中需求是在一定的時期，在每個價格水平下，消費者願意並且能夠購買的商品數量。
互聯網產品大多數都為虛擬產品服務，運用經濟學分析當然無可厚非，但是這必然與我們日常工作中遇見的需求南轅北轍。於是乎，我們需要進一步去探究。
從心理學角度來看，需求是人們為瞭解決實際問題或是滿足自身慾望的具體訴求。
如此一來，需求的定義就要清晰許多。
換種說法，將經濟學與心理學的定義結合來看，需求是指人們在慾望驅動下的一種有條件的、可行的，又是最優的選擇，這種選擇使慾望達到有限的最大滿足，即人們總是選擇能負擔的最佳物品。
由此可見，「需求」絕對不等於「需要」。
根據百度百科的定義：
需要，是有機體感到某種「缺乏」而力求獲得滿足的心理傾向，是內外環境的客觀要求在頭腦中的反應。它源於自然性要求和社會性要求，表現為物質需要和精神需要。需要常以一種「缺乏感」體現，以意向、願望的形式變現出來，最終發展為推動人進行活動的動機。
需要總是指向某種東西、條件或活動的結果等，具有周期性，並隨著滿足需要的具體內容和方式的改變而不斷變化和發展。
從上述定義來看，需要是內在的客觀訴求，而需求則是外在的主觀要求，而且需求比需要的層次更高，其中有兩個關鍵因素，一是支付能力，二是意願水平。
舉個例子，大家就能夠明白兩者的差別了：
- 需要：我需要能夠在社交平臺上展現自己，將自己的寫作公開，並不斷督促自己成長與反思，結合更多志同道合的朋友。
- 需求：我想要開通微信公眾號與簡書兩個平臺賬號，並且加入 007 行動與大家共同成長。我願意支付了一定的時間和金錢成本來獲取社交與溝通需要。
簡而言之，
- 需要，是解決問題或者滿足慾望，它是我們最終目的。
- 需求，是需要付出一定成本來滿足，具體表現為解決方案中的具體產品或是功能。
因而，我們熟知的馬斯洛理論其實應當馬斯洛需要理論，它將需要分成生理需要（Physiological needs）、安全需要（Safety needs）、愛和歸屬感（Love and belonging）、尊重（Esteem）和自我實現（Self-actualization）五類，依次由較低層次到較高層次排列。
當然，馬斯洛需要理論過於宏大，我們需要更為精準且有效的分析模型。在我看來，對於互聯網產品來說，一般有以下十種需要，而我們在一款產品中經常能夠發現它其實滿足了多種需要，不同功能旨在提供不同的用戶體驗：
- 工具需要：蝸牛睡眠、隨手記
- 社交需要：微信、QQ
- 溝通需要：釘釘、Worktile
- 娛樂需要：熊貓直播、王者榮耀
- 購物需要：淘寶、京東
- 信息獲取需要：即刻、Readhub
- 展示需要：臉萌、足記
- 學習需要：得到、微信讀書
- 人性需要：探探、陌陌
- 終端需要：支付寶、有贊
大家有空可將手機上的下載應用稍加分析便可略知一二。
3
理解需求的內涵後，下面我們便能更好地開展需求挖掘與分析工作了。
在初入職場時，我尚未建立起自己的分析邏輯與框架，總是會不假思索地增加與改變原有的架構與功能模塊，如此做法很容易導致後續功能或是資料庫變動，因而影響產品上線與項目進度。最可怕的就是推翻重來，之前的努力都付諸東流。
在接觸更多優秀的產品學習與分析案例之後，我愈發認為，打造自己的思維模式與分析框架是多麼重要，一方面簡化流程，培養產品感覺，另一方面總結經驗，不斷迭代。
我將自己的需求分析方法論分為三個階段：
- 首先，面對單個需求，我們如何分析它是否合理？它是否滿足了用戶在特定場景下的需要？它是否解決了用戶在使用產品中遇到的問題？
- 其次，面對海量需求，我們如何進行優先順序排序？是否制定明確的產品設計原則？
- 最後，我們如何對需求進行管理？如何將需求收集到需求池中？如何進行版本迭代管理？
本篇文章將闡述第一階段的需求分析方法論。
4
當老闆、運營或是客服人員提出了新需求，我們在產品設計中首先要做的就是明確兩個原則：
- 產品設計，就是不斷解決用戶在特定場景下的需求。
- 增加、減少功能並非關鍵，關鍵能不能解決用戶問題。
上線一個月的 CUATA 小程序，高校管理者一直希望能夠通過小程序來尋找校友，並且聊天溝通，這是他們的社交需要，否則用戶處於封閉狀態，他們很可能在註冊後便再也不登錄，如此不可避免地造成用戶流失。
從高校管理者與用戶角度而言，這的確十分關鍵，但是，微信小程序的核心定位是打造連接線上線下的工具，激活線下場景，社交本身不適用於小程序場景，直接利用微信便可以完成。因而，基於上述社交需要，我們提出的方案就是提供用戶註冊後的服務通知推送，告知高校管理員聯繫方式，可私下建羣溝通，並且管理員亦可收到類似通知，雙方都有動機去添加對方，從而實現流程上的閉合。
接下來進入主題，面對單個需求，我們如何分析它是否滿足了用戶在特定場景下的需要？是否真正地解決了問題？
我的思考方式如下：
首先，考慮用戶，用戶是一切產品的核心所在。
當想到一個功能或是需求，先考慮誰會用？潛在用戶有哪些？我們要從用戶角度去思考這一功能對他們的影響，因為最終是用戶使用產品，從最發散的方式去逐一驗證或者推翻。
列出所有可能感興趣的用戶（請注意，這裡的用戶不單單是消費者，而是指所有對這一功能感興趣的人，可能包括 CEO、運營人員或是第三方等）。
對於紅包或優惠券這一需求，用戶自然願意享受價格優惠，運營人員則提升用戶規模與產品轉化率，CEO 希望用一段時期內的補貼刺激用戶在不同場景下分享或是轉發。
其次，分析場景，在移動互聯網時代，場景感是最重要的因素。
我們要考慮這些用戶分別在什麼情況下使用（感興趣）？
我們再列出用戶發生（感興趣）的場景，先對場景進行假設，然後再實地驗證對場景的描述，因為場景不同，問題和需求自然不同。
我們可針對每一類用戶往下分解，把具體情況描述清楚。
運營人員希望擴大用戶註冊人數與各類產品指標，在公眾號圖文消息營銷活動，給予參與用戶一定的獎勵。
再次，考慮問題，用戶分別在上述場景下碰到什麼問題。
問題不是解決方案，問題也不要怕重複，可以採用多個為什麼來探究背後的真實動機與想法，多數問題最終都與情感需求有關。
運營人員在進行營銷活動是受制於技術水平，發放獎勵給相應用戶十分麻煩。
最後，考慮解決方案：用戶現在的解決方案是什麼？
運營人員目前需要通過後臺系統來實現訂場後退款或者添加用戶微信號來聯繫用戶領取獎勵。
通過上述的思考方式後，相信大家已經有初步的結論與邏輯了，此時我們再利用 MindNode 或是 Xmind 就能夠完整地梳理剛才的思考過程。
下圖是關於美團外賣增加上傳短視頻功能的思考，僅供說明參考。
以上就是我的需求分析方法論第一步——利用思維導圖梳理需求。挖掘單個需求同樣能鍛煉自己的邏輯思維與產品分析能力。
總而言之，作為產品經理，我們在遇見需求時，首先要分析用戶、場景、問題以及現有解決方案，利用思維導圖將思考過程完整記錄並梳理，從中篩選並提煉出最有價值的信息與開發方向。
恭喜你已經學慣用戶思維的第一步，接下來便是如何從海量需求中確定需求優先順序以及開發原則，我會在下文中深入闡述我的需求排序原則以及對於公司發展的思考。
首先，我們先回顧需要與需求的的定義：
需要，是解決問題或者滿足慾望，它是我們最終目的。
需求，是需要付出一定成本來滿足，具體表現為解決方案中的具體產品或是功能。
在上文發出後，我總是想著能否用更為簡潔的類比方式來描述兩者的關係，直到看到老黃的那篇《身為互聯網人，看不懂用戶行為該怎麼辦》，裡面提出了以下觀點：
A 類需求往往與用戶的外在環境和特定的行為表象有關，通常會因為環境、工具、用戶習慣等外部條件的變化而週期性發生變化。典型比如人們在特定場景下的話語體系和交流方式（如各類層出不窮的花式表情包、「皮皮蝦我們走」、「打call」），新的娛樂和消磨時間的方式（如抖音、狼人殺），最近又新近流行了哪些好喫的等等。
B 類需求則往往是面向內在的，它往往與用戶的心理和內在情緒相關，相比起 A 類需求來說，它會更加恆定持久，鮮少會因為時代、環境的變化而發生變化。
我並非想去爭執，這兩類需求說到底就是需要與需求，概念模糊才會讓我們在解決實際問題是捉襟見肘，每個人都有一套自己的理論卻很難說服對方。
看罷文章，我突然想到了如何向他人講解兩者的好辦法，需要與需求其實就是矛盾的共性與個性。
矛盾的共性指矛盾的普遍性，是絕對的、無條件的；
矛盾的個性指矛盾的特殊性，是相對的、有條件的。 矛盾共性與個性的辯證關係是指，共性寓於個性之中，個性又受共性的制約，共性和個性在一定條件下相互轉化。
這一段在高中政治學習的哲學辯證法代表了世間萬物的發展規律與本質。將這一觀點運用到需求分析中特別有效，我就像發現了新大陸那般興奮，如此一來，對於產品工作者而言，我們只需要運用這一關係就能夠挖掘出用戶行為及其產生的環境本後的種種本質。
我們可以升華對於需求分析的理解與認知：
需求可能是用戶一時的喜好與解決方案。需要可能是對於「用戶在遭遇經受何種場景何種衝擊後一定會得到或產生某些特定體驗和感受」有了更加深刻和普世的理解。
2
在《我的產品方法論之需求分析（上）》中，我將自己的需求分析方法論分為三個階段，第一階段我的做法是：
我們在遇見需求時，首先要分析用戶、場景、問題以及現有解決方案，利用思維導圖將思考過程完整記錄並梳理，更要深層地理解用戶需要，圍繞核心的用戶體驗與感受，從中篩選並提煉出最有價值的信息與開發方向。
拋開單個需求分析框架，我們在工作中不免碰到太多需求，很多時候，若是處理不當，很容易打亂我們的日常計劃：
- 今天 ，CEO 提出了新的商業訴求，我們要在內容付費上花功夫，看看能否結合具體業務場景實踐；
- 明天，市場部談了新合作協議，我們的管理平臺需要對場館方與教練開放，並且設置不同的管理許可權；
- 後天，IOS 與 Android 版本的啟動頁長時間未更新，用戶反饋太單調了，未能突出平臺與產品價值。
上述這些案例只是我們需求的九牛一毛而已，對於需求提出者而言，這些都很緊急，我們必須儘快安排開發，否則會影響後續商業洽談。
然而，我們需要明白，一個公司的產品路線圖是需要清晰明確的規劃與執行的，「任何需求都可以完成，只是需要時間」，因而，我們需要認真地制定評估原則，原則是我們為人處世的標準。我們常說的優先順序排序就是為了確定現階段的任務以及我們為何要開發。
在總結了個人學習與公司發展後，我將需求優先順序排序分為以下三個維度：
2.1 用戶量與發生頻率
用戶量是指這個需求或問題是影響小部分用戶還是所有用戶。
發生頻率是指這個需求或問題是每次都出現還是偶爾出現。
我們要優先解決大用戶量的高頻問題，這是保證產品的基礎體驗，也是保證用戶口碑的關鍵所在，若是基礎體驗都無法滿足，何來產品價值與用戶自發推廣？
例如，App 手機登錄簡訊驗證碼收不到；場館地圖無法獲取；支付頁面報錯。
最後解決小用戶量的低頻問題，這是超出預期的用戶體驗。
例如，Kindle 的全文搜索；網購書籍贈書籤。
2.2 開發難度與實踐效果
開發難度是指問題解決或是功能實現的技術要求、人員數量以及開發時間。
實踐效果是指問題解決或是功能實現的用戶體驗、操作效率以及實踐效果。
我們要優先做難度不大、效果明顯的事情，這就是常說的產品迭代，早期更是如此，我們推出產品後最好圍繞核心功能進行完善。
例如，ofo 小黃車的低成本投放與快速複製；微信的社交聊天與好友。
然後做難度大、效果不明顯的事情，這可能是未來的機會。
例如，摩拜單車智能鎖與科研技術投入；得到 App 的《每天聽本書》年卡體系。
2.3 產品價值
按照俞軍的說法：
產品的用戶價值 = （新體驗 – 舊體驗）- 換用成本
產品的商業價值 = 用戶意願支付價格 – 產品成本
因而，看一個產品的價值可以從用戶需求的緊迫性以及用戶對產品的付費意願。
例如，去年的直播行業與內容付費行業風生水起，從用戶價值來看，直播帶來的新體驗要遠遠超出原來一個人的孤獨感，而且隨著移動支付的便捷，人們對於付費閱讀或是打賞等已經有了更深的認知，這也可以認為是舊時代的粉絲經濟的現代版本。因而，我們就不難解釋為什麼很多產品跟風上了直播或是付費問答等功能。
總而言之，我們能夠得出以下幾個結論：
（1）需求優先順序的定義要基於當時的環境和實際情況，需求分析最關鍵是回到用戶、場景、問題上來，因為用戶需求是一個動態變化的過程，需要適時調整。
產品起步階段的重點是核心功能的實現，驗證產品的可行性。產品的發展階段重點是功能的擴展和完善，需要做的是探索新的價值。產品的迭代階段重點是用戶體驗的提升。
（2）產品與運營不分家，在確保滿足基本需求時，也要適當考慮滿足用戶期望和興奮型需求。
這其實就是 KANO 模型中的三種需求：基本型需求、期望型需求、興奮型需求。三種需求的重要性程度當然是基本型需求優先，期望型與興奮型需求次之。
因而，在產品開發與運營過程中，我們需要動態調整或是轉換當前階段的重點，上述的三個維度就是衡量優先順序的標準之一，最終將劃分出來的需求進行對比與討論。
3
下面我就用實際案例來拆解並運用上述需求優先順序排序原則。
我們從 QQ 第一版上線的優先順序來分析，面對以下12個需求的思考方式為：
- 卡通頭像；
- 不可竊聽安全通訊；
- 聊天室；
- 很小的 exe 程序；
- 皮膚；
- 速度超快 0.5 秒反應；
- 聊天記錄管理器；
- 語音；
- 視頻；
- 看誰在線上；
- 傳文件；
- QQ 表情。
首先，從用戶量與發生頻率來看，
QQ 的核心功能是即時聊天，在當時的網路技術與時代背景下，與聊天相關的元素就顯得異常重要，可能會涉及到大範圍用戶，利用四象限分析法，卡通頭像、聊天室、很小的 exe 程序以及看誰在線上對用戶來說是非常重要的基礎功能，無論是私聊、羣聊還是用戶狀態顯示，都是為了提升在線聊天用戶的溝通與交流體驗，而語音、視頻或是文件傳輸僅適用於特定人羣，例如商務往來、家人溝通等場景，優先順序當然排後。
其次，從開發難度與實施效果來看，卡通頭像、聊天室與看誰在線上這三個需求開發難度相對較低，且容易被用戶察覺並迅速傳播。其他的需求依次劃分在其他象限上。
最後，從產品價值來看，聊天室、看誰在線上、超快反應可能是當時用戶較為迫切的需求，從付費意願來看，皮膚、QQ 表情都是後期用戶為了炫耀並展現個性的絕佳方式，每天龐大的用戶量使得騰訊在當時的玩法十分多樣，站在用戶角度，我是願意為了皮膚或是表情付費，想當年 QQ 的個性皮膚與各類增值服務可是風靡全國。
綜上所述，1、3、5、10 是較為合理的需求優先順序排序，當然，這只是我們簡單地分析與思考，事實情況與業務數據我們並無更多信息。
這只是我的個人經驗與總結，大家可對照自己公司的產品需求運用這三個維度來思考並完善。
4
以上就是我的需求分析方法論第二步——利用四象限分析法來進行優先順序排序。
作為產品經理，我們在遇見海量需求時，要明確需求優先順序排序原則，逐一運用四象限分析法來判斷，然後再結合公司產品發展階段與具體場景來思考。
恭喜你已經學慣用戶思維的第二步，接下來便是如何對需求與需求池進行管理以及如何進行版本迭代，我會在最後一篇文章中繼續闡述我的實踐經驗與思考。
需求分析就是：觀察——篩選——判斷——迭代。這同樣是一個產品的從零到一的發展歷程，每一步都任重而道遠。
今天終於要完結了，內心還是忐忑不安的，一方面特別興奮，能夠將自己的學習與實踐經驗認真總結，並得到了同行的認同，另一方面，我擔心自己如何收場，與資深玩家相比，我深知有不小差距，不過我會嘗試通過自己的思考來幫助大家梳理。
2
今天的主要話題是需求管理、需求池與版本迭代。
前文說到，作為產品經理，需求分析的核心方法分別為：
- 在遇見單個需求時，首先要分析用戶、場景、問題以及現有解決方案，利用思維導圖將思考過程完整記錄並梳理，從中篩選並提煉出最有價值的信息與開發方向。
- 在遇見海量需求時，要明確需求優先順序排序原則，逐一運用四象限分析法來判斷，然後再結合公司產品發展階段與具體場景來思考。
這些都是十分具體而複雜多樣的，在日常工作中，我們難免遇到各式各樣的需求，第二篇文章中我也有所提及，例如：
- 場館需要增加視頻入口，從而擴大現場曝光，突出智慧場館優勢，進而做到線上線下雙重結合；
- 電商模塊需要在訪問量較大的頁面上增加彈窗或是提示，以此結合具體場景來實現銷售轉化；
- 新賽事系統上線後，領隊反饋需要了解賽事進程，修改比分或是撤銷比賽，給予賽事管理者較大的靈活性。
這些都是內部或外部需求的舉例，我們第一步要做的當然是區分不同來源進而梳理需求。
1. 領導、同事
一般而言，在公司所在行業，領導與同事都是對業務十分熟悉並且思考更為獨到，無論是工作溝通還是開會討論都能夠碰撞出火花。
當然，他們的訴求點可能更偏向於商業利益，有時我們很難理解他們的決定，這時候就需要認真記錄並且後續深入溝通了。
2. 行業調研與競品挖掘
這考驗產品經理甚至是整個公司的行業趨勢與動態的敏感程度，有時我們在專心按照規劃做產品時，很容易忽視其他競爭對手或是行業動態，這就需要產品經理在日常工作中多關注行業數據與動態。
行業數據可參考艾瑞諮詢、企鵝智酷、QuestMobile 等，競品調研可參考 App Annie、各大應用市場中同行業產品，從中挖掘出背後的商業與產品邏輯。
若是一味地閉門造成，後果就是，團隊想出來的靈感早就被人家鑽研並且實踐了，此外，別人不做的功能說不定早就已經被市場拋棄了。
最好的辦法就是讓團隊的每一個成員都關注其他產品的功能更新，然後再開會討論，由產品負責人統一管理。
3. 用戶、客戶反饋
產品面向的對象一般為大眾用戶或是企業級客戶，他們是產品的直接使用者與反饋者，通常會通過評價、投訴、分享等方式向客服反饋，我們需要特別關注。
特別是早期階段的種子用戶，他們對於產品的態度能夠讓我們在第一時間瞭解產品功能與體驗上的問題，從而更快地迭代。
3
這裡，我們就不得不提及需求池這個概念了：
從名稱上我們不難看出，需求池是各方需求的集合與整理，這些需求是我們在工作中提出的想法或是問題，但是尚未實際開發或是梳理。
建立需求池的理由特別簡單：每個人都是健忘的，很多靈感或是想法當時大家興緻勃勃，後續執行很容易偏離軌道，第二天再來詢問，發現自己已經全然不知需求產生的背景與解決方向。
因而，我們必須通過需求池來記錄並且尋求更深入的解決方案。
首先，我們要明白，每個團隊都有一堆待辦事項，作為產品經理，首要任務就是了解並掌握你所負責的產品，版本的演變過程以及未來迭代的方向，這一方面大公司文檔或是信息溝通可能更為完善，小公司基本上就是通過上級領導或是同事來解答，剩下的就自己體驗一遍，這樣做其實效率很低，大部分人只有在遇見具體問題時才會深入去思考。
推薦做法是向公司瞭解是否有項目文檔或是相關產品業務介紹與說明，然後下載最新的產品自己體驗，一方面熟悉公司業務，另一方面作為用戶體驗並發現問題，最後，通過 App Annie 等同類型的數據統計或工具來詳細瞭解迭代過程。
通過以上步驟，你會有較為清晰的業務輪廓，這時再與公司交流未來的版本究竟如何事半功倍。
無論是個人還是團隊，都需要通過需求池來瞭解想法並且適時推進。
其次，我們究竟如何高效方便地管理需求池呢？
常見的需求池工具如下：
- Excel：個人特別合適，每天的溝通與交流都有明確的指向與展示，然而對於團隊而言，十分麻煩，即便有同步工具，還是很難處理並且無法瞭解動態。
- Worktile：個人與團隊皆有，個人版側重於任務管理與資料記錄，企業版關注內部管理與信息同步，這是我個人一直在使用的工具，同時與 Excel 相結合。
- Teamabition/Tower：團隊特別合適，這是項目管理與團隊信息同步的工具，若是要採用，必須要求團隊統一思想，一起使用，否則毫無意義。
- Trello/JIRA：它們都是國外公司所開發，功能強大，但受限於互聯網政策，採用的公司不多。
- 禪道：這是一款適合團隊的應用工具，專註研發項目管理，支持敏捷開發過程。目前公司就是採用這款工具，優點是所有模塊清晰準確，缺點是無法即時同步信息。
4
接下來，當我們採用了合適的需求池工具後，我們必須認真思考需求收集這個過程：
需求收集
在這裡，我們要清楚地描述需求得到的背景與狀況，通過反饋者、受影響用戶、描述問題並且補充信息幾個方面來闡述。
客服告訴技術：今天有用戶反饋掃碼無法開門，希望你們處理下。
矛盾就很容易產生，因為缺乏必要的信息我們就無法判斷問題的起因與解決方案。
我們再來看更為專業的方式，你們感受下差異：
今天用戶 XXX，手機號碼 XXXX（反饋者）打電話給我，他昨天下午四點在南江苑的訂單無法掃碼開門，提示他伺服器異常（描述問題），他是用 IOS V3.1 版本的韻動網球 App 掃碼的（補充信息），希望你們儘快處理。
兩者相比，高下立見。
需求整理
需求收集後，我們接下來需要整理需求，推薦採用流程來處理：
- 第一步，判斷這個問題是屬於 Bug、改進還是全新需求？
- 第二步：這個需求是有效的還是無效的？
- 第三步：我們是否要做？我們如何做？
流程如下圖所示（圖片），思維導圖分析和四象限分析法在前兩篇文章中已經充分闡述了。
那我們再來看上面的需求如何按照流程處理：
根據信息，用戶無法掃碼開門，原因為伺服器異常，這顯然是屬於重要且緊急的 Bug，並且十分重要，可能會涉及更多訂場用戶，需要立即修復，這是影響用戶體驗的巨大問題。
需求反饋
需求反饋也有原則需要執行：
- 盡量當下反饋結果；
- 盡量真實反饋結果；
- 進入需求池後，盡量有行動計劃。
無論是立即修復，還是無法復現，無論是接下來版本上線，還是暫無關注，我們都需要告知反饋者相應結果，並適時調整需求池內容。
綜上所述，我在結合上述思考後為公司提出的需求反饋原則如下：
向項目或產品負責人反饋問題，說清楚具體問題與反饋渠道。
統一收集需求池，將反饋分為 Bug、改進與新增，Bug 提交禪道，直接交由相關人員處理並告知反饋者結果，改進和新增則進入下一版本需求，同時調整產品開發優先順序。
5
最後，我們要明確產品需求與版本的關係。
在我看來，版本是圍繞著產品需求來設定的，我們先要了解公司的產品線，一般會分為官網及後臺、App、微信公眾號網站、小程序、運營 H5 等幾類。
關於如何定義版本號，互聯網公司的方法多種多樣。我倒認為，方式是次要的，而核心是讓團隊輕鬆理解並且統一思想與認知，最為簡單的方式就是：
主需求我們可以採用 V1.0 來表示，例如訂場、電商、課程等都是產品的主要模塊；
若有與主需要相關的其他需求，可以採用 V1.1 的版本號，例如場館中增加視頻入口與視頻播放，若是修復 Bug 或是改進等需要單獨跟進，可以採用 V1.01、1.02 來區分，例如最後兩片場地捆綁銷售、過了當前時間還能夠訂場等。
至於何時發版本，這需要各方（市場、產品與技術）開會討論確定，根據需求的優先順序以及開發進度來控制，當然，最終確認只能視具體請可定，這裡就不展開討論了。
6
聊了這麼多關於需求分析的那些事，想必大家已經有了更為深入的理解與認識了。需求真的不是一件小事，通過這些思考，轉念一想，自己未來還得和它打交道，內心還是充滿期待的。
總結就是，需求分析就是：觀察——篩選——判斷——迭代。這同樣是一個產品的從零到一的發展歷程，每一步都任重而道遠。
本文最後，奉上我自己總結的產品開發流程，這是我個人對於從需求分析到產品上線整個流程的分析，我會在後續的文章中對每一部分儘力闡述與思考。同時，歡迎分享你的見解與思考。
希望你能夠有所啟發。
作者：劉禎（公眾號「聽天由己」），現在互聯網體育領域創業，擔任產品經理。
本文由 @劉禎 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖由作者提供
原文鏈接：我的產品方法論之需求分析（上） | 人人都是產品經理
我的產品方法論之需求分析（中） | 人人都是產品經理
我的產品方法論之需求分析（下） | 人人都是產品經理
推薦閱讀：
