因項目不同，成員不同，不同團隊會有不同的需求管理方法。本文從七個方面，結合作者自己團隊所採用的產品需求管理規範，來跟大家談談版本的需求管理。
需求管理是產品經理工作內容當中的重中之重，好的需求管理能有效推動需求的開發上線，與開發測試間建立健康的工作流程。而不規範的需求管理，容易造成需求過度飽和、需求優先級不明確、臨時插入需求、需求質量低等問題。
我所在團隊採用敏捷開發，我作為每個版本的責任人，根據團隊基因制定了一套產品需求管理規範。
正常是兩週一版本的迭代速度，共10個工作日，在這10個工作日中，產品測的工作安排如下：
1）如圖所示的版本週期為本週五~下下週四，週四發佈版本。
2）在版本開始的前一天，版本責任人會號召全員進行版本啓動會。
該啓動會必須全體開發、測試人員到場，啓動會的目的是向所有成員介紹我們下期版本的需求，簡要介紹需求背景、目的、內容和價值。這個啓動會能讓開發在上一版本和即將開始的版本之間起到一個過渡作用，同時也能讓所有成員對下一版本的規劃有整體的瞭解，提前先了解需求，避免直接進入需求評審。
3）在版本的第一天和第二天，產品經理與開發測試完成正式的需求評審。
此次需求評審需要達到：
4）版本開始的第三天至發佈的前一天，每個產品都將跟進本版本的需求進度，同時需要收集分析下一期的需求。
5）在本版本開始的第五天，版本責任人需要號召項目內所有產品開始下一期需求的排期。（由於項目特點和客户性質，我們很難提前一個月/季度就制定好下一週期的需求）。
排期的目的是：
6）下一版本開始的前2天，如果下期需求中有大的功能模塊、運營推廣測產出的需求、涉及系統底層邏輯的需求，則版本責任人要監督開展需求內部評審會議，對應產品經理也要自主安排內部評審。
由於系統功能模塊是由不同產品人員負責，先經過一輪內部需求評審，能避免需求遺漏的地方，正式需求評審時才能更加順暢。
7）之後下一版本開始，正式需求評審，重複2~6步。
因項目不同，成員不同，不同團隊會有不同的需求管理方法。以上的需求管理流程是在多次適用中目前較符合我們團隊的一套需求管理規範，在其他團隊中看來有很多不合理之處，我們也仍在不斷的探索改進當中。
歡迎和我探討和指點吖！
作者：悦悦；微信公眾號：大話熙遊
本文由 @悦悦 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議