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

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

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

• 有沒有跟進(jìn)時間計劃
• 有沒有跟進(jìn)產(chǎn)品節(jié)點
• 有沒有全局考慮全在這里體現(xiàn)

01 時間計劃

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

【PROJECT管理工具】

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

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

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

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

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

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

02 跟進(jìn)需求

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

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

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

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

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

【移動端算法異常的情況】

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

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

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

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

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

因為每個團(tuán)隊的項目管理、團(tuán)隊大小不同，其每個團(tuán)隊反饋問題或同步問題的方式或流程也不同。

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

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

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

03 要學(xué)會舍棄

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

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

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

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

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

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

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

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

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

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

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

【UGC中常用的舉報或屏蔽功能模塊】

總結(jié)

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

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

#專欄作家#

kevin，微信公眾號：Kevin改變世界的點滴，人人都是產(chǎn)品經(jīng)理專欄作家。曾從事騰訊云產(chǎn)品設(shè)計與中興通訊產(chǎn)品研發(fā)，現(xiàn)金融產(chǎn)品經(jīng)理一枚。歡迎交流

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議