導(dǎo)讀：什么是產(chǎn)品需求呢？產(chǎn)品需求就是對(duì)達(dá)到某個(gè)既定目標(biāo)需要實(shí)現(xiàn)的產(chǎn)品功能和特性的描述。提產(chǎn)品需求是運(yùn)營(yíng)同學(xué)的日常工作之一，看似簡(jiǎn)單，其實(shí)并不容易。
正文
提產(chǎn)品需求是運(yùn)營(yíng)同學(xué)的日常工作之一，看似簡(jiǎn)單，其實(shí)并不容易。
什么是產(chǎn)品需求呢？產(chǎn)品需求就是對(duì)達(dá)到某個(gè)既定目標(biāo)需要實(shí)現(xiàn)的產(chǎn)品功能和特性的描述，可以從以下幾個(gè)維度來劃分：
1.外部需求和內(nèi)部需求：
前者來自各個(gè)渠道收集的用戶反饋，如微博、微信、QQ群、客服郵箱、客服電話，以及產(chǎn)品自身的反饋渠道（如論壇的客服專區(qū)、在線即時(shí)咨詢窗口等）；
后者來自公司內(nèi)部，如老板和其它部門提出的需求。這些反饋通常都不會(huì)很明確，需要運(yùn)營(yíng)同學(xué)進(jìn)行整理挖掘、溝通調(diào)研進(jìn)而提煉出需求。如果不經(jīng)整理提煉就統(tǒng)統(tǒng)丟給產(chǎn)品跟研發(fā)同學(xué)去處理的話——會(huì)被鄙（qia）視（si）的……
2.改進(jìn)型需求和新建型需求：
它們倆是從1到10和從0到1的區(qū)別。我個(gè)人的建議是已有的產(chǎn)品如果改進(jìn)優(yōu)化后能用，盡量不要另起爐灶，除非是原有的產(chǎn)品從定位到風(fēng)格全都跟新需求不一致。這里一方面關(guān)系到效率，能否快速運(yùn)用已有產(chǎn)品達(dá)到業(yè)務(wù)目標(biāo)，而不是只能等著新產(chǎn)品上線錯(cuò)過寶貴的窗口期；另一方面關(guān)系到借勢(shì)，是否能夠借助已有的流量或者品牌優(yōu)勢(shì)來加速業(yè)務(wù)目標(biāo)的實(shí)現(xiàn)。
這就要求運(yùn)營(yíng)對(duì)公司內(nèi)部現(xiàn)有產(chǎn)品定位跟功能了如指掌，對(duì)公司外部可以利用的現(xiàn)成平臺(tái)和資源也非常熟悉，從而能夠根據(jù)需求制定出合理的問題解決方案，有時(shí)甚至可以不需要產(chǎn)品改動(dòng)和新增就能達(dá)到目的。
比如：
做一個(gè)媒體，先以微信公眾號(hào)起步，就比直接開發(fā)一個(gè)App實(shí)際地多；
要推廣一個(gè)新產(chǎn)品，是自己從零開始建一個(gè)產(chǎn)品官網(wǎng)一步步做內(nèi)容做流量拉用戶來得快，還是和能夠直接接觸到該產(chǎn)品潛在用戶的渠道合作來得快？
最怕的是拍腦袋就做個(gè)產(chǎn)品，不考慮是否能利用已有的平臺(tái)資源，導(dǎo)致留下一堆半截子工程，說能用也湊合能用，但又缺乏清晰的定位和維護(hù)，后期運(yùn)營(yíng)推廣也不好做；同時(shí)系統(tǒng)里留下很多冗余代碼，如果負(fù)責(zé)人一離職就再也沒人能說清這產(chǎn)品的來龍去脈，于是又推倒重來一遍……對(duì)人力物力都是極大的浪費(fèi)。
3.籠統(tǒng)型需求和精確型需求：
前者如：「現(xiàn)在這個(gè)編輯器太難用了換一個(gè)吧，好多代碼格式都不支持」；
后者如：「需要一個(gè)除現(xiàn)在支持的代碼格式外，還能夠支持markdown語法的編輯器」。
很多用戶反饋的需求就是前者那樣的，必須深入了解分析，否則過于籠統(tǒng)不具體的需求，是無法實(shí)現(xiàn)的，即使勉強(qiáng)上馬，也一定會(huì)因?yàn)樾枨蟛幻鞔_而導(dǎo)致工期延誤和反復(fù)修改，最終應(yīng)付了事，所有參與人忙得夠嗆都不開心，寧可早期多用一些時(shí)間把需求搞清楚。
4.解決問題的需求和提高效率的需求：
例如：「我需要一個(gè)能給用戶群發(fā)郵件的后臺(tái)」和「我需要能夠自己導(dǎo)出符合某些特征的用戶郵箱列表給他們?nèi)喊l(fā)郵件」。
不過后者需要評(píng)估使用頻度，如果是高頻使用需求，開發(fā)一個(gè)還是有必要的，否則每次都要找研發(fā)同學(xué)給導(dǎo)出郵箱也確實(shí)麻煩；如果是為了某個(gè)臨時(shí)性的項(xiàng)目用，或者一年也用不了幾次的低頻需求，那就沒必要開發(fā)一個(gè)專門的功能了。
為什么要從這些維度來劃分呢，因?yàn)閷?shí)現(xiàn)產(chǎn)品需求的資源通常是有限的，因此必須對(duì)需求的合理性和優(yōu)先級(jí)做出明確判斷，并以此來決定開發(fā)的資源投入以及排期先后。
另外有些似是而非的「產(chǎn)品需求」，實(shí)際上并不是需求而是bug，bug和產(chǎn)品需求的區(qū)別及處理方式的不同如下：
產(chǎn)品需求：
針對(duì)還不存在的功能提的
解決的是「不好用」的問題
實(shí)現(xiàn)周期通常較長(zhǎng)
發(fā)給產(chǎn)品經(jīng)理處理（這個(gè)要看具體團(tuán)隊(duì)構(gòu)成和分工，是否有專門的產(chǎn)品經(jīng)理來處理需求，如果運(yùn)營(yíng)兼負(fù)責(zé)產(chǎn)品那就由提出需求的同學(xué)自己處理了）
產(chǎn)品bug：
針對(duì)已經(jīng)存在的功能提的
解決的是「不能用」的問題
解決時(shí)間視bug嚴(yán)重程度，通常要求盡可能快地處理
可直接發(fā)給研發(fā)人員解決
提需求和提bug的流程
產(chǎn)品需求描述
產(chǎn)品經(jīng)理通常需要把收到的各路需求整理成產(chǎn)品原型文檔，但對(duì)于運(yùn)營(yíng)同學(xué)來說并沒有那么嚴(yán)格的文檔要求，只要讓產(chǎn)品同學(xué)能夠明白你的意思就可以；不過為了提高溝通的效率，有必要參照一定的格式來描述你的需求，這里舉個(gè)我現(xiàn)在團(tuán)隊(duì)的例子：
1.需求名稱：產(chǎn)品名稱+功能+提出時(shí)間，如「編輯后臺(tái)改進(jìn)產(chǎn)品需求-2015-8-17」
2.目的：有助于產(chǎn)品同學(xué)充分理解你的需求的必要性和重要程度，如「為了提高編輯發(fā)稿的工作效率」或「為了統(tǒng)一網(wǎng)站整體風(fēng)格而進(jìn)行UI重新設(shè)計(jì)」。
3.優(yōu)先級(jí)和時(shí)間要求：這個(gè)也很重要，因?yàn)楫a(chǎn)品經(jīng)理通常會(huì)收到大量的需求，如何安排優(yōu)先級(jí)處理順序？如果你在需求里有明確的說明，那么處理效率會(huì)高一些。如「第一優(yōu)先級(jí)，需要六月15日前完成」。
4.需求描述：說明用戶身份（外部用戶和內(nèi)部用戶的處理方式有區(qū)別），頁面需要包含哪些元素，期待的布局和風(fēng)格，排列順序，是否必選項(xiàng)，有何特殊要求，是否需要查詢及查詢條件設(shè)定，是否需要權(quán)限管理等信息，盡可能詳細(xì)，最好給出參考案例或類似競(jìng)品截圖。
什么情況下需要提產(chǎn)品需求
如果以上你都已經(jīng)爛熟于心，對(duì)于如何提產(chǎn)品需求應(yīng)該是沒有問題了。
但是且慢，知道怎么做只是最基礎(chǔ)的，對(duì)于合格的運(yùn)營(yíng)來說，更重要的是判斷要做什么和不做什么。
用戶的需求永無止境，運(yùn)營(yíng)不能只是需求的傳聲筒，需要深入分析用戶需求背后的目的和隱藏的問題，如果能夠用已有的產(chǎn)品達(dá)到的，就盡量不要重復(fù)建設(shè)做新產(chǎn)品；如果能用運(yùn)營(yíng)的手法解決的，更不必興師動(dòng)眾地動(dòng)用產(chǎn)品和研發(fā)；如果能夠利用已有成熟的渠道跟平臺(tái)借勢(shì)推廣的，又何苦非要做一個(gè)「自己的」獨(dú)立平臺(tái)一切從零開始呢？
做加法永遠(yuǎn)比做減法容易，另起爐灶似乎也比在原有基礎(chǔ)上修補(bǔ)改進(jìn)要痛快（某些情況下，也被看做是業(yè)績(jī)的體現(xiàn)），但是資源永遠(yuǎn)都有限，無論是人力還是時(shí)間，即使你有一組強(qiáng)悍的產(chǎn)品和研發(fā)同學(xué) 24 小時(shí)無條件配合，仍然要評(píng)估需求真實(shí)的價(jià)值有多少，衡量投入產(chǎn)出比。
運(yùn)營(yíng)的強(qiáng)項(xiàng)在于給你一個(gè)產(chǎn)品，你能夠發(fā)掘它的一千零一種用法（玩法）并將其傳遞給用戶來滿足業(yè)務(wù)的需求，如果一接到新需求就要做個(gè)新產(chǎn)品，而不是先看看運(yùn)用已有的產(chǎn)品是否能夠解決問題，運(yùn)營(yíng)自身的價(jià)值何在呢？
案例一：數(shù)據(jù)分析后臺(tái)
曾經(jīng)有同事負(fù)責(zé)運(yùn)營(yíng)一個(gè)垂直專業(yè)領(lǐng)域的群組，提出要做一個(gè)數(shù)據(jù)分析后臺(tái)，能夠根據(jù)加入群組用戶填寫的個(gè)人信息自動(dòng)生成各種維度的分析圖表，「就像專業(yè)的數(shù)據(jù)分析報(bào)告那樣」，他說。
這并不是一個(gè)實(shí)現(xiàn)起來很簡(jiǎn)單的需求，雖然對(duì)用戶的數(shù)據(jù)分析是有必要做的。但是該群組目前的注冊(cè)用戶只有幾千人，且新用戶增加速度非常緩慢，用戶數(shù)據(jù)分析的時(shí)效性并不是非常高，因此最終解決方案是導(dǎo)出用戶數(shù)據(jù)到Excel中，運(yùn)營(yíng)自己根據(jù)統(tǒng)計(jì)需求，利用Excel生成分析圖表，至于是否像專業(yè)報(bào)告，那就看自己的Excel造詣啦~如果未來用戶量和增長(zhǎng)速度達(dá)到一定規(guī)模，人工統(tǒng)計(jì)無法滿足，才是需要開發(fā)數(shù)據(jù)統(tǒng)計(jì)后臺(tái)的時(shí)候。
案例二：大會(huì)報(bào)名App
我所在的社區(qū)運(yùn)營(yíng)團(tuán)隊(duì)曾經(jīng)負(fù)責(zé)組織公司的開發(fā)者大會(huì)報(bào)名，通過社區(qū)各個(gè)渠道向開發(fā)者用戶進(jìn)行宣傳，使用的是社區(qū)的活動(dòng)報(bào)名系統(tǒng)，可以匯聚各個(gè)渠道的報(bào)名數(shù)據(jù)到后臺(tái)數(shù)據(jù)庫。
有同事提議說開發(fā)一個(gè)大會(huì)報(bào)名App，以后組織大會(huì)都可以讓用戶通過App報(bào)名，這樣推廣時(shí)只要通過App推送提醒就可以啦~~~我說你這個(gè)創(chuàng)意不錯(cuò)，你先想法讓用戶都裝上這個(gè)App，然后。。就沒有然后了。。。
總之收集到需求后，先問自己以下幾個(gè)問題：
目標(biāo)足夠明確嗎？
已有的產(chǎn)品確實(shí)無法滿足工作要求嗎？
已有產(chǎn)品的缺陷已經(jīng)極其影響工作效率嗎？
成本是否合適？
如果答案有任何一條是否定的，那就需要重新審視這個(gè)需求的合理性，并且和需求方積極溝通確定最終解決方案。南寧網(wǎng)站建設(shè)
如何促使需求盡快實(shí)現(xiàn)
需求表述明確，溝通清楚，提交流程規(guī)范：該自己做的一定要做到位
按流程提交需求后最好再當(dāng)面跟產(chǎn)品經(jīng)理溝通，盡快落實(shí)需求并啟動(dòng)
必要時(shí)要舍得砍需求，確?？焖偕暇€
充分利用各項(xiàng)資源來達(dá)到目標(biāo)：平時(shí)和產(chǎn)品設(shè)計(jì)研發(fā)同學(xué)搞好關(guān)系，甚至必要時(shí)通過老板推動(dòng)都是方法（但此大招不可常用）
幾點(diǎn)總結(jié)
產(chǎn)品改進(jìn)通常落后于業(yè)務(wù)需求，這是正?，F(xiàn)象
互聯(lián)網(wǎng)產(chǎn)品改進(jìn)伴隨整個(gè)產(chǎn)品的生命周期，不是一次性的
產(chǎn)品改進(jìn)通常是由運(yùn)營(yíng)驅(qū)動(dòng)的，由產(chǎn)品（不了解運(yùn)營(yíng)）驅(qū)動(dòng)的多半失敗
再好的產(chǎn)品，不重視運(yùn)營(yíng)也是白費(fèi)
對(duì)內(nèi)容運(yùn)營(yíng)和社區(qū)運(yùn)營(yíng)來說，產(chǎn)品是輔助手段，不是目標(biāo)
具備一定產(chǎn)品能力的運(yùn)營(yíng)會(huì)有更多的職業(yè)發(fā)展機(jī)會(huì)
