因项目不同，成员不同，不同团队会有不同的需求管理方法。本文从七个方面，结合作者自己团队所采用的产品需求管理规范，来跟大家谈谈版本的需求管理。

01

需求管理是产品经理工作内容当中的重中之重，好的需求管理能有效推动需求的开发上线，与开发测试间建立健康的工作流程。而不规范的需求管理，容易造成需求过度饱和、需求优先级不明确、临时插入需求、需求质量低等问题。

02

我所在团队采用敏捷开发，我作为每个版本的责任人，根据团队基因制定了一套产品需求管理规范。

正常是两周一版本的迭代速度，共10个工作日，在这10个工作日中，产品测的工作安排如下：

1）如图所示的版本周期为本周五~下下周四，周四发布版本。

2）在版本开始的前一天，版本责任人会号召全员进行版本启动会。

该启动会必须全体开发、测试人员到场，启动会的目的是向所有成员介绍我们下期版本的需求，简要介绍需求背景、目的、内容和价值。这个启动会能让开发在上一版本和即将开始的版本之间起到一个过渡作用，同时也能让所有成员对下一版本的规划有整体的了解，提前先了解需求，避免直接进入需求评审。

3）在版本的第一天和第二天，产品经理与开发测试完成正式的需求评审。

此次需求评审需要达到：

1. 评审后与开发测试同学确定需求的story point；
2. 确定需求是否过大，是否要进行拆分，如是则要拆分story；
3. 开发需要给出需求的预计提测时间；
4. 本版本需求全部评审完成后，将严令禁止在版本中插入新需求；
5. 本版本需求全部评审完成后，版本负责人根据每个开发手上的需求、需求优先级、预计提测时间制定开发资源分布图，跟进版本需求进度。

4）版本开始的第三天至发布的前一天，每个产品都将跟进本版本的需求进度，同时需要收集分析下一期的需求。

5）在本版本开始的第五天，版本责任人需要号召项目内所有产品开始下一期需求的排期。（由于项目特点和客户性质，我们很难提前一个月/季度就制定好下一周期的需求）。

排期的目的是：

1. 明确下期需求；
2. 产品内部明确需求优先级；
3. 产品内部讨论出需求解决方案，对应需求责任人进行需求产出；
4. 项目leader对下期需求进行开发责任人分配；

6）下一版本开始的前2天，如果下期需求中有大的功能模块、运营推广测产出的需求、涉及系统底层逻辑的需求，则版本责任人要监督开展需求内部评审会议，对应产品经理也要自主安排内部评审。

由于系统功能模块是由不同产品人员负责，先经过一轮内部需求评审，能避免需求遗漏的地方，正式需求评审时才能更加顺畅。

7）之后下一版本开始，正式需求评审，重复2~6步。

03

因项目不同，成员不同，不同团队会有不同的需求管理方法。以上的需求管理流程是在多次适用中目前较符合我们团队的一套需求管理规范，在其他团队中看来有很多不合理之处，我们也仍在不断的探索改进当中。

欢迎和我探讨和指点吖！

作者：悦悦；微信公众号：大话熙游

本文由 @悦悦 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议