產品經理經理從需求評審到落地的流程，往往需要各項過程同步支撐，那麼如何包握住各個流程的細節呢？下面的文章帶大家去了解。
01
產品研發過程
網際網路產品研發過程：
一般可以把產品的過程分為：需求分析、產品分析、產品規劃、產品設計、產品落地。
- 需求分析：產品經理需要定義清楚目標使用者，透過各種方法接近和了解目標使用者，甚至變成使用者，儘可能全面、準確的找到使用者需求，並透過各種方法校正需求，逃出“偽需求”的魔咒，並根據技術趨勢、生態革新趨勢、時代變遷趨勢，來提前預判需求；
- 產品分析：產品經理需要對比行業市場競爭對手的情況，思考當前行業、市場環境和自身優劣勢，制定出合理的產品策略和周密的商業化策略，從而更好的切入市場，獲得立足之地並謀求長遠發展；
- 產品規劃：產品經理需要面對諸多需求，決策做哪些？不做哪些？先做哪些？後做哪些？
- 產品設計：產品經理需要協同設計師推進視覺設計和互動設計，並用最低成本進行快速迭代；
- 產品落地：產品經理需要協同開發人員一起，推進產品的開發、測試、部署、釋出，把控專案節奏，確保產品按時保質上線；
02
產品需求落地的管理過程
專案啟動：
好的開始是成功的一半，一個好的專案啟動能極大的提高專案的成功率，避免專案過程中的很多風險。
專案啟動的重點是需求宣講，說明這個專案為什麼要做，我們相比其他人的優勢是什麼？如果不做，使用者會損失什麼？專案的目標和預期以及這個目標大家認不認可？如何衡量結果好壞？讓大家知道你要幹啥、為啥幹、幹了有啥好處等。
專案的目標必須滿足SMART原則，專案目標是結束時我們衡量專案是否成功，需要一個清晰明確的目標指導我們判斷專案成敗。
需求評審：
需求評審需要講清楚需求目的是什麼？
解決方案方向是什麼？
大致的成本和收益，用來決定這個需求到底是否開始做。產品經理需要將需求描述明確清楚，讓開發、測試、設計等人員理解一致，對需求進行拆分，確保順利分工配合。
參考需求評審流程：
- 產品初稿：產品內部評審，給出核心主流程、核心產品解決方案，方案較粗糙；
- 技術初稿：開發前兩週和技術負責人過稿，主要是粗略評估技術障礙、技術工作量等；
- 產品終稿：在產品內部過審，給出完整方案，包括中高保真原型、完善邊界條件，完善異常case；
- 開發終稿：開發前一週技術過稿，主要是精細的講解需求；
在需求評審時，需要做到提前資訊充分公開並有會議邀請，關鍵人員到位，評審後關鍵參與人明確工作目標和職責。
產品經理需要進行重點資訊和問題等收集，並同時做好資訊公開同步及重大問題的單獨跟進等事項。
專案排期：
評審完後進入專案排期階段，對資源進行盤點以及對目標進行聚焦，和參與的同學溝通清楚投入度和時間節點，並讓開發、測試等人員給出排期。
一定要明確幾個重要的時間點：設計評審、測分評審時間、提測時間、產品驗收時間、釋出時間。在排期中遇到可能的風險要及時對外同步。
專案排期時可能會遇到以下問題：
- 排期時間過長。我們可以透過拆分需求、增加人力以及分階段進行開發等方式進行，並建議最小開發任務模組評估最好不要超過3人日 ；
- 其他專案排期衝突。首先分析衝突原因是因為產品節奏衝突還是人員衝突，確認好衝突原因後再共同協商總體排期；
- 重要階段未給足充分時間，如架構設計階段、系統聯調、測試等經常忽略項。需要我們提前協商好，和各個崗位人員溝通並做好協調；
研發階段：
排期完成後進入研發階段，大家精力都會集中在各自負責專案的模組上，開發同學輸出相關架構設計進行評審，測試同學輸出相關測試用例進行評審，需要做到重要的流程有圖、文字、用例覆蓋。
重要的設計方案和測試用例需要提前同步溝通討論是否存在可能的風險點，並及時做好相關的對外同步。
研發過程中產品經理應該及時進行資訊跟蹤，對於可能涉及到排期的調整，要及時溝通和調整，並進行相關進度彙報，如當前專案的進度、各個模組的進度、風險同步與處理等。
測試階段：
研發同學開發、聯調完成後提測進入測試階段，開發任務基本告一段落，剩餘的是測試bug修復，測試提交的的測試bug需要做到日清，不能按日清需要有原因跟蹤。
在測試過程中，開發同步進行code review，開發負責人對關鍵鏈路設計、流程日誌記錄等進行重點把關。
產品驗收：
一般測試完成進入產品驗收階段，對於ToB產品驗收的目標是檢查產品功能能完整性、產品體驗，產品驗收最多隻會佔可能不到整個專案case的一半，因此將產品驗收作為最後的質量兜底是不可取的。
對於ToC產品驗收的目標是全方位無死角覆蓋需求功能及細節，是對產品功能、細節、問題的最後一次的體驗。
驗收產品前可以進行一些準備性的工作如驗收產品驗收checklist、資料的準備、驗收問題列表、埋點驗收準備等幫助產品驗收。
需求釋出及覆盤：
以上階段完成，需要進入釋出階段，是整個流程中最重要的一環，釋出時需要注意依賴控制、時間節奏把握等事項，建立釋出群通知機制，產品經理隨時關注釋出動向，釋出完成後進行相關線上驗收。
釋出後的線上檢查需要注意是否會影響線上的功能和資料。
釋出完、線上驗證完畢，進行專案覆盤，覆盤起初設定的目標是否達成、過程中的優缺點等事項，釋出郵件或通知同步參與人員，讓需求有始有終，並及時安排慶祝（請下午茶慶祝、儀式感很重要）。
【其他的補充】
產品需求管理的衡量指標：
- 需求的吞吐量：團隊指定時間段內完成的需求數，可大體反應出團隊的產出趨勢；
- 需求的平均完成時長：需求從建立到終態的平均時長，時間越多，需求交付粒度越小效率越高；
- 新增缺陷的數量 ：統計時間段內團隊被新增指派的缺陷數量，結合存量缺陷以及缺陷平均解決時長，反應團隊產品的質量以及對於缺陷解決的效率；
- 缺陷的平均解決時長 ：缺陷從建立到解決的平均時長，表示解決缺陷的效率；
- 線上釋出的成功率：線上釋出成功次數與總次數之比，越高證明產品上線質量越高；
- 缺陷的 reopen 率 ：缺陷被 reopen 的次數與缺陷數目之比，該值越高證明修復缺陷的質量越差，reopen 率是表示產品質量的一個重要指標；
end
文章來自社群簽約作者:PM言語
