如今的大部分互聯(lián)網(wǎng)公司，是不怎么區(qū)分產(chǎn)品經(jīng)理和項目管理經(jīng)理了。也難怪，它們的工作職責中是有很多重合的部分，因此，往往產(chǎn)品經(jīng)理也會擔著項目管理的活兒。今兒，咱們就聊一聊項目管理的那些事兒。

你是產(chǎn)品經(jīng)理

也負責項目管理

天天各種問題都要經(jīng)歷

前腳方案被斃

接著開發(fā)就延期

新版上線實屬不易

即使這樣

踉踉蹌蹌

產(chǎn)品經(jīng)理依然不一樣

我希望你

斗志昂揚

仔細閱讀這篇文章

相信項目管理不會再成為你的弱項

運營mm：“老王，你看這個需求這一期能不能給俺加上啊，你要這期給俺做的話，我就答應(yīng)跟你去看電影。”

我：“嗯，別慌，容我考慮一下！”

 

運營gg：“小王啊，這期這個需求一定要給我加上啊，這都拖了快半年了，啥時候是個頭?。俊?/p>

我：“急啥，下期一定給你加，這期的話，是不行了?！?/p>

當然，作為一個鐵面無私的產(chǎn)品經(jīng)理，一定是本著對需求負責的態(tài)度，那么，對于這些來源于不同部門，像是一團散沙的需求，如何去整理歸類呢。

需求池的建立

需求這東西，就好比是一條條小魚，平時你不管它的時候，它活蹦亂跳，真正想去找它的時候，卻發(fā)現(xiàn)它消失的無影無蹤。既然這樣，我干脆就把它們?nèi)︷B(yǎng)起來。什么時候想吃烤魚了，撈出一條就直接烤了吃，方便快捷。

說起需求池，就不得不說一下需求的來源。一般分為3類：

運營需求

運營部門是銜接產(chǎn)品和用戶的橋梁，有時候再細一點會分為用戶運營和產(chǎn)品運營。運營在和用戶溝通的過程中，會直接的成為用戶的吐槽目標。用戶說：“你們這個功能怎么用啊？”運營mm：“你好，這個功能balabalabala”，在這個過程中，運營mm知道了用戶覺得這個功能不好用。但往往產(chǎn)品經(jīng)理卻很難有精力注意到類似的對話。很多這樣的功能改進意見，第一發(fā)現(xiàn)者是運營。那么運營便會將該需求提給產(chǎn)品，由產(chǎn)品對該需求進行管理、評定、實現(xiàn)等工作。

戰(zhàn)略需求

戰(zhàn)略需求，說白了就是BOSS提出的戰(zhàn)略層面的需求。這部分需求，作為產(chǎn)品經(jīng)理，當然可以質(zhì)疑其合理性，但往往需要堅定不移的去執(zhí)行。也許，從產(chǎn)品層面上思考，這并不是一個合理需求。但老大思考問題的高度，可能會從各方面去權(quán)衡?！靶『⒉欧謱﹀e，大人只看利弊”。就像最近很火的人工智能音箱，各大廠商，都開始著手布置自家的人工智能產(chǎn)品，與其說是新需求，不如說是戰(zhàn)略性的防御。你不做，別人便會做，到時候侵占的是本屬于你的市場份額。大到產(chǎn)品，小到功能。往往BOSS提出的要求，都需要產(chǎn)品經(jīng)理站在更高的角度去俯視這樣一個需求。

迭代需求

回歸自我，作為一名產(chǎn)品經(jīng)理，應(yīng)有著自己的迭代節(jié)奏，在 什么階段，出什么需求，做什么功能。每次迭代更新的目標究竟是什么，都應(yīng)有著清晰的規(guī)劃。比如前期，產(chǎn)品不完善，體驗不佳，應(yīng)本著“小步快跑”的節(jié)奏，迭代頻繁一些，讓整個產(chǎn)品在每一次的更新中，都有著最直觀的改進。而到了有一定用戶量，活躍度的情況。就應(yīng)該想著如何去維持現(xiàn)有的活躍，是否要搭建用戶激勵體系，去提高當前用戶的活躍度。是否要構(gòu)建內(nèi)容型社區(qū)，來充實整個產(chǎn)品的UGC氛圍。這些都是在產(chǎn)品不同階段需要去規(guī)劃的需求方向。

這么多需求，如果來一條，想一條，一會就都亂掉了。最好的辦法是把他們歸納在一起。根據(jù)版本迭代的節(jié)奏，去決定哪些需求，在什么時候去實現(xiàn)。用一個簡單的Excel表格，將每一項都填寫完整，區(qū)分該需求屬于優(yōu)化部分還是新功能部分，然后通過顏色去區(qū)分當前的進度。綠色代表已實現(xiàn)，灰色代表被擱置，藍色代表正在開發(fā)。簡潔易懂，清晰明了。每次新版本規(guī)劃時即可從這個需求池里提取需求。

項目進度的把控

還記得校招時，群面環(huán)節(jié)有一個角色叫做Timer，負責計時間，把控進度的。當時并不理解這個角色的意義所在。但在實際工作中，才發(fā)現(xiàn)能讓一切進度按規(guī)劃順利進行很不簡單。

由于一個項目往往牽扯到多個部門的協(xié)作，因此整個項目進行下來，極其依賴于各個部門之間的配合。就拿現(xiàn)在大部分互聯(lián)網(wǎng)公司的項目流程來說吧。一個需求或項目從立項到完成，往往需要產(chǎn)品、設(shè)計、開發(fā)（前、后端）、測試配合。

可以看出，在項目的不同階段，產(chǎn)品經(jīng)理都有著不同的工作目標。而每個階段的時間節(jié)點，也是由產(chǎn)品經(jīng)理去把控。這就要求了產(chǎn)品經(jīng)理對時間管理有著極其嚴格的要求，否則很容易出現(xiàn)項目delay的情況。

（1）第一次評審

每一次項目立項，產(chǎn)品經(jīng)理在準備充足的前提下，需要主動召集相關(guān)人員去針對此項目進行討論?；诋a(chǎn)品經(jīng)理已出方案的情況下，每個部門都應(yīng)有種參與感，對其方案進行評定，站在技術(shù)角度上，站在視覺角度上，站在運營角度上，這樣子產(chǎn)品經(jīng)理才可以綜合各方面去評定該方案的合理性。這便是第一次需求評審的目標。

（2）調(diào)整期

最終結(jié)果應(yīng)是產(chǎn)品經(jīng)理去做調(diào)整，而設(shè)計應(yīng)根據(jù)已有結(jié)果的原型圖，去重新設(shè)計最終的效果圖，值得注意的是，在這個過程中，產(chǎn)品經(jīng)理應(yīng)減少對視覺效果的干預(yù)，并不是說不注重細節(jié)，而是應(yīng)將精力重點放在功能層面，各司其職。與此同時，開發(fā)也有著手準備開發(fā)方案，以此來確認開發(fā)排期。

（3）第二次評審

應(yīng)不再對功能層面上進行討論與修改?；谧罱K的效果圖，針對各種細節(jié)進行討論與確認，避免需求不明確的坑。開發(fā)也需要確認實現(xiàn)方式及技術(shù)方案，并給出產(chǎn)品經(jīng)理開發(fā)周期。這樣最終在需求層面上，產(chǎn)品經(jīng)理和各個部門達成一致，并對整個項目開發(fā)時間和測試時間掌握詳細的排期情況。正式進入開發(fā)階段。

（4）開發(fā)階段

最容易出現(xiàn)問題的就是開發(fā)階段，錯誤評估開發(fā)難度、開發(fā)結(jié)果與實際出入很大。這些問題均會產(chǎn)生一系列連鎖反應(yīng)，可能導(dǎo)致測試階段無法正常進行，或?qū)е马椖緿elay。但這并不是說一定都是開發(fā)的責任，產(chǎn)品經(jīng)理也要承擔一定責任?？赡苡捎诋a(chǎn)品的需求不明確，或漏掉了效果圖上的交互細節(jié)。

因此，基于以上的問題所在，產(chǎn)品經(jīng)理需要定期去了解項目開發(fā)進度，把控開發(fā)時間。

比如說，開發(fā)說可能要延期，那產(chǎn)品經(jīng)理需要知道延期的原因。到底是開發(fā)評估時間過少還是中間有新的需求插入。如評估時間過少，要了解是什么原因?qū)е碌模情_發(fā)前期疏忽漏掉了一些功能的工作量還是其他什么原因。如是新需求插入，則需由產(chǎn)品評估需求的優(yōu)先級。在此過程中，要有合理的掌握度，既不能對項目進度完全不知，又不能頻繁的去問開發(fā)，以免因打斷開發(fā)思考而被打。最好是在項目開發(fā)中間階段，抽時間和開發(fā)開個項目進度會，了解一下當前進度，并對開發(fā)階段遇到的問題進行引導(dǎo)、解決。

（5）測試階段

請一定在提測前，先自測一遍，這應(yīng)是產(chǎn)品經(jīng)理的基本素養(yǎng)。如果連最基本的功能都沒有完成，那其實根本沒有達到提測的要求，因此，在測試進行全面測試前，先將本次的需求點自測一遍，這樣可以最大限度的將測試時間花在更多的細節(jié)上。在測試階段時，產(chǎn)品經(jīng)理應(yīng)抽出一定精力去著手下一個版本的需求整理了，因為如果遵循“小步快跑”的節(jié)奏的話，基本測試結(jié)束，也就意味著下一版本的開發(fā)正式開始了。

整個項目流程中，每個參與人員，都沒有完全的空閑時間。而產(chǎn)品經(jīng)理，是將他們穿織成一條線，又繞成一個循環(huán)圓的角色。

寫到這里，基本也就是我在項目管理中遇到問題的總結(jié)，不同公司、不同項目的流程可能會存在一些差異，但產(chǎn)品經(jīng)理要有一套自己的流程標準。這樣才能更有序的去管理項目。

#專欄作家#

王偉華，微信公眾號：夜漫產(chǎn)品（learnerwwh），一只略帶文藝情懷的產(chǎn)品汪，擅長社交，資訊領(lǐng)域產(chǎn)品，心理學(xué)愛好者，目前正處于知識體系搭建階段。

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