黄色网站在线,亚洲一区二区精品,奇米在线7777在线精品

搜索

APP

起點課堂會員權益

職業(yè)體系課特權

線下行業(yè)大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

互聯網產品運營體系總結之產品管理

菜根老譚

2018-01-29

2 評論 12180 瀏覽 96 收藏

15 分鐘

如果一個產品經理只關注創(chuàng)造需求而忽視需求實現的過程，那么這個產品也很難說會成功，因為執(zhí)行落地才是最重要的。

上篇文章《互聯網產品運營體系總結之產品設計》簡單從四個方面進行了總結：

確定產品定位——發(fā)展方向
確定商業(yè)模式——經營策略
確定產品架構——產品形態(tài)
確定產品賣點——運營重點

很多人說這個流程更適合初創(chuàng)產品，對于發(fā)展中特別是成熟期的產品，是不是就不需要考慮這么多了，其實我感覺不管是初創(chuàng)期的產品，還是迭代過程的產品，都可以用該流程去思考，這也是產品經理培養(yǎng)高階思維的一種訓練過程。當然對于每一部分，需要掌握的知識和技能也是非常多的，后續(xù)有機會我們會逐一總結。

好的產品策劃設計是成功的一半，但當我們滿懷希望憧憬產品上線的樣子的時候，卻經常發(fā)現，產品無法按期上線，開發(fā)出的功能和期望很大，過程中產品和技術打架，產品和運營相互吐槽，終究原因就是產品開發(fā)管理過程是混亂的，所以產品管理也是我們產品運營體系的一個重要環(huán)節(jié)，一個好的產品經理，不僅要具備創(chuàng)造性的思維和業(yè)務能力，也要具備工程思維和管理能力，所以產品管理體系我們從產品經理的主要職責作為梳理。

產品經理（負責人）要管理全周期

我們經?；煜a品管理和項目管理的概念，簡單的說，產品管理重需求（管理），強調產品實現的持續(xù)過程；項目管理重任務（管理），強調任務完成的整體協(xié)調。從管理周期上來看的話，產品管理過程中包含了項目管理，而且一個產品管理過程可能包含了多個項目管理。我們通過下圖來了解產品管理的主要過程：

一個產品功能的開發(fā)要從需求探查開始找業(yè)務機會，產品經理要負責召開需求評審，確定產品可行性。一旦產品確定開發(fā)，產品和技術將并行進行方案的設計，特別對于技術要求比較高的產品，技術的可行性調研和架構就要開始，同時產品團隊將需求和業(yè)務場景結合，設計最終的產品形態(tài)。這幾個過程就是我們在第一篇文章中所涉及的部分。接下來進入開發(fā)測試過程，在這個過程中很多產品經理會犯的一個錯誤就是認為這個管理過程屬于技術團隊，就和自己沒關系了。這種想法是不對的，產品經理要對產品最終的結果負責，為了保證自己想要的結果，需要和技術團隊進行密切的協(xié)作，監(jiān)控整個開發(fā)過程，協(xié)調相關資源，共同保證產品交付。

一個項目目標的實現就代表項目過程的結束，而產品管理過程卻是一個不斷迭代的過程，因為一旦一個版本的產品投入市場，也就意味著通過市場和運營的反饋將產生新的需求和調整，一個新的過程又開始了。

所以，產品經理不僅僅和技術團隊協(xié)作生產，同時要和市場、運營甚至是用戶等各種角色的人進行協(xié)作，來保證產品持續(xù)的生命力。我們常說，產品經理是沒有權利的小CEO，這話一點沒錯，他需要非常全面的能力和協(xié)作，正如下圖一樣：

產品經理要做好版本規(guī)劃

初級的產品經理經常犯的一個錯誤是太關注自己的創(chuàng)意和需求，而不關注需求實現的過程。我在工作中也經常碰到產品和技術互掐，技術說按照領導期望的時間完成不了，希望產品減需求、分階段。而產品經理就不想減需求，他希望自己的創(chuàng)意能全部實現出來。其實這就是我們?yōu)槭裁匆霎a品版本規(guī)劃的原因：資源和時間的沖突。資源總是不夠的，時間也總是不夠的，為了保證產品持續(xù)的成果，我們必須要控制自己的欲望，合理的安排產品需求實現路徑。

既然要做產品版本的規(guī)劃，那么我們應該去規(guī)劃版本呢？

1.0版本很重要，這是產品的起點

新產品上來第一個版本從開發(fā)到上線時間相對較長。按照我們前一篇文章介紹的，此版本的功能一定要緊扣定位，重點要解決用戶痛點，不要貪多，貪多反而淡化了定位和產品亮點。比如微信最開始就是定位的移動IM，解決人與人連接的問題，所以微信第一版上線就非常的簡單，就是基于手機移動端的即時通訊，甚至這個版本連發(fā)語音功能都沒有。

大版本的規(guī)劃考慮戰(zhàn)略需求

首先看看微信的大版本的核心功能：

微信1.0：移動IM，圖片分享，微信誕生；
微信2.0：語音消息，視頻消息，微信成功的基礎；
微信3.0：搖一搖，陌生人社交；騰訊新聞等外部插件，平臺化初試；
微信4.0：萬能的朋友圈來了；公眾平臺上線；平臺化戰(zhàn)略正式開始；
微信5.0：微信支付來了，內容能搜索了，深入到人們日常生活，商業(yè)化開始；
微信6.0：微信生態(tài)，鏈接一切。

大版本規(guī)劃基本上都是基于每一步的戰(zhàn)略需要來設計的，其實對應的是公司的整體戰(zhàn)略規(guī)劃，基本上以年為單位。產品經理要深刻領會高層的戰(zhàn)略需求，并進行具體的產品功能的策劃設計，保證戰(zhàn)略的實現。

小版本的規(guī)劃考慮運營需求

大版本的周期很長，方向相對穩(wěn)定，即使戰(zhàn)略調整也并不是一早一夕就能完成，相對比較容易控制。大版本上線以后，接下來就是產品的小版本迭代了，如何來做產品的迭代呢？可以從以下角度考慮：

確定你的產品架構；
拆分架構實現的步驟；
根據步驟，確定需要的支持功能；
根據功能關聯耦合情況，拆分成需求story；
根據數據表現、人力、運營計劃、市場資源配合情況，確定版本story。

所以，小版本的規(guī)劃既要契合大版本的戰(zhàn)略需要，而且又要和公司其他業(yè)務部門緊密的配合，通過市場、運營甚至客戶的推動，共同制定迭代的版本計劃。在版本的迭代計劃中，新功能的產生和比較重大的變更，一般采用0.x版本進行管理，周期根據各自自己情況，控制在一個月到一個季度。bug的修復和小功能更新，可以采用0.1.x版本進行管理，周期一般在一周到一個月。在這種快速的迭代過程中，更需要敏捷的產品開發(fā)過程：

產品經理要管理好需求變更

上圖雖然很夸張，但是不得不說，產品和技術的戰(zhàn)爭很多時候都來自于需求的變更。雖然我們每次都做了版本規(guī)劃，但是很多時候計劃跟不上變化，所以需求的變更是不得不面對的，為了保證產品過程的有序，需要建立需求變更機制。

首先我們需要清晰的認識需求變化對項目的過程所產生的影響。如上圖所示的項目管理的鐵三角，直觀的反映了項目中各個變量元素的關系。所以，我們需要統(tǒng)一一下認識：

加/改需求，或者要延長項目時間；或者替換掉相等工作量的需求；如果又不想延長時間，也不想替換掉原有需求，只能找boss協(xié)調資源，增加成本，否則只能犧牲質量了。

除了思想意識的統(tǒng)一之外，做好需求變更管理我們還應該：

建立需求池機制

產品經理日常最需要關注的三個東西：當前版本、下個版本和需求池。需求池就是對于現在開發(fā)的版本的可量化的描述，就像水池一樣，水多了就溢了，水少了資源就沒充分利用，對于需求也是。既然可量化，產品經理應該對每個需求需要的開發(fā)人天和總周期人天要足夠明確，對于需求的優(yōu)先級和重要級別有個排序。這是我們合理變更需求的基礎！

建立需求的評審機制

對于需求變更一定不要著急動手，因為需求變更后影響到后續(xù)的所有環(huán)節(jié)，存在著很大的風險，這個風險既不是產品團隊承擔，也不應該讓技術團隊承擔，而應該是和產品相關的整個團隊共同承擔，甚至包含老板和客戶。所以需求的變更需要進行評審，評審的目的不僅僅是讓相關人都簽字確認，更多的還是讓大家再仔細的思考、討論，變更需求所帶來的風險，是不是要變更需求！所以需求的評審盡量各相關崗位的決策人都要參加。

統(tǒng)一需求的入口

當一個項目，失去統(tǒng)一的需求入口，當一個產品經理失去對入口的控制，意味著項目的失控。任何一個需求都不是孤立存在的，只有當需求入口統(tǒng)一，才能夠整體的判斷需求的價值，明確當前的資源使用狀況，合理的安排需求的實現關系。過去我一直在糾正運營人員直接向技術提需求的問題，運營人員的需求（除非bug）必須要經過產品經理，由產品經理統(tǒng)一提交給技術。