需求跟進(jìn)中的3大步驟

一個(gè)產(chǎn)品經(jīng)理可以隨時(shí)隨地的知曉自己需求的進(jìn)度，并且能夠及時(shí)檢驗(yàn)，是對產(chǎn)品負(fù)責(zé)的一個(gè)態(tài)度。

　　產(chǎn)品經(jīng)理中打醬油的節(jié)點(diǎn)

　　最近負(fù)責(zé)的產(chǎn)品模塊進(jìn)入開發(fā)周期，需求評審、產(chǎn)品設(shè)計(jì)過一段落，是時(shí)候歇一口氣的周期。往往很多產(chǎn)品經(jīng)理在這個(gè)時(shí)候，最常用的是要么在有任務(wù)或需求指標(biāo)下，不快不慢地進(jìn)入下一個(gè)需求；要么是在下一個(gè)版本時(shí)間、或需求沒明確的時(shí)候，沒有事情的等待產(chǎn)品上線；不得不說這個(gè)周期，我認(rèn)為是評判一個(gè)產(chǎn)品經(jīng)理是否負(fù)責(zé)的PM。

　?。?nbsp;有沒有跟進(jìn)時(shí)間計(jì)劃

　?。?nbsp;有沒有跟進(jìn)產(chǎn)品節(jié)點(diǎn)

　?。?nbsp;有沒有全局考慮全在這里體現(xiàn)

　　01 時(shí)間計(jì)劃

　　我在工作中，會(huì)用甘特圖或PROJECT去把控產(chǎn)品的開發(fā)負(fù)責(zé)人、開發(fā)周期、工作描述，其中如果遇到大版本迭代，參與人數(shù)或變動(dòng)比較頻繁的話，我會(huì)多采用PROJECT去管理項(xiàng)目的情況。

【PROJECT管理工具】

　　由上圖，我們可以清清楚楚的看到每一個(gè)階段會(huì)有哪些任務(wù)，每個(gè)任務(wù)會(huì)消耗的時(shí)間或精力。

　　這個(gè)就是時(shí)間計(jì)劃，當(dāng)然根據(jù)你公司的分工情況；有時(shí)候項(xiàng)目經(jīng)理會(huì)進(jìn)行把控時(shí)間節(jié)點(diǎn)，并沒有一個(gè)產(chǎn)品經(jīng)理的時(shí)間點(diǎn)的意識(shí)。

　　但作為一個(gè)產(chǎn)品經(jīng)理，隨時(shí)隨地的知曉自己需求的進(jìn)度，并且能夠及時(shí)檢驗(yàn)，是對產(chǎn)品負(fù)責(zé)的一個(gè)態(tài)度；并且在需求評審落地過程中，如果是大的需求，可能會(huì)遺忘一些產(chǎn)品邏輯或細(xì)節(jié)字段。

　　這個(gè)是我會(huì)出現(xiàn)的一個(gè)情況，但我不知道正在閱讀的你是否會(huì)出現(xiàn)以上情況，來一個(gè)投票看看大家的情況吧！

　　在這里注意的是，在使用PROJECT工具中，需要注意各個(gè)項(xiàng)目任務(wù)的前后流程、人員關(guān)系，清楚知道時(shí)間節(jié)點(diǎn)或有評估時(shí)間節(jié)點(diǎn)。

　　不然，你隨便做一個(gè)時(shí)間節(jié)點(diǎn)，可能開發(fā)的周期更長，那么這個(gè)項(xiàng)目周期的管理能夠?qū)嶋H運(yùn)用的意義就沒有了。

　　02 跟進(jìn)需求

　　剛剛前面說過，有的團(tuán)隊(duì)可能會(huì)是以項(xiàng)目經(jīng)理或者BOSS直接去跟進(jìn)需求進(jìn)度，時(shí)刻CEHCK當(dāng)時(shí)的產(chǎn)品是否符合預(yù)期或滿足其需求。

　　這里我們拋開上面的情況不說，PM跟進(jìn)需求通過以上的節(jié)點(diǎn)去了解現(xiàn)在的進(jìn)度。比如一個(gè)APP中的某個(gè)功能，到了周五交貨時(shí)間（開發(fā)說給你測試包），那么產(chǎn)品就可以去驗(yàn)收，看看現(xiàn)在是否滿足其需求。

　　這個(gè)過程是頻繁、交際較多的，以下就是常見的開發(fā)分工情況

　　那么，一個(gè)完整的產(chǎn)品需求完成是離不開以上幾個(gè)工作職責(zé)的開發(fā)人員，不然你只可能去看看UI，沒有數(shù)據(jù)的產(chǎn)品；要么就是有數(shù)據(jù)，但是不能按照需求中的算法或規(guī)則去顯示。

　　比如FEED流的重力算法，是否可用按照需求中的算法，這個(gè)需要PM人員進(jìn)行相關(guān)測試，但是如果服務(wù)端沒有做處理；那么可能數(shù)據(jù)就是按開發(fā)人默認(rèn)的順序去執(zhí)行。

【移動(dòng)端算法異常的情況】

　　因此，產(chǎn)品經(jīng)理跟進(jìn)中，跟進(jìn)第一部分說的時(shí)間節(jié)點(diǎn)；去跟進(jìn)當(dāng)前的開發(fā)需求完成情況，當(dāng)然根據(jù)我的經(jīng)驗(yàn)中，很多過程會(huì)出現(xiàn)以下情況

【根據(jù)中的問題處理】

　　在我工作的團(tuán)隊(duì)中，經(jīng)常會(huì)出現(xiàn)或數(shù)據(jù)端跟不上前端的速度，前端需要苦逼的等著接口的到來，這其實(shí)無疑是木桶效應(yīng)。我認(rèn)為團(tuán)隊(duì)中，應(yīng)該盡可能的去避免這種情況的出現(xiàn)。

　　木桶效應(yīng)的原理是：影響裝水的量最終是木桶中最短的那個(gè)木板。

　　這里我們把裝水的量比作是開發(fā)的進(jìn)度，因此開發(fā)人員中如果有一個(gè)部門或某個(gè)職責(zé)的工作影響了進(jìn)度，就會(huì)導(dǎo)致整個(gè)模塊的開發(fā)推遲。這也是為什么一個(gè)好的項(xiàng)目經(jīng)理或好的產(chǎn)品經(jīng)理能夠迅速去把控相應(yīng)的問題，爭取將團(tuán)隊(duì)的木桶效應(yīng)最小化，開發(fā)資源利用最大化。

　　因?yàn)槊總€(gè)團(tuán)隊(duì)的項(xiàng)目管理、團(tuán)隊(duì)大小不同，其每個(gè)團(tuán)隊(duì)反饋問題或同步問題的方式或流程也不同。

　　在創(chuàng)業(yè)公司，或許開發(fā)就坐PM旁邊，任何問題或情況都能馬上知曉。但在一定規(guī)模的團(tuán)隊(duì)或企業(yè)中，往往開發(fā)人員對一些需求出現(xiàn)了問題，沒有進(jìn)行處理或未完成，PM根據(jù)時(shí)間節(jié)點(diǎn)才能進(jìn)行追蹤到相應(yīng)環(huán)節(jié)出現(xiàn)問題的人或部門。

　　這也是我目前跟進(jìn)中最頻繁的工作，移動(dòng)端出現(xiàn)的問題是因?yàn)榉?wù)端，那么就去跟進(jìn)服務(wù)端；服務(wù)端做了，但移動(dòng)端卻沒有顯示，那么就去跟進(jìn)移動(dòng)端。

　　保證需求能夠順利的發(fā)包，最終按時(shí)上線。

　　03 要學(xué)會(huì)舍棄

　　最終這一部分，說一說最近工作中最常出現(xiàn)的情況，也有可能是在閱讀的你工作中出現(xiàn)比較多的情況。

　　需求開發(fā)過程中，往往會(huì)出現(xiàn)一些需求評審沒有出現(xiàn)的問題或技術(shù)沒辦法估計(jì)的問題。

　　好的情況是，這個(gè)需求經(jīng)過評審得到開發(fā)人員的認(rèn)可，可以去做，但是需要推遲；壞的情況是，開發(fā)人員根本不認(rèn)可，不做！

　　當(dāng)然，PM總會(huì)說：

　　“砍我可以，別砍需求??！這個(gè)需求評審的時(shí)候你不說，現(xiàn)在這個(gè)節(jié)骨眼給我說。”

　　但是，這個(gè)的的確確是執(zhí)行與會(huì)議的區(qū)別，每個(gè)產(chǎn)品經(jīng)理都心知肚明。好的產(chǎn)品經(jīng)理能夠在評審中找到關(guān)鍵的難點(diǎn)進(jìn)行詳細(xì)評審，新人產(chǎn)品往往就會(huì)一篇蓋全，不知道最大的坑確實(shí)在開發(fā)過程中。

　　首先，在工作中產(chǎn)品經(jīng)理是對產(chǎn)品負(fù)責(zé)的第一責(zé)任人，如果你都不對你的產(chǎn)品負(fù)責(zé)，不想辦法去把產(chǎn)品往好的做；而是以完成任務(wù)的心態(tài)，上一個(gè)需求能上多少就上多少，那這個(gè)產(chǎn)品最終能為你帶來多少的價(jià)值，我們可想而知。

　　在遇到上面的情況，我們首先需要可以從下面幾部分去分析或爭辯：

　　從以上4個(gè)部分來爭取需求的開發(fā)資源，比如一個(gè)用戶量只有幾十萬的用戶產(chǎn)品；每天產(chǎn)生的用戶UGC就十多條，那么是否有必要增加舉報(bào)功能？

　　雖然說舉報(bào)功能對于產(chǎn)品尤其是UGC是很好的一個(gè)過濾機(jī)制，是能夠增加產(chǎn)品的豐富。

　　但每天就10多條，現(xiàn)在的產(chǎn)品重點(diǎn)應(yīng)該是引導(dǎo)用戶去產(chǎn)生UGC，十多條的量人工在后臺(tái)可以進(jìn)行刪除監(jiān)控就足夠，是不是在當(dāng)前的用戶基數(shù)或產(chǎn)品量情況下，可以不用去考慮過濾情況？

【UGC中常用的舉報(bào)或屏蔽功能模塊】

　　總結(jié)

　　因此，產(chǎn)品經(jīng)理需要學(xué)會(huì)舍棄，用需求池之前有說過垂直社交與需求文檔思考的相關(guān)管理辦法。

　　我看到很多產(chǎn)品經(jīng)理為了說服開發(fā)去做自己的需求，有時(shí)候是為了不讓自己打臉。畢竟就算一個(gè)很小的需求，產(chǎn)品人員也是經(jīng)過調(diào)研或者思考，作為產(chǎn)品設(shè)計(jì)中，每個(gè)人都希望自己的需求能夠盡可能的完整。

來源：人人都是產(chǎn)品經(jīng)理