在互聯網公司,，產品經理也充當項目經理的角色。每次產品迭代,，都是一場戰(zhàn)役,，而在項目管理過程中風險無處不在，如果我們知道接下來會有哪些風險,，那就可以提前準備做好預案,，從而大大減少我們產品迭代上線時間的風險,。

往往在項目管理的過程中，產品經理缺乏的是對項目有整體的全景認識,，此時需要產品經理提前考量各種約束潛在風險,，并且在一個個產品迭代過程中積累成體系的產品風險管理方案。針對于這樣的方式做產品風險管理,，可以大部分把風險降到最低值,。

一、列出潛在風險

產品經理應該和技術負責人,、運營負責人在項目初期階段,，把能想到的所有風險都列出來，先暴露風險并做好準備,。

健康的產品迭代流程,，風險系數是會隨著產品迭代過程呈現遞減趨勢，可控性會提高很多,。

風險點的挖掘可以從項目管理全路徑去發(fā)現,。項目管理是對人、財,、物,、時間的管理與協(xié)調，剛開始時可以從這四個緯度做簡單的挖掘闡述,。

在項目推進的過程中,，核心的里程碑事件如果要依靠到項目外資源的交付，那么就要做好風險預案,。如果外部資源交付出了問題怎么辦,，你的planB計劃是什么。

如果某件事不確定是否有風險點,，那么算作該事件有風險點,。風險控制是要保證潛在的風險點不發(fā)生或者發(fā)生后的解決措施。

John非常貼心的為大家準備了互聯網產品迭代常見的風險清單,。（風險清單一定是在項目初期過程中提前給各組干系人須知,，讓每個項目組成員提前感知潛在的風險，直到產出對應的解決方案）

（這張圖片求你們保存下）

二,、風險應對策略

1.需求篇

在產品迭代的過程中,，最怕出現了主要流程和核心邏輯調整，意味著技術前面預研和開發(fā)的項目全廢了,。這也是為什么在項目評審前需要加上技術預研的過程,。另外有一說一，產品經理在產品設計的過程中一定需要把控好需求的過程,。

秉承著三個原則：想清楚,、說明白,、動手快

第1個是一件事情能把它想清楚。任何一件事發(fā)生了,，產品經理能不能想到它底層的原因是什么,？它的根本是什么？

現在所有的電商平臺,，都想做直播電商,。其實直播電商本質是品牌方對私域流量渴望的體現，直播為工具,，電商為基礎,。直播電商重塑人貨場：

• 人：從主動消費變?yōu)楸粍酉M；（主播是誰很重要,，是否有帶貨的潛質,？）

• 貨：實現去中間商，拉近產品原產地,；（商品是否有吸引力,，價格和質量決定商品能否賣出去）

• 場：“千里眼+順風耳”的功能變成現實。（平臺服務和直播體驗以及下單流程就很重要）

第 2 個叫說的明白,。因為產品是整條線的那個牽頭人，如果一個產品人不能把你的想法這件事情的東西說明白,，就是能力很差,，不存在表達能力很差的產品經理。有一句話很經典,，希望所有產品經理都能記?。?/span>

如果你不能用簡單的話來完整表達你的產品/想法，證明你根本不了解/沒思考清楚,。

第 3 個是要有能力快速的去試,。這個試包括但不限于把產品搞上線讓用戶/客戶來用，也包括了可能做一個粗的原型,，也包括了可能去做訪談,，去做客戶的溝通。

做好這三個步驟,，迭代上線后很難出現無人問津的局面了,。可能你就會問了,，想清楚這件事極其的難,，如果能想清楚事情，就不會出現這么多死掉/曇花一現的產品了,。的確是,，那我可能就會反問你了,。你調研/拆解了多少競品，梳理了多少他們的運營大事件,。以及基于當時的環(huán)境為什么這么做,？——這兒其實在他們的產品版本迭代記錄中全部能找到。建議去看下你負責產品的競品歷史版本迭代記錄,。你會發(fā)現很多有意思的點,。

落地回來到項目風險的點中，一定要對需求琢磨琢磨再琢磨,。否則一切都是白搭,。

2.團隊協(xié)作篇

在《騰訊方法》這本書中，提到過一種團隊協(xié)作方法,，那就是建立團隊協(xié)作任務故事墻,。顧名思義，任務故事墻就是把團隊中每個人的任務故事分解成一個個的小任務,，然后貼在墻上,，使得項目信息變得透明化和可視化，從而方便團隊成員跟蹤進度,，提升協(xié)作效率,。

如上圖所示，一面簡潔的故事墻制作起來其實并不復雜,，最主要的元素大概就是以下四點：

• “任務負責人”列：這一列主要就是把團隊成員寫上,，比如產品、UI,、前端,、后端、測試等等,。方便團隊成員知曉每個任務的跟進負責人是誰,。

• “待辦事項”列：還沒有開始做的任務，負責人需要把當前版本的任務或者一些臨時需求添加到“待辦事項”列,，方便團隊成員清晰看到自己近期總共有哪些任務,。

• “進行中”列：正在進行中的任務，負責人需要把正在進行中的任務移動到“進行中”列,，方便團隊成員清晰看到自己正在進行的工作有哪些,。

• “已完成”列：已完成的任務，負責人需要把已完成的任務移動到“已完成列”,，方便團隊成員清晰看到自己已經完成的工作任務有哪些,。

這四個元素就構成了一面團隊協(xié)作故事墻，團隊成員通過添加、減少,、移動墻上的任務便簽,，就可以讓整個團隊清晰了解項目的進度狀況。

那么,，在每天站立會的時候,，每個團隊成員只需要站到故事墻前面，用語言講解和移動便簽相結合的方式向團隊傳達自己昨天做了哪些任務,，已完成和未完成的哪些,，今天又準備做哪些任務。

同時,，要注意的是,，對于各個成員之間相關度比較高的任務，負責人一定要及時向相關人員匯報進度,，比如說已完成的情況下要及時告知后續(xù)相關人員應該怎么做,。這樣的話，整個團隊成員就能夠對每個任務走到哪一步有一個清晰的認知,，也就有時間提前準備與任務相關的后續(xù)工作,。

舉例來說：后端在晨會上告知團隊后端接口即將開發(fā)完成，那么就可以提示前端開發(fā)等下就可以對接口了,。

當然,，在這個過程中，每位成員還可以把自己工作中的一些想法和心得簡單分享出來,，提出自己的看法,；或者說有什么困難，需要其他成員或者其他部門幫忙,，也可以及時提出來,。

當然里面還涉及到其他的問題,，其實就是和相關的人去溝通清楚,。事情最怕溝通，溝通過后,，事情就慫了,。

總結：回到根上來，產品迭代方案早期做好調研：明確用戶需求和產品方向,，減少后期的變動,；早點準備技術調研，讓資深技術人員根據項目實際情況做好最合理的技術選型,。對常見的風險（需求不斷新增,，代碼提測質量差，計劃排期不準，變更記錄不全未周知,，發(fā)布流程不規(guī)范等）,，可以用對應的更完善的流程來緩和和預防問題的發(fā)生。

以下是專業(yè)項目經理給的方案：

• 規(guī)定在一個固定時間盒不接受新增需求：采用集中評審代碼,，安排多次代碼評審,，打通Jira和Git倉庫做好功能跟進，擴大冒煙測試用例范圍,；

• 適當改變項目的功能范圍,，保證計劃上線；計劃排期充分考慮到節(jié)假日,，學習,、開會、評審等緩沖時間,；

• 維護好公共的需求變更記錄wiki頁面,， 建立項目各角色的聊天群組、郵件列表,，任何變動及時周知干系人,；

• 規(guī)范發(fā)布流程必備內容，包含Release note ,、Code review報告 ,、功能測試報告 、異常測試報告（若有） ,、性能測試報告（若有）,，另外要求開發(fā)負責人，開發(fā),，QA,，DBA等重要干系人務必參與評審給出意見。

三,、思考

我想以后對產品經理的能力要求越來越高,。這并不是說考了個PMP證書就可以了。而是在執(zhí)行的過程中深入到：這四步：定義產品,、設計產品,、研發(fā)產品和運營產品。

定義產品：首先要清楚你迭代的目的是服務于什么用戶/客戶,，他們的使用場景是什么,？總之需要清晰的梳理出：迭代的XX功能是為XX用戶在XX場景下使用的。

設計產品：基于場景拆分用戶的使用任務,，任務再會拆分為功能和交互,、內容和信息架構,，最終把它呈現到界面上。

研發(fā)產品：主要指界面設計,、技術研發(fā),，還應該有用戶體驗及可用性測試的部分。

運營產品：產品上線前后的基于產品的運營計劃,，產品的增長管理,、市場營銷、跟用戶之間不斷的互動過程,。

希望能夠幫到你,。記得三連哦。（轉發(fā),、評論,、點在看）感謝了。

John為你準備了歷史文章,。真的建議小伙伴好好看看：（點擊圖片過去看原文）