需求文档的注意事项

产品需求文档（PRD）定义了产品的功能、逻辑、交互等关于产品的一切，工程师基于此进行开发，测试基于此写测试用例，它的重要性不言而喻。这里说说写 PRD 的一些建议和注意事项

1. 不要用 word、用 wiki

一些大厂的产品经理还在用 word 写需求文档，他们会在文档顶部说明修订时间、作者以及大致的更新内容，看起来很规范。确定最终版后，使用邮件或 IM 将文档发送给相关的开发、测试人员。

Word 版 PRD 的版本更新记录

使用 word 写文档有以下缺点

1. 不支持全局搜索和即时预览。随着产品的迭代，文档越来越多，查找会越来越不方便，在邮件或 IM 中需要下载下来重新打开查看，手机端查看和修改更加麻烦。
2. 版本管理不便。需要修改时候，修改对应的内容后需要重新发邮件给所有人，如果有很多次版本迭代，很容易就混淆究竟哪个才是最新版。
3. 不利于离职人员交接。当一个同事要离职时，需要把所有他负责过的 word 文档整理出来交接给另一个人，如果没有处理到位，一些历史文档就丢失了。

wiki 系统中， Confluence 是不错的选择，支持全文搜索、每次保存都有记录，无需手动撰写版本记录，支持树状层级结构，权限控制也可以做到非常细致，这里强烈推荐。当然，如果你们团队使用 Teambition、Tower 等在线协作工具，可以直接使用其自带的文档管理工具。

Confluence 的版本记录功能

2. 需求文档是碎片化的，不是大而全的

我曾见过上百页的 word 版需求文档，打印出来简直就是一本书。它的缺点很明显：传递起来太过笨重，在文档内查找定位繁琐，最重要的是，开发人员讨厌这种复杂冗长的文档。

我的建议是，利用好 wiki 系统的树状层级结构，将不同的功能模块进行合理划分，放在不同的目录树中。未来有新的需求，直接在对应的目录下新增文档即可。

3. PRD 是动态的，一定记得及时更新

虽然大家都讨厌需求变更，但在实际项目中却又无法避免。需求变更后，最先做的则是更新需求文档，即使没有需求变更，产品也是不断更新迭代的，对应的产品文档也需及时更新。

很多产品经理经常忽略这件事，以至于一段时间过后，产生很多需求文档和产品线上版本很多不一致的情况，团队有新成员加入或有人离职，又增多了很多解释和说明的成本。