产品需求文档在迭代阶段怎样管理？

产品经理在完成一个大项目后接下来会遇到后期产品的更新迭代问题，请问这些后期更新需求的文档怎样管理？近期产品迭代较快，求高手大牛指点

我自己是按文件夹来：项目名下按照不同文档或资源设多个子目录，其中一个是需求文档，需求文档下按版本号再区分目录。我自己的需求文档命名规则：项目名-需求所属模块-日期

如果文档存在修改，就在文档内，加一个文档版本，修改日期，注明修改人，注明修改内容。

我接触过好几个项目，其中有不少都会使用Git来管理各类的文档，也自然包括需求文档，而所有的文档通常都会采用markdown或latex来进行编写，方便直接查阅或比较差异。

没有最优解，一般重写更便于管理。

建议：

1、不同期一版本目录中记录所有修改list（如项目名，模块，版本号，日期，变更人，变更内容），内容中只记录该最新版本的（各功能特性注明需求场景、操作用户、操作路径、数据来源、用户界面、界面描述、补充说明等）

2、同期优化修改的可直接在原文档中修改（加入文档版本号，修改日期，修改人，内容）

3、项目周期较长，提供辅助说明文档，用于进一步分类各模块历史修改list（不涉及详细内容）

4、内容上，可以每半年/一年梳理系统功能最新文档。

我一般会单出一份版本的需求文档，并且把版本修改内容更新到整个项目的需求文档之中，保证项目需求文档为当前最新内容，并且每个版本修改的内容也能被单独的找到

版本号命名文件夹呀，同一文档中只记录该版本修改的记录哦~

谢邀！两种方式，第一种按照版本号去走，V2.0.1 V2.1.3等等，即时某个功能迭代到第二版，那也是跟著一个更新发版上线的，所以你可以按照版本号去走，顺便这个版本可能优化个其他小功能点。这样做的好处是，以后你回顾的时候，直接按照版本，去复盘即可，能清楚的知道哪个版本什么时间上线的什么功能。第二种，就按照功能线走，这个比较混乱，我不建议用。就是某个功能一期、二期、三期等都放在一个目录下，那什么版本上的这个功能呢？不知道。我推荐第一种，一定要注意文档的名称，你可以写XXXX功能二期，这样结合版本号就能很好的整理归档了

良好的命名规则以及细心的分类。

我工作的时候似乎没有遇到类似问题，可能是因为我们有文档管理工具项目经理。

那么可以从这两点来解释如何管理大型项目的二期、三期需求。

首先，无论在这个大型项目完成后有多少新增的需求，总会有一个预计的二期发布时间点；

在这个时间点确定后，就可以去安排二期的需求点。有时候这两个环节是同时进行的；

二期需求点确认，发布时间点也确认，接下来的需求安排，其实就和普通的版本类似了；

以上是PM需要做的事情，而文档管理工具，则帮助你确认当前更新的需求文档属于哪个迭代、产品、开发、测试；

到这一步，其实后期需求也很好管理了~要做的只需要管理需求list即可

从头到尾有一份需求文档即可，后期更新的内容以不同颜色标注出来，并记录更新日志。使用SVN的话，可自动记录版本号，并可查看制定版本。

这里的同志们似乎都没有遇到过需求失控引发的项目工期失控。

我有一个建议，在遇到失控的时候，需求变更一定要纳入基线管理。修改需求要有变更过程。

以版本号命名，将更改内容以条目的方式列清楚，注意文档的保存与版本号的对应即可。