起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求評審會后，產品經理的工作有哪些？
開需求評審會后，需求評審達成一致，進入研發階段。沒有需求設計的產品應該充當什么角色、干些什么呢？
目錄：
一、需求評審后所處階段
首先一個小產品功能落地到使用共四個階段：采集需求——分析需求、設計需求——研發期——運營使用期（然后從采集需求開始循環）；而需求評審所處分析分析需求、設計需求階段。
需求評審會后，我們處于分析需求、設計需求階段，階段向研發期過渡，那么在研發期作為產品應該做些什么呢？
二、需求評審需要做些什么呢？
1. 總述
具體共四個大步驟：完成需求評審會待解決問題、跟進項目、準備項目上線、項目上線步驟，詳見下面。
2.?詳細
2.1 完成需求評審會待解決問題
需求評審會，對于產品經理，是講述自己的需求原因和實現的主要步驟、邏輯；對于技術、測試，是評定、審核需求是否有必要做、以及實現方案是否有漏洞的會議。
- 在這個階段有可能產品的需求，因為想法不合理、開發等資源達不到被斃掉（當然這個問題，可以通過事前私下溝通避免）。
- 如果需求沒形成閉環，遺留問題過多；需要產品重新完善邏輯，然后進行二次需求評審。
- 如果資源到位，產品基本邏輯能走通，會對產品邏輯、實現的方法、各種正常異常各種情況下的邏輯和實現可能性、實現成本進行討論。
ps：私下溝通很重要，私下溝通可以解決很多問題：
對于產品，可通過私下討論知道自己的想法是否合理、缺失的問題、以及各種實現成本，從而做到心中有數；對于技術、測試等同學，增強他們的項目參與感，并且讓他們有所了解，及時提出問題進行溝通。
最終，有一個大圓滿結局，不至于把產品需求評審會開成產品需求批斗會。不過私下討論溝通也是大體上，僅限于各端，各端一起實現這個功能，還是有些需要統一開會解決。
需求評審完，把遺留問題要進一步確認、解決，而后同步給各方。要注意及時同步，以及參與人員的周知；可用發集體郵件的方式和在公共群里@所有人的方法通知，并且要得到大家的回復確認。
2.2 跟進項目
2.2.1 制定項目計劃和排期
制定項目計劃和排期，是為了功能需求按時按需的完成，主要考驗項目管理能力。在項目不能完成時，要及時預警并采取有效解決方案。
2.2.1.1 排期關鍵點
明確項目總計劃、制定關鍵節點（時間和人）
2.2.1.2 排期注意點
確定總目標，進行子目標拆分，注意拆分到足夠細，以便把任務量化到人。
注意多端和上下游的問題。特別是一些需要調取外部配合的數據，需要及時的準備協調好資源。
2.2.1.3 排期通用模版
個人模版：以下是平常工作中用到的簡單模版，主要給產品自己看，供參考?，F在也有很多專業的排期管理平臺可用。
注意：其實，明確排期關鍵點、注意排期要點最重要，把控進度，讓需求功能準時上線最重要。不要陷入排期管理的呈現細節，注重了形式，而忽視了結果。排期的呈現形式表格，只是輔助。
2.2.2 其他需要推進的需求
需求評審會后，還有些流程，需要產品經理參與和推進，項目參與角色有：設計、測試、開發、產品。主要任務有：設計評審、測試評審、開發聯調、驗收（測試驗收、產品驗收）。
2.2.2.1 設計
前期：原型交付，進行設計——（設計比稿，進行細化）——驗收設計——進行設計、切圖
后期：在最后驗收階段，需設計走查是否符合規范。
補充：如果是大型迭代，會有多個設計參與，出具多種方案。
2.2.2.2 測試
根據需求文檔，測試會出具測試用例，并開測試用例評審會。
參與人員：包括開發、測試、產品，然后進行細節的補充、修改。
開完測試需求評審會可做的：并將測試用例給開發，讓他們知道測試要點，并可進行一些簡單自測。
2.2.2.3 開發
A 開發遇到問題類型
主要分為開發中遇到問題、快開發完成時遇到問題。
B 開發中遇到問題和解決方法
開發中遇到問題，可能是開發過程中發現不能按計劃完成；主要是排期過短、人員過少。最直接的是向老板提出，增加時間和人員；若時間、人員不可解決，那么就是砍需求功能了。
C 快開發完成時遇到問題和解決方法
對于快開發功能，測試會進行驗收。測試匯總所有bug，bug類型為：開發自己編碼出的bug、未實現的排期功能。需要產品、開發、測試一起協商，并對本次所有細節需求功能進行確認。
如沒問題，產品注意及時了解進度即可。如有問題，產品能自己把控，排出必解的bug；如不能解決（重大延期等，注意及時向老板預警，尋求資源幫助）。
2.2.2.4 產品
A 怎么跟進項目，有哪些標準？
及時跟進進度，大迭代、多個功能進行開發時，及時安裝開發包，及時體驗，如有錯誤及時更改。
當領導問起時，能清楚說清節點，。
B 需求更改，各方扯皮怎么辦？
進行功能項目中途，難免會遇到需求上錯誤缺失的小問題、開發對于一些實現上有扯皮。
產品私下調研，給出解決方法——拉涉及所有端的開發集體討論可行性，如不可再集體討論出結果——做出取舍后，同步給所有人（開發、測試）結果；以郵件或者群同步的方式——并更新需求文檔
C 有哪些需要溝通注意的？
及時給出解決回饋，如不能立即解決，也要給出解決的時間節點并告知相關人員。
2.3 準備項目上線
產品除了設計產品功能，還需從0到1推動產品需求實現，開發完成后，產品需參與到產品上線的全流程中，并推動全流程的進行。那么產品上線全流程是怎樣呢？
2.3.1 產品上線發版的全流程？
一個產品正式上線，流程上，需開發提交正式包 → 供測試同學測試封板、供安全審核團隊審核（若是新品流程，還需申請新app申請等，此處不再展開）→ 測試對于封板包，發測試測試結果郵件；安審對于封板包，發通過郵件 → 產品對于測試封板包，發產品確認上線郵件
完成這個流程，才算能對外正式上線發布此版本。（具體公司可能上線流程不同，但基本遵循此步驟）
2.3.2 產品驗收產品功能的主要內容？
測試驗收完成，還需產品驗收，產品驗收主要包括：主流程、分支流程、逆向流程、重大關鍵節點。
to c 產品可參考xiaopiu網站的產品自查手冊，網址為https://www.xiaopiu.com/h5/byId?type=project&id=5ce262e596541012dae2aec4&isprd=true
2.4 項目上線
2.4.1 對自己，需進行復盤
一個有經驗的產品，肯定踩過非常多的坑；但是踩過很多坑的產品，不一定會成為有經驗的產品，重點在于總結復盤。那么總結復盤的意義是什么？怎么總結復盤呢？
2.4.1.1 總結復盤的意義？
復盤對于自己最直接的好處，對于失敗的項目，找到原因改正錯誤，避免犯同樣的錯誤，下次更好的完成項目；對于成功的項目，找到可復制方法即找到規律，固化流程和做法、從“蒙著打”到“瞄準打”；并且要從失敗和成功項目中，努力發現新的知識和思路。
2.4.1.2 復盤的方法？
復盤共四個步驟：回顧目標，評估結果，分析原因，總結規律。
具體方法：盡量量化結果；精簡語言
呈現形式：看匯報對象，如果給自己，建議電子版腦圖、word等，自己習慣，方便、快捷、便于日后查詢既可；如果給領導，可用ppt展示。
如果想更多了解，推薦參考書籍：《復盤：對過去的事情做思維演練》
復盤才可以更好的讓人成長，變成有經驗的產品。
2.4.2 對他人，收集意見
2.4.2.1 收集意見對象？
公司內部人員；外部行業人員
2.4.2.2 向公司內部人員收集什么？
to c 主要看此版本發布情況后，用戶對此的反饋。代表用戶的公司內部人員的反饋，主要是運營、市場、銷售等最接近一線用戶的同事——他們最能了解用戶的想法。但要注意數據樣本選取，對照組的正確；并看大多數用戶的想法。
此處收集意見的目的，根本是為了用戶增長，推薦參考書籍：《我不是產品經理：移動互聯網商業模式下的用戶增長》。
2.4.2.3 向外部行業人員收集什么？
一個功能，有的時候具有重要的意義，比如代表app調性、具有某個戰略意義，所以可以看外部行業人員對于此功能的反饋。反饋包括公開的意見建議和他們負責的競品功能是否因此有改進。
完成對自己進行復盤、對他人收集意見，才能算是一個項目功能完整做完。當做完后，又進入了第一步采集需求。
三、附錄
1. 通用模版表格參考
2. 推薦書籍
①to c產品自查：xiaopiu網站的產品自查手冊，網址為https://www.xiaopiu.com/h5/byId?type=project&id=5ce262e596541012dae2aec4&isprd=true
②復盤：《復盤：對過去的事情做思維演練》
③數據分析、用戶增長：《我不是產品經理：移動互聯網商業模式下的用戶增長》。
作者：董小圓；公眾號：dy1820268
本文由 @董小圓 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
- 目前還沒評論，等你發揮！
