需求分析就是：觀察——篩選——判斷——迭代。這同樣是一個產品的從零到一的發展歷程，每一步都任重而道遠。
今天終於要完結了，內心還是忐忑不安的，一方面特別興奮，能夠將自己的學習與實踐經驗認真總結，並得到了同行的認同，另一方面，我擔心自己如何收場，與資深玩家相比，我深知有不小差距，不過我會嘗試通過自己的思考來幫助大家梳理。
今天的主要話題是需求管理、需求池與版本迭代。
前文說到，作為產品經理，需求分析的核心方法分別為：
這些都是十分具體而複雜多樣的，在日常工作中，我們難免遇到各式各樣的需求，第二篇文章中我也有所提及，例如：
這些都是內部或外部需求的舉例，我們第一步要做的當然是區分不同來源進而梳理需求。
一般而言，在公司所在行業，領導與同事都是對業務十分熟悉並且思考更為獨到，無論是工作溝通還是開會討論都能夠碰撞出火花。當然，他們的訴求點可能更偏向於商業利益，有時我們很難理解他們的決定，這時候就需要認真記錄並且後續深入溝通了。
這考驗產品經理甚至是整個公司的行業趨勢與動態的敏感程度，有時我們在專心按照規劃做產品時，很容易忽視其他競爭對手或是行業動態，這就需要產品經理在日常工作中多關注行業數據與動態。
行業數據可參考艾瑞諮詢、企鵝智酷、QuestMobile 等，競品調研可參考 App Annie、各大應用市場中同行業產品，從中挖掘出背後的商業與產品邏輯。
若是一味地閉門造成，後果就是，團隊想出來的靈感早就被人家鑽研並且實踐了，此外，別人不做的功能說不定早就已經被市場拋棄了。
最好的辦法就是讓團隊的每一個成員都關注其他產品的功能更新，然後再開會討論，由產品負責人統一管理。
產品面向的對象一般為大眾用戶或是企業級客戶，他們是產品的直接使用者與反饋者，通常會通過評價、投訴、分享等方式向客服反饋，我們需要特別關注。特別是早期階段的種子用戶，他們對於產品的態度能夠讓我們在第一時間了解產品功能與體驗上的問題，從而更快地迭代。
這裡，我們就不得不提及需求池這個概念了：
從名稱上我們不難看出，需求池是各方需求的集合與整理，這些需求是我們在工作中提出的想法或是問題，但是尚未實際開發或是梳理。
建立需求池的理由特別簡單：每個人都是健忘的，很多靈感或是想法當時大家興致勃勃，後續執行很容易偏離軌道，第二天再來詢問，發現自己已經全然不知需求產生的背景與解決方向。
因而，我們必須通過需求池來記錄並且尋求更深入的解決方案。
首先，我們要明白，每個團隊都有一堆待辦事項，作為產品經理，首要任務就是了解並掌握你所負責的產品，版本的演變過程以及未來迭代的方向，這一方面大公司文檔或是信息溝通可能更為完善，小公司基本上就是通過上級領導或是同事來解答，剩下的就自己體驗一遍，這樣做其實效率很低，大部分人只有在遇見具體問題時才會深入去思考。
推薦做法是向公司了解是否有項目文檔或是相關產品業務介紹與說明，然後下載最新的產品自己體驗，一方面熟悉公司業務，另一方面作為用戶體驗並發現問題，最後，通過 App Annie 等同類型的數據統計或工具來詳細了解迭代過程。
通過以上步驟，你會有較為清晰的業務輪廓，這時再與公司交流未來的版本究竟如何事半功倍。
無論是個人還是團隊，都需要通過需求池來了解想法並且適時推進。
圖片：App Annie – 極客時間
其次，我們究竟如何高效方便地管理需求池呢？
常見的需求池工具如下：
接下來，當我們採用了合適的需求池工具後，我們必須認真思考需求收集這個過程：
在這裡，我們要清楚地描述需求得到的背景與狀況，通過反饋者、受影響用戶、描述問題並且補充信息幾個方面來闡述。
客服告訴技術：今天有用戶反饋掃碼無法開門，希望你們處理下。
矛盾就很容易產生，因為缺乏必要的信息我們就無法判斷問題的起因與解決方案。
我們再來看更為專業的方式，你們感受下差異：
今天用戶 XXX，手機號碼 XXXX（反饋者）打電話給我，他昨天下午四點在南江苑的訂單無法掃碼開門，提示他伺服器異常（描述問題），他是用 IOS V3.1 版本的韻動網球 App 掃碼的（補充信息），希望你們儘快處理。
兩者相比，高下立見。
需求收集後，我們接下來需要整理需求，推薦採用流程來處理：
流程如下圖所示（圖片），思維導圖分析和四象限分析法在前兩篇文章中已經充分闡述了。
圖片：需求分析流程（ProcessOn）
那我們再來看上面的需求如何按照流程處理：
根據信息，用戶無法掃碼開門，原因為伺服器異常，這顯然是屬於重要且緊急的 Bug，並且十分重要，可能會涉及更多訂場用戶，需要立即修復，這是影響用戶體驗的巨大問題。
需求反饋也有原則需要執行：
無論是立即修復，還是無法復現，無論是接下來版本上線，還是暫無關注，我們都需要告知反饋者相應結果，並適時調整需求池內容。
綜上所述，我在結合上述思考後為公司提出的需求反饋原則如下：
向項目或產品負責人反饋問題，說清楚具體問題與反饋渠道。
統一收集需求池，將反饋分為 Bug、改進與新增，Bug 提交禪道，直接交由相關人員處理並告知反饋者結果，改進和新增則進入下一版本需求，同時調整產品開發優先級。
最後，我們要明確產品需求與版本的關係。
在我看來，版本是圍繞著產品需求來設定的，我們先要了解公司的產品線，一般會分為官網及後臺、App、微信公眾號網站、小程序、運營 H5 等幾類。
關於如何定義版本號，網際網路公司的方法多種多樣。我倒認為，方式是次要的，而核心是讓團隊輕鬆理解並且統一思想與認知，最為簡單的方式就是：
主需求我們可以採用 V1.0 來表示，例如訂場、電商、課程等都是產品的主要模塊；
若有與主需要相關的其他需求，可以採用 V1.1 的版本號，例如場館中增加視頻入口與視頻播放，
若是修復 Bug 或是改進等需要單獨跟進，可以採用 V1.01、1.02 來區分，例如最後兩片場地捆綁銷售、過了當前時間還能夠訂場等。
至於何時發版本，這需要各方（市場、產品與技術）開會討論確定，根據需求的優先級以及開發進度來控制，當然，最終確認只能視具體請可定，這裡就不展開討論了。
聊了這麼多關於需求分析的那些事，想必大家已經有了更為深入的理解與認識了。需求真的不是一件小事，通過這些思考，轉念一想，自己未來還得和它打交道，內心還是充滿期待的。
總結就是，需求分析就是：觀察——篩選——判斷——迭代。這同樣是一個產品的從零到一的發展歷程，每一步都任重而道遠。
本文最後，奉上我自己總結的產品開發流程，這是我個人對於從需求分析到產品上線整個流程的分析，我會在後續的文章中對每一部分盡力闡述與思考。同時，歡迎分享你的見解與思考。
圖片：產品開發流程（ProcessOn）
希望你能夠有所啟發。
我的產品方法論之需求分析（上）
我的產品方法論之需求分析（中）
作者：劉禎（公眾號「聽天由己」），現在網際網路體育領域創業，擔任產品經理。
本文由 @劉禎 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖由作者提供