什么是需求

大家都在講需求分析，但是什么是需求，軟件工程中提供了一系列復雜的解釋。我所理解的需求就是，用戶用的不爽、不舒服、不合適的，我們就要去解決這樣的問題。不管在產(chǎn)品的任何階段，把用戶放在首位，是否滿足了用戶需求，要么解決了痛點，要么帶來快感，這才是必要的需求。

需求獲取

需求獲取有多種途徑：用戶訪談、調(diào)研問卷、其他渠道的反饋

用戶訪談：通過6-8個（針對一個或者一段時間的產(chǎn)品迭代）用戶訪談，定性了解用戶的使用情況，最好的訪談形式，是在用戶所熟悉的場景中，還原使用產(chǎn)品的整個過程；不過這樣的成本確實蠻高，邀請一個用戶需要耗費大量的時間和金錢；所以一般都是邀請用戶到公司參加測試、或者直接電話訪談的形式。

O2O的用戶除了日常使用者之外，背后還有忽視掉的商戶，而商戶端的用戶情況非常復雜，包含：服務員、前臺、迎賓、收銀、市場經(jīng)理、店長、老板、連鎖店老板、甚至公關營銷和法務，所以針對商戶端的用戶訪談，電話是不合理的，除了跑到店里體驗服務外，就是跟以上角色一對一聊，才會獲取到一線的需求，以及產(chǎn)品的評價（這一系列文章里面，考慮到專門有一篇，就是寫用戶訪談，一半重點會放在商戶側(cè)）。

調(diào)研問卷：訪談是定性的了解，那調(diào)研問卷就是定量的研究，針對訪談中出現(xiàn)的問題，通過調(diào)研問卷的方式，從更大規(guī)模的用戶來論證，并根據(jù)調(diào)研問卷結(jié)果，將需求做優(yōu)先級處理。有時候調(diào)研問卷不只是為了論證需求的存在，同樣可以論證需求是否合理。

但是你如果直接問用戶，如果我增加一個功能，你需要么？大部分用戶回答都是需要（不管是訪談還是問卷），所以需要通過引導式的內(nèi)容，或者問卷中，開放式的問題，來收集并論證新功能的必要性。如果真的是用戶急需，肯定會有用戶強烈提出（這部分天使用戶需要好好珍惜）。

其他渠道的反饋：很多渠道的反饋，吐槽也好，表揚也罷，都說明天使用戶對你產(chǎn)品的關心；除了產(chǎn)品自身的反饋渠道之外，還有論壇、圍脖、知乎等等第三方網(wǎng)站；另外媒體渠道，現(xiàn)在的36kr等、可以看到競品的報道，可以嘗試分析下報道背后的原因，以及對自己報道后，各界對自己產(chǎn)品的反饋?，F(xiàn)在不只是PM會關注圍脖神馬的，連各個公司大佬們都會積極去關注。

需求分析

通過種種方式，需求收集回來了，整理整理，to do list里面少則十幾條，多則上百條；當然了調(diào)研問卷會幫你篩選出一批，可是剩下的部分，怎么去論證需求的合理性、必要性、甚至是否為無理需求呢，從實踐以及跟前輩交流中，總結(jié)了以下三種方式：

用戶怎么說：用戶永遠是對的；這句話對，也不對。用戶會告訴你想要什么，但是用戶不會告訴你他的需求是什么；所以需要從用戶那挖掘需求。
饅頭和海底撈的例子，小明說晚上我們?nèi)コ院５讚瓢?，為什么呢？因為他餓了，其實他的本質(zhì)需求是餓了，給他兩饅頭，可能會不爽，但是絕對解決了小明的需求；同樣的，老板說我請大家吃飯吧，讓你安排，你安排饅頭，會被所有人K死吧，相反，這時候海底撈就是個不錯的選擇
所有用戶怎么說，只是描述用戶的行為，使用習慣，以及所要的預期結(jié)果；真正如何去滿足用戶的這個預期結(jié)果，就是PM需要從用戶深挖出需求，然后通過產(chǎn)品方式去解決。

數(shù)據(jù)：一切以數(shù)據(jù)說話，這是產(chǎn)品的準則，雖然數(shù)據(jù)有時候會騙人，也有很多為了數(shù)據(jù)好看故意掩蓋的行為。但是真實可靠的數(shù)據(jù)，確實是能為產(chǎn)品增色，給用戶帶來方便。

舉個例子：在做App的時候，第一版本是拍腦袋，根據(jù)競品分析和自己判斷，顯示神馬內(nèi)容；上線一個月之后再進行優(yōu)化，我就選取了大部分用戶使用的幾個場景和動作，分別做了匹配；交上去被罵了一頓（略夸張，不過自信心還是被打擊到了），肯定有更好的方式來實現(xiàn)。我就靜心仔細思考，用戶在使用時，每天在不同時間段，他的動作和目標是不一樣的，所以我將每天以小時分段，看每個時間段，用戶都進行神馬操作，發(fā)現(xiàn)在每個時間段中，60%甚至更高的用戶都是一樣的目標和操作；

所以就簡單了，將24個小時前后有類似操作的時間段做個區(qū)分，用戶在這個時間段打開App看到的內(nèi)容，就是大部分人所操作的，可能影響小部分人，但是方便了更多的用戶，畢竟產(chǎn)品永遠是為大部分人去準備的。

競爭對手怎么做：有一句話說得好，我們不需要重復造輪子；圓是上天賜予我們的禮物，前輩們的產(chǎn)品和設計，也是他們賜予我們后輩的財富。在競品分析的時候，就可以留意別人好的設計；可能有人會覺得不恥，不就是抄襲么？對的，世間那么多產(chǎn)品，對個功能的設計，你能抄襲或者借鑒到，至少說明一你有用心留意并觀察別人的產(chǎn)品；二別人的產(chǎn)品至少被用戶接受了；三他已經(jīng)慢慢幫你培養(yǎng)了用戶的使用習慣；四直接證明此需求存在。模仿是一種很穩(wěn)妥的方式，畢竟世間就只有一個喬布斯；此外在模仿中升華，做出更完美的產(chǎn)品，豈不是更好。

當然了，不能盲目的去跟風，別人有，我也要有的思路是不對的。這里所講的，是你通過別人的產(chǎn)品去論證需求，別人成功的產(chǎn)品，去實現(xiàn)你的需求。產(chǎn)品做加法一點都不難，難的是做減法，如果能在別人成功的產(chǎn)品上做減法，那還是需要嚴密的論證以及大膽的嘗試。

對需求做決策

論證了需求的存在，以及必要性，下面就是對需求的優(yōu)先級交付開發(fā)，有些需求，因為優(yōu)先級低，可能永遠處于被砍掉的部分，或者一直呆在to do list直至天荒地老。

需求優(yōu)先級：

需求永遠是做不完的，而研發(fā)資源永遠是不夠的，怎么辦？所以PM需要對所有需求的優(yōu)先級進行分類，研發(fā)按照需求優(yōu)先級列表，一個個進入開發(fā)隊列。如何劃分優(yōu)先級：MVP（最小化可用產(chǎn)品），快速迭代，迅速論證需求及產(chǎn)品的合理性。當每個需求出現(xiàn)在列表中時，不停的問，這個需求有必要么？有必要優(yōu)先級這么高么？不做用戶會不會發(fā)狂？不做產(chǎn)品是不是能run？不做是否不通過產(chǎn)品線下也有解決方案，成本和線上比怎么樣？經(jīng)過這一系列論證，某些是必須要做，而且立馬要做；有些是必須要做，但是并沒有那么緊急；有些甚至是必要，但是卻不是當前階段需要的。少即是多，所有功能的累加并不難；難的是只提供用戶核心的功能和產(chǎn)品，并讓用不離不開他，再在這樣的功能上，輕松調(diào)整和擴展產(chǎn)品。

那些被砍掉的需求：

從參與工作的第一個月，就整理了一個feature list，都是大家腦暴，或者研究競品給產(chǎn)品未來做的規(guī)劃，現(xiàn)在回頭來看，里面所描述的功能，絕大部分都沒有去做。一方面的原因是產(chǎn)品還很小，沒必要大而全；另一方面部分功能，完全拍腦袋決定，根本沒有必要在產(chǎn)品中增加。

feature list是產(chǎn)品規(guī)劃方面的需求，具體執(zhí)行層面，每次需求評審，會故意放進很多需求；老板可以砍，技術可以砍，QA可以砍；需求多研發(fā)肯定會叫，象征性地砍掉不需要的需求，適當?shù)陌巡糠中枨笱悠?，只要保證你所要的核心需求，在這次迭代完成就好了，畢竟已經(jīng)砍了一部分需求，不好意思一直砍。具體怎么交付技術需求，跟技術溝通會專門再寫一篇。

交互視覺和重構(gòu)
讓專業(yè)的人做專業(yè)的事情，雖說PM應該是個70%的交互設計師，但是公司既然有了交互設計師，那交互的工作就十分信任地讓他們?nèi)プ觯籔M做的只是跟交互設計師描述清楚用戶使用場景。當然作為新人，我經(jīng)常犯的錯誤就是，我這里需要加XX功能，而不是我要解決XX問題。視覺重構(gòu)同理，PM就是要利用好這些資源，并充分地信任他們。

關注用戶體驗：產(chǎn)品要么給用戶帶來利益，要么方便用戶使用；脫離了這兩點的產(chǎn)品都是耍流氓。若一款產(chǎn)品既給用戶帶來利益又有非凡的體驗，才是最成功的。用戶體驗為啥重要，因為體驗會影響用戶口碑，口碑影響產(chǎn)品成敗，產(chǎn)品成敗決定一切。用戶體驗包含用戶所看到的一切元素，以及交互過程，除了顯性的特性外，體驗上隱性傳遞給用戶的信息，會給造成暗示，如某處金額現(xiàn)實為負時，傳遞出的隱性情感肯定是偏向負面的。

PM要學會講故事：這里講故事的意思，是跟UED的童鞋進行溝通，感性的傳達肯定比理性的說教要好。某天交互設計師發(fā)了這樣一條微博：我總是忽略一件事，PM同學提出的究竟是需求，還是ta出于對需求的認知而擬定的一種解決方案。老大回復的是：往往是后者，junior PM因為junior所以會是后者，senior PM因為senior所以還是后者。