你是產品經理，也負責項目管理

來自專欄夜漫產品5 人贊了文章

你是產品經理

也負責項目管理

天天各種問題都要經歷

前腳方案被斃

接著開發就延期

新版上線實屬不易

即使這樣

踉踉蹌蹌

產品經理依然不一樣

我希望你

鬥志昂揚

仔細閱讀這篇文章

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

如今的大部分互聯網公司，是不怎麼區分產品經理和項目管理經理了。也難怪，它們的工作職責中是有很多重合的部分，因此，往往產品經理也會擔著項目管理的活兒。今兒，咱們就聊一聊項目管理的那些事兒。

運營mm:「老王，你看這個需求這一期能不能給俺加上啊，你要這期給俺做的話，我就答應跟你去看電影」

我:"嗯，別慌，容我考慮一下！"

運營gg:「小王啊，這期這個需求一定要給我加上啊，這都拖了快半年了，啥時候是個頭啊」

我:"急啥，下期一定給你加，這期的話，是不行了"

當然，作為一個鐵面無私的產品經理，一定是本著對需求負責的態度，那麼，對於這些來源於不同部門，像是一團散沙的需求，如何去整理歸類呢。

需求池的建立

需求這東西，就好比是一條條小魚，平時你不管它的時候，它活蹦亂跳，真正想去找它的時候，卻發現它消失的無影無蹤。既然這樣，我乾脆就把它們圈養起來。什麼時候想吃烤魚了，撈出一條就直接烤了吃，方便快捷。

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

• 運營需求

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

• 戰略需求

戰略需求，說白了就是BOSS提出的戰略層面的需求。這部分需求，作為產品經理，當然可以質疑其合理性，但往往需要堅定不移的去執行。也許，從產品層面上思考，這並不是一個合理需求。但老大思考問題的高度，可能會從各方面去權衡。「小孩才分對錯，大人只看利弊」。就像最近很火的人工智慧音箱，各大廠商，都開始著手布置自家的人工智慧產品，與其說是新需求，不如說是戰略性的防禦。你不做，別人便會做，到時候侵佔的是本屬於你的市場份額。大到產品，小到功能。往往BOSS提出的要求，都需要產品經理站在更高的角度去俯視這樣一個需求。

• 迭代需求

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

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

項目進度的把控

還記得校招時，群面環節有一個角色叫做Timer，負責計時間，把控進度的。當時並不理解這個角色的意義所在。但在實際工作中，才發現能讓一切進度按規劃順利進行很不簡單。

由於一個項目往往牽扯到多個部門的協作，因此整個項目進行下來，極其依賴於各個部門之間的配合。就拿現在大部分互聯網公司的項目流程來說吧。一個需求或項目從立項到完成，往往需要產品、設計、開發（前、後端）、測試配合。

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

• 第一次評審：每一次項目立項，產品經理在準備充足的前提下，需要主動召集相關人員去針對此項目進行討論。基於產品經理已出方案的情況下，每個部門都應有種參與感，對其方案進行評定，站在技術角度上，站在視覺角度上，站在運營角度上，這樣子產品經理才可以綜合各方面去評定該方案的合理性。這便是第一次需求評審的目標。
• 調整期：最終結果應是產品經理去做調整，而設計應根據已有結果的原型圖，去重新設計最終的效果圖，值得注意的是，在這個過程中，產品經理應減少對視覺效果的干預，並不是說不注重細節，而是應將精力重點放在功能層面，各司其職。與此同時，開發也有著手準備開發方案，以此來確認開發排期。
• 第二次評審：應不再對功能層面上進行討論與修改。基於最終的效果圖，針對各種細節進行討論與確認，避免需求不明確的坑。開發也需要確認實現方式及技術方案，並給出產品經理開發周期。這樣最終在需求層面上，產品經理和各個部門達成一致，並對整個項目開發時間和測試時間掌握詳細的排期情況。正式進入開發階段。
• 開發階段：最容易出現問題的就是開發階段，錯誤評估開發難度、開發結果與實際出入很大。這些問題均會產生一系列連鎖反應，可能導致測試階段無法正常進行，或導致項目Delay。但這並不是說一定都是開發的責任，產品經理也要承擔一定責任。可能由於產品的需求不明確，或漏掉了效果圖上的交互細節。因此，基於以上的問題所在，產品經理需要定期去了解項目開發進度，把控開發時間。比如說，開發說可能要延期，那產品經理需要知道延期的原因。到底是開發評估時間過少還是中間有新的需求插入。如評估時間過少，要了解是什麼原因導致的，是開發前期疏忽漏掉了一些功能的工作量還是其他什麼原因。如是新需求插入，則需由產品評估需求的優先順序。在此過程中，要有合理的掌握度，既不能對項目進度完全不知，又不能頻繁的去問開發，以免因打斷開發思考而被打。最好是在項目開發中間階段，抽時間和開發開個項目進度會，了解一下當前進度，並對開發階段遇到的問題進行引導、解決。
• 測試階段：請一定在提測前，先自測一遍，這應是產品經理的基本素養。如果連最基本的功能都沒有完成，那其實根本沒有達到提測的要求，因此，在測試進行全面測試前，先將本次的需求點自測一遍，這樣可以最大限度的將測試時間花在更多的細節上。在測試階段時，產品經理應抽出一定精力去著手下一個版本的需求整理了，因為如果遵循「小步快跑」的節奏的話，基本測試結束，也就意味著下一版本的開發正式開始了。

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

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