无论是瀑布流，还是sprint形式推进，文档总是逐渐完善的。版本的控制，尤为重要。
文件命名法
每个产品都是持续迭代的，而每个迭代覆盖的功能（新增 or 更新，甚至有删除）改动是不一样的。文档的编号和命名就很关键，可以区分该文档属于产品的哪个迭代，修改了几个版本。
顾名思义就是通过文件名，来区分各个版本。简单的方法是，XX产品V1.0PRD_V2，其中V1.0是产品迭代的编号，后面的V2是PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。
文件命名法是不可或缺的，但应用不深。究其原因，是内部研发更关注：
- 文档是最新的，也就是PM所想即PRD所写
- 能快速定位修改点，例如增加了一个查询条件这种
文件命名法的版本号，在这方面帮助不大。所以只用于区分迭代，例如XX产品V2.0PRD.docx。
更新标识
前面讲的，研发过程更希望能快速定位修改点。所以，PRD要有更新标记，提高查找效率。更新标识一般是总分形式，改动说明概括本次修改点，然后查看具体的修改点
改动说明
这个近似于更新记录，基本上所有PRD模板中都有，大体类似这种样式：
| 日期 | 版本 | 修订说明 | 修订人 | 备注 |
|---|---|---|---|---|
| 2019-09-23 | 0.1 | 初始创建 | Oliver | |
| 2019-09-24 | 0.2 | 优先级变更，增加X功能 | Oliver | 从第二迭代移至第一迭代 |
但实际应用中，能认真写的人太少了。普遍结果为导向，就是项目/迭代准时交付。即便人员流动很大，只要系统不出问题，文档是没人去看的。
修订模式
这个是word自带的功能，以office2013为例简单介绍下。
首先，开启修订模式的路径，是菜单栏“审阅-修订-修订”：
开启完后，文档的相关修改，都会留下痕迹。每次更改之前，可以接收所有修订。这样就能让修订模式，记录下此版本的修改项。也可以一直修订，但是会导致文档很大。另外使用时候很卡，而且不容易定位修改点。
研发、测试拿到最新文档，可打开审阅窗格，路径为“审阅-审阅窗格-垂直审阅窗格”。打开后，可以看到具体的修订（双击可定位到对应位置）：
约定标记
这个是非常规做法，主要用于临时性的修改。根据墨菲定律，还是准备下。
主要有以下形式：
- 字体颜色的标记，如红色是修改项
- 字体的背景色，如黄色高亮是修改项
- 批注，相对于颜色改动，更有持续性。
颜色最为直观，推荐临时改动使用颜色：
至于批注，更适合下面疑问的标记
疑问标记
需求评审，基本是PM先介绍项目背景，概述修改点，研发初估可行性和工作量。然后研发查看PRD，再询问PM具体的疑问，效率会比较低。目前了解到，有以下两种形式
批注
虽然原始但非常有效的方法，用于标记对文档的疑问、意见，形成一问一答的效果，并留有痕迹：
系统辅助
Jira/Teambition/TAPD/禅道，都是比较知名的管理工具。以TAPD为例子，有各种的玩法：
- 作为项目管理工具使用，需求管理基本不用，还美其名曰敏捷。项目根据一期二期，拆分多个迭代。一个迭代一个需求，文档附在需求中。task用于开发测试的工时，缺陷主要管控Bug（需求问题较少），整体监控项目进度。
- 披着敏捷外衣的传统式项目。项目拆解多个迭代，迭代拆解多个需求。需求拆解story（细分功能，如列表查询、增删改、导入导出。story拆解开发task,如新增编辑、删除，测试工时也用task登记。用例线下Excel处理，缺陷用于管控需求缺陷和Bug。最终关注项目里程碑和交付，看板基本不使用
- 真正的敏捷，不描述了。看板，story、用例、燃尽图统统上，联合 DevOps和jenkins ，实现自动集成，快速部署。
