提產(chan)品(pin)需(xu)求是運營同學的日常(chang)工作之一，看似簡單，其實并不容易。
什么是(shi)(shi)產品需(xu)(xu)求呢？產品需(xu)(xu)求就是(shi)(shi)對(dui)達到某(mou)個既定(ding)目標需(xu)(xu)要實(shi)現(xian)的產品功能和特性的描述(shu)，可以從以下幾個維度來劃分：
1.外部(bu)需(xu)求和內部(bu)需(xu)求
前者(zhe)來自各個渠(qu)道收集的(de)用戶反(fan)饋(kui)，如微博微信qq群(qun)客(ke)服(fu)郵箱客(ke)服(fu)電話(hua)(hua)，以及產(chan)品自身的(de)反(fan)饋(kui)渠(qu)道（如論壇的(de)客(ke)服(fu)專區、在線即時(shi)咨詢(xun)窗口等）；后者(zhe)來自公司內(nei)部，如老板和其他部門(men)的(de)反(fan)饋(kui)。這些反(fan)饋(kui)通常都不會很明(ming)確，需(xu)(xu)要(yao)運營同學進(jin)行(xing)整理(li)挖掘(jue)，溝通調研進(jin)而提(ti)煉出(chu)需(xu)(xu)求。如果不經整理(li)提(ti)煉就統統丟給研發(fa)同學去處理(li)的(de)話(hua)(hua)——會被鄙（qia）視（si）的(de)……
2.改進型(xing)需(xu)(xu)求和新建型(xing)需(xu)(xu)求
它們倆是(shi)從1到10和(he)從0到1的(de)(de)區別。我個人的(de)(de)建議是(shi)已(yi)有(you)(you)的(de)(de)產品如果改進(jin)優化后能用，盡量不(bu)要(yao)(yao)另(ling)起爐灶，除(chu)非是(shi)原有(you)(you)的(de)(de)產品從定位到風格全都跟新需求不(bu)一致。這就(jiu)要(yao)(yao)求運營對(dui)現有(you)(you)產品定位跟功能了如指掌，能夠根(gen)據需求制定出合(he)理的(de)(de)問題解決(jue)方案，有(you)(you)時甚至可以不(bu)需要(yao)(yao)產品改動就(jiu)達(da)到目的(de)(de)。這樣(yang)不(bu)是(shi)效率很高嗎~
最怕的是(shi)(shi)拍腦袋(dai)就(jiu)做個(ge)產品，不考慮是(shi)(shi)否能利用已有的，導致留下一(yi)堆半截子工程，說能用也湊(cou)合能用，彼此間定位不清晰，后期運營推廣也不好做；同時系統里(li)很(hen)多(duo)冗余代碼難以(yi)維護，如(ru)果負責人一(yi)離(li)職就(jiu)再也沒人能說清這(zhe)產品的來(lai)龍去脈，于是(shi)(shi)又推倒重來(lai)一(yi)遍(bian)……對人力物(wu)力的極大浪(lang)費啊。
3.籠(long)統型需求和(he)精確型需求
前(qian)者如“現在(zai)(zai)這個編輯(ji)器(qi)太難用了(le)換一(yi)個吧，好(hao)多代碼格式都不支持(chi)”，后者如“需(xu)要(yao)一(yi)個除現在(zai)(zai)支持(chi)的代碼格式外，還能(neng)夠支持(chi)markdown語法的編輯(ji)器(qi)”。很多用戶反(fan)饋(kui)的需(xu)求就是前(qian)者那樣的，必須深入了(le)解分析，否則過于籠(long)統不具體的需(xu)求，是無法實現的，即使勉(mian)強上馬(ma)，也一(yi)定會因為需(xu)求不明確而導致(zhi)工期(qi)(qi)延誤(wu)和反(fan)復修改(gai)，最終應付(fu)了(le)事(shi)，所有參與人忙得夠嗆都不開心(xin)，寧可早期(qi)(qi)多用一(yi)些時間把需(xu)求搞(gao)清楚。
4.解(jie)決問題的需求和提(ti)高(gao)效率(lv)的需求
“我(wo)需(xu)要(yao)(yao)一(yi)個(ge)能給(gei)用戶群發(fa)(fa)郵件的(de)(de)后(hou)臺”和“我(wo)需(xu)要(yao)(yao)能夠自己導出符(fu)合某些特征的(de)(de)用戶郵箱列表給(gei)他們群發(fa)(fa)郵件”。不過后(hou)者需(xu)要(yao)(yao)評(ping)估(gu)使用頻度(du)，如果是(shi)高頻使用需(xu)求(qiu)(qiu)，開發(fa)(fa)一(yi)個(ge)還是(shi)有必要(yao)(yao)的(de)(de)，否則每次(ci)都要(yao)(yao)找(zhao)研發(fa)(fa)同學給(gei)導出郵箱也確實麻煩；如果是(shi)為了(le)某個(ge)臨時性的(de)(de)項目用，或者一(yi)年(nian)也用不了(le)幾(ji)次(ci)的(de)(de)低頻需(xu)求(qiu)(qiu)，那就沒必要(yao)(yao)開發(fa)(fa)一(yi)個(ge)專門(men)的(de)(de)功能了(le)。
為什(shen)么要從這些(xie)維(wei)度來(lai)劃分(fen)呢，因為實現(xian)產品需(xu)(xu)求(qiu)的(de)資源通(tong)常是有限的(de)，因此(ci)(ci)必須對需(xu)(xu)求(qiu)的(de)合理性和優先級做出(chu)明確判斷，并以此(ci)(ci)來(lai)決(jue)定開發的(de)資源投入以及(ji)排期(qi)先后。
另外有些(xie)似(si)是(shi)而非(fei)的(de)“產(chan)品需(xu)求”，實際(ji)上是(shi)bug，bug和產(chan)品需(xu)求的(de)區別及處理方(fang)式的(de)不(bu)同如下：
產品(pin)需求：
針(zhen)對還不存在的功能提的
解決(jue)的(de)是(shi)“不好用”的(de)問(wen)題(ti)
實(shi)現周期通常較長
發給產(chan)品(pin)經理處理（這個要(yao)看具體團隊(dui)構成和分工，是否(fou)有專門的(de)產(chan)品(pin)經理來處理需(xu)求(qiu)，如果運營兼負責產(chan)品(pin)那就由提出需(xu)求(qiu)的(de)同學自己(ji)處理了(le)）
產品bug：
針對已經存在的功(gong)能提的
解決的是“不能(neng)用”的問題(ti)
解決時間視bug嚴重(zhong)程度，通常要求(qiu)盡可能快地處(chu)理
可直(zhi)接發(fa)給研發(fa)人員解(jie)決
提(ti)需求和(he)提(ti)bug的流程
產品需(xu)求描述
產品經理通常需(xu)要(yao)把收到的(de)(de)各路(lu)需(xu)求(qiu)整理成產品原型文(wen)檔，但對于運(yun)營同學來說(shuo)并沒有那(nei)么嚴格的(de)(de)文(wen)檔要(yao)求(qiu)，只(zhi)要(yao)讓產品同學能(neng)夠明(ming)白你的(de)(de)意思(si)就可以(yi)；不過為(wei)了提高溝通的(de)(de)效率，有必要(yao)參照一定的(de)(de)格式來描述(shu)你的(de)(de)需(xu)求(qiu)，這(zhe)里舉(ju)個我現在團隊的(de)(de)例(li)子：
需求名稱：產品名稱+功能+提出時間，如“CocoaChina編輯后(hou)臺改進(jin)產品需求-2015-8-17”
目的(de)：有助于產(chan)品同學充分理解你的(de)需求的(de)必(bi)要性(xing)和(he)重要程度，如“為了提高編輯發稿的(de)工作效率”或“為了統一(yi)網站整(zheng)體風格而進行(xing)UI重新設計(ji)”。
優先(xian)級和時間要求：這個也(ye)很重要，因為產品經理通常會收(shou)到大量的(de)需求，如何安排優先(xian)級處理順序？如果你在需求里有(you)明確的(de)說(shuo)明，那么處理效率會高一些。如“第一優先(xian)級，需要六月15日前(qian)完成”。
需(xu)求描述：說明用(yong)戶(hu)身份(fen)（外部(bu)(bu)用(yong)戶(hu)和(he)內部(bu)(bu)用(yong)戶(hu)的處理方式(shi)有區別），頁面(mian)需(xu)要包含哪些元素，期待的布(bu)局和(he)風格，排列(lie)順序，是(shi)否(fou)(fou)必選項，有何(he)特殊要求，是(shi)否(fou)(fou)需(xu)要查(cha)詢及查(cha)詢條件設定，是(shi)否(fou)(fou)需(xu)要權限管理等信息(xi)，盡可能(neng)詳(xiang)細，最好(hao)給出參考案(an)例(li)或類似競品(pin)截圖。
什么情況下(xia)需要提產(chan)品需求
如果(guo)以上(shang)你都(dou)已經爛熟(shu)于心，對(dui)于如何提產品需求應(ying)該是(shi)(shi)沒有(you)問題了(le)。但是(shi)(shi)且慢，知道怎么(me)做(zuo)只是(shi)(shi)最(zui)基礎的(de)(de)(de)(de)，對(dui)于合格(ge)的(de)(de)(de)(de)運營(ying)來說，更重要(yao)(yao)(yao)的(de)(de)(de)(de)是(shi)(shi)判斷要(yao)(yao)(yao)做(zuo)什么(me)和不做(zuo)什么(me)。用(yong)(yong)(yong)戶的(de)(de)(de)(de)需求永無(wu)止境，運營(ying)不能只是(shi)(shi)需求的(de)(de)(de)(de)傳(chuan)聲筒，需要(yao)(yao)(yao)深入分析用(yong)(yong)(yong)戶需求背后的(de)(de)(de)(de)目的(de)(de)(de)(de)和隱(yin)藏(zang)的(de)(de)(de)(de)問題，如果(guo)能夠用(yong)(yong)(yong)已有(you)的(de)(de)(de)(de)產品達到的(de)(de)(de)(de)，就盡(jin)量不要(yao)(yao)(yao)重復(fu)建(jian)設做(zuo)新產品；如果(guo)能用(yong)(yong)(yong)運營(ying)的(de)(de)(de)(de)手法解決的(de)(de)(de)(de)，更不必耗時(shi)費力(li)地動用(yong)(yong)(yong)產品和研(yan)發(fa)；如果(guo)能夠利用(yong)(yong)(yong)已有(you)成熟(shu)的(de)(de)(de)(de)渠道跟平(ping)臺借勢推廣(guang)的(de)(de)(de)(de)，又何苦非要(yao)(yao)(yao)做(zuo)一個(ge)“自己的(de)(de)(de)(de)”獨立平(ping)臺一切從零開(kai)始呢？
做(zuo)加法永遠(yuan)比(bi)做(zuo)減法容易，另起(qi)爐灶似乎也(ye)比(bi)在原有(you)基礎上(shang)修(xiu)補改進要(yao)痛快，但是資源永遠(yuan)都有(you)限，無論是人力還是時間，即使你有(you)一組強悍(han)的(de)產(chan)(chan)品和研發同學(xue)24小時無條件配合，仍然要(yao)評估需求(qiu)(qiu)真實的(de)價值有(you)多少，衡(heng)量投入產(chan)(chan)出比(bi)。運(yun)(yun)營的(de)強項(xiang)在于給你一個產(chan)(chan)品，你能(neng)夠發掘它(ta)的(de)一千零(ling)一種用(yong)法（玩法）并(bing)將其傳遞給用(yong)戶來滿(man)足(zu)不同的(de)需求(qiu)(qiu)，如果(guo)一接到(dao)新需求(qiu)(qiu)就要(yao)做(zuo)個新產(chan)(chan)品，而不是先看看運(yun)(yun)用(yong)已有(you)的(de)產(chan)(chan)品是否能(neng)夠解決問題，運(yun)(yun)營自(zi)身(shen)的(de)價值何在呢？
案(an)例一：數據優化(hua)后(hou)臺
曾經有同事負責運營(ying)一個垂直(zhi)專業(ye)領域(yu)的(de)(de)群組，提出(chu)要做一個數(shu)(shu)據(ju)(ju)分(fen)(fen)析(xi)(xi)后臺，能夠根據(ju)(ju)加入群組用(yong)戶(hu)(hu)填寫(xie)的(de)(de)個人信(xin)息自(zi)(zi)動(dong)生(sheng)成(cheng)各種維度的(de)(de)分(fen)(fen)析(xi)(xi)圖(tu)表，“就(jiu)像專業(ye)的(de)(de)數(shu)(shu)據(ju)(ju)分(fen)(fen)析(xi)(xi)報(bao)告(gao)(gao)那樣”，他說。這并(bing)不(bu)是(shi)一個實(shi)現起來很(hen)簡單(dan)的(de)(de)需(xu)求，雖然對用(yong)戶(hu)(hu)的(de)(de)數(shu)(shu)據(ju)(ju)分(fen)(fen)析(xi)(xi)是(shi)有必要做的(de)(de)。但是(shi)該群組目前(qian)的(de)(de)注冊用(yong)戶(hu)(hu)只有幾(ji)千人，且新用(yong)戶(hu)(hu)增加速度非(fei)常(chang)緩慢，用(yong)戶(hu)(hu)數(shu)(shu)據(ju)(ju)分(fen)(fen)析(xi)(xi)的(de)(de)時效性(xing)并(bing)不(bu)是(shi)非(fei)常(chang)高，因此最終解決方(fang)案是(shi)導出(chu)用(yong)戶(hu)(hu)數(shu)(shu)據(ju)(ju)到(dao)excel中(zhong)，運營(ying)自(zi)(zi)己根據(ju)(ju)統(tong)計(ji)需(xu)求，利用(yong)excel生(sheng)成(cheng)分(fen)(fen)析(xi)(xi)圖(tu)表，至于是(shi)否像專業(ye)報(bao)告(gao)(gao)，那就(jiu)看自(zi)(zi)己的(de)(de)excel造詣啦~如果(guo)未來用(yong)戶(hu)(hu)量和(he)增長速度達(da)到(dao)一定(ding)規模，人工統(tong)計(ji)無法滿足，才是(shi)需(xu)要開發數(shu)(shu)據(ju)(ju)統(tong)計(ji)后臺的(de)(de)時候。
案例二：大會報名app
我所(suo)在的(de)(de)(de)社(she)區(qu)運營(ying)團(tuan)隊(dui)曾經負責組織(zhi)公司的(de)(de)(de)開發(fa)者大(da)會報名，通(tong)過(guo)社(she)區(qu)各個(ge)(ge)渠道向開發(fa)者用(yong)戶(hu)進行(xing)宣(xuan)傳(chuan)，使用(yong)的(de)(de)(de)是社(she)區(qu)的(de)(de)(de)活動報名系(xi)統，可(ke)以匯聚各個(ge)(ge)渠道的(de)(de)(de)報名數據到后(hou)臺數據庫(ku)。有同事提(ti)(ti)議說開發(fa)一個(ge)(ge)大(da)會報名app，以后(hou)組織(zhi)大(da)會都可(ke)以讓用(yong)戶(hu)通(tong)過(guo)app報名，這(zhe)樣(yang)推(tui)(tui)廣時只要通(tong)過(guo)app推(tui)(tui)送(song)提(ti)(ti)醒就可(ke)以啦~~~我說你這(zhe)個(ge)(ge)創(chuang)意不(bu)錯，你先(xian)想法讓用(yong)戶(hu)都裝上這(zhe)個(ge)(ge)app，然(ran)后(hou)。。就沒(mei)有然(ran)后(hou)了。。
總之接到需求(qiu)后，問自己(ji)以(yi)下幾個(ge)問題：
目標(biao)足(zu)夠明確嗎？
已(yi)有的產品確實無法滿足工作要求嗎？
已(yi)有產(chan)品的缺陷已(yi)經(jing)極其(qi)影響工作(zuo)效率(lv)嗎？
成本(ben)是否合(he)適(shi)？
如果答(da)案(an)是否定(ding)的(de)(de)，那就需要重新審視這個需求的(de)(de)合理性，并(bing)且(qie)和需求方積(ji)極溝通確(que)定(ding)最(zui)終(zhong)解決(jue)方案(an)。
如何促使需(xu)求盡快實現
需求表述明確，溝通(tong)清楚(chu)，提(ti)交流程規范：該(gai)自(zi)己做(zuo)的(de)一定要做(zuo)到位
按流程提(ti)交需(xu)求(qiu)后最好(hao)再(zai)當(dang)面跟產品(pin)經(jing)理溝通，盡快落實需(xu)求(qiu)并啟動
必(bi)要時(shi)要舍得砍需求，確保(bao)快速上線
充(chong)分(fen)利用各(ge)項資源(yuan)來(lai)達(da)到(dao)目(mu)標(biao)：平時(shi)和(he)產品設計研(yan)發(fa)同學搞好關系，必要時(shi)通過上級推動都是(shi)方法
幾(ji)點總結(jie)
產品改進(jin)通常要(yao)落(luo)后于業務(wu)需求
互聯(lian)網產(chan)品(pin)改進(jin)伴隨整個產(chan)品(pin)的(de)生命周(zhou)期(qi)，不是(shi)一次性的(de)
產品改進是由(you)運營驅動的(de)
再(zai)好的產品，運營跟(gen)不(bu)上也是白(bai)費(fei)
對內容運營和社區運營來說(shuo)，產品是輔助手段，不(bu)是目(mu)標
了解產品的互聯網編輯/運營(ying)會有更多的職業發展機會
作者：產(chan)品經營張媛
來源：簡書(shu)
原文(wen)鏈(lian)接：//www.jianshu.com/p/65fa56a8cf2c#
