正如我們都知道的一樣，產品需求可以來自用戶、客戶、銷售、領導，也可以來自競品、技術、以及自我反省。總之，需求來源廣泛，只要你留意觀察收集，就會發現很多很多的需求反饋，正式的、非正式的，直接的、委婉的，甚至是反饋者都不知道反饋的是自己對產品的需求。
產品的需求是產品不斷更新迭代、日趨完善的不竭動力，很多人懂，也都能說來一些。但是總是不夠全面，仿佛需求分析很大、很多，給人一個很難全面掌握了解的印象。那是因為所處的環境不同、公司性質不同、產品屬性不同，產品需求的處理與分析也大相徑庭。你不可能要求一家由產品經理兼任交互設計與用戶研究的初創型公司，像BAT一樣有團隊來做一個產品；你更不可能要求一個以技術為導向的公司能夠有一個團隊來做用戶研究。
很不幸的事，作者就是在這樣的刀山火海里面走出來的。在這樣的環境中，作者對需求的處理就沒有那么多的精雕細琢，更多的是粗暴直接的方法與技巧。
從作者的經驗來看，在小公司，或許沒有項目經理、用戶研究院、交互設計師，一個產品經理單挑一個或多個產品，直接獲取干巴巴的需求，直接與UI設計對接。
作者認為需求分析的難點在于，確定哪些需求是急迫的、在下個版本中一定要解決的，屬于A類需求，哪些是大眾的、有必要做的但是并不急在下個版本解決，屬于B類需求，又有哪些需求是“偽需求”，是由于用戶的不常規的習慣、或者特殊情況下出現的需求，屬于C類需求。只有在確定這些需求歸屬何種需求的情況下，才能在有限時間、資源的預算中有序的推進產品不斷完善。
對于一個剛入門的產品經理，在沒有經驗、底氣情況下，需求分析也是一樣，這篇文章就是對需求的提出、調研以及解決來闡述作者在解決需求分析的個人經驗，破解需求分析難點的“三板斧”。
第一板斧：數據會說話
任何一個互聯網產品都不可能給你充足的時間、人力資源讓你做一個完美的產品。在這個每一分鐘都會變化的環境中，我們都在遵循一個敏捷開發的產品節奏。需求就是我們進行開發的開始。在我們獲取大量需求的前提下，對需求進行分類整理，合并同類項，將具有相同或者相似需求整理在一起，研究同類需求的共性以及有沒有共同的解決方案，接著就是查看共性需求的比重，如果一個共性需求在收集的需求中的比重達到了50%，你說這個需求要不要做？對這一類的共性需求在需求報告中標注為高優先級。對于需求特性較為分散的差異化需求，也可以算出所在的需求比重，再拿出以往的需求分析，可以看出差異化需求是否具有低頻持續化，如果有，這個差異化的需求就是有必要做，但是不急于一時，可以在需求分析報告中標注為中優先級。如果沒有前期的數據分析積累，那么，就需要持續關注這個需求，并把當前的分析就可以作為數據積累，在后期的需求分析中用到。
另外一點，針對不能直接接觸用戶、需求的產品經理來說，網絡埋點是一個不錯的選擇。我們可以通過網絡埋點，發現對于某個頁面或者button的用戶瀏覽和點擊量，來確定問題的優先級。
第二板斧：永恒的競品分析
古語有云：知己知彼，百戰不殆。作為需求分析中一個很重要的方法，競品分析不僅僅是檢查我們所獲的需求是不是真正的需求，還是我們獲取需求、調整產品方向的重要參考。競品分析不是在我們做需求分析的時候才去做，而是時時在做，在我們做需求分析的時候，著重的去了解相似功能的模塊。比如，作者的工作經驗中，作者會每個月出一份行業競爭對手的分析報告。單份的競品分析作用可能有限，但是，連續幾個月的競品分析作用就很有用了。當我們拿著很多需求，參考競品在類似問題上是怎么解決的，不僅可以提供設計思路，有時會在技術方面也會有很多啟發。如果可以參考的競品很少，或者競品中沒有滿足類似需求的功能模塊，那么你要注意了：可能是你的想法很有預見性，是一個潛在的需求；還有另外一種可能，就是這是個坑，小心別跳下去。競品分析中有一個很重要的 至于競品分析的方法不在今天探討的層次維度，以后再談！
第三板斧：需求討論——真正的演武場
對產品經理來說需求討論會是把想法真正落地的演武場。當你拿著自己分析好的需求、制作好的Demo，在需求討論會上向項目、UI、開發、測試等闡述自己的觀點時，你不會獲得大家一致認可的結果。這個就要你去堅持，不能因為開發說一句“這個實現不了”就放棄你的想法，試著去找到替代方案，或者在開會之前就想好第二種方案，因為你的方案被大家反對不看好的概率會高達99%。
需求討論會，一般會經過三次討論：第一次是產品經理闡述需求，以及需求的緊急程度，需要Demo的要給出，保證參會的關鍵人員能夠完全明白你的意思，最好能讓他們根據自己的理解復述一下需求，使需求的傳達不會出現偏差。最后，讓相應的人員根據需求去調研相關技術方案的可行性。第二次需求討論會就是討論技術方案的可行性，以及在相應時間預算中能否保質保量的完成，從而調整這次版本迭代中要解決的需求，使確定的需求在各方面的承受范圍。最后就是各相關人員會后評估與自己相關的工作量。第三次需求討論會就是根據反饋過來的工作量，確定解決最終需求的時間點，以及每個階段的時間和確定最后的升級時間。
當然，所有的問題都不會有固定的解決方案，就像在做需求分析時這三板斧不會一板接一板的掄，可能會一起掄，有可能在做數據統計的時候競品分析也同時在做，也有可能需求討論會上你還要調整需求。但是，需求分析宗旨是不變的，就是發現需求中的真正的需求，并根據需求的優先級合理安排解決需求的時間節點和版本。
當有人質疑你的需求時，你能夠有理有據的給出解釋，除非有些人為不可抗拒的因素，你的需求分析一定能夠通過并順利實施。
敬請關注UIUX設計工作坊，微信公眾號：UIUX-HUANG，每周會有互聯網產品設計的相關文章更新，是作者的實際工作經驗，愿與大家共同進步。
