本篇文章我们讨论的主题是资料归档管理。文章只针对工作过程中的业务资料，谈一下个人是如何进行归档管理的，希望能够对您有所帮助。

为什么要进行归档管理？

从项目的角度来说

大多数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有归档管理，在大型项目中，需求的迭代变更将变的无据可循。

从产品汪的角度来说

我们先来看一下这个场景：

“他们要的黑不是黑，而是五彩斑斓的黑”（需求评审后，产品小哥仰天长啸……）

“内容评审了好几版，最终还是决定用第一版”（论产品小哥是如何猝死的……）

好了，皮一下，我们回到主题当中来。以上场景虽是玩笑话，但也是实实在在地源于生活。有些同学在工作中可能还未养成一些良好习惯，例如需求评审确定了新方案之后，修改原型或者文档就直接在原来的基础上进行修改了，未留存历史版本；再例如，在多次需求变更、方案优化的过程中，没有整理文件的习惯，文件一多，想找到某些内容就需要逐个文件地去查，逐个文档地去找。有木有对号入座的同学，请留言站位……

回到刚才说的场景中，正如以上所述，我们无法确定领导或者客户会最终会使用哪个方案，所以对于我们产品汪自身来说，养成良好的归档管理习惯，是非常有必要的。

归档管理哪些内容？

1. 获取的需求一定要归档

避免领导或者客户前后所说矛盾或者不认账，这是我们反驳的有力证明（虽然反驳不会有什么用…但是最起码不用背锅了，有木有）。都说程序猿害怕需求变更，身处需求一线的产品汪，何尝不是呢？

获取的需求一般都是word文档的形式，如果对于需求内容较多的同学，或者是口头需求的传递形式，大家一定要对需求进行整理。

整理模板可参考如下文件：

链接：https://pan.baidu.com/s/1vKDXlwAmzn1cnrCSR8VQGg
提取码：gcck
复制这段内容后打开百度网盘手机App，操作更方便哦

2. 思维导图建议归档

思维导图是属于功能概设方面的内容，是我们产品的整体框架。在后期来说，我们会根据思维导图来建立功能视图，这也是需求接收方（开发、测试、运营）了解产品的第一步。

3. 流程图、用例图需要归档

需求变了，方案变了，我们的流程图、用例图肯定也会改变。如果不对这些内容进行归档，难道我们还一个个地重新画一遍？（就算不累死，也会因为延期被领导祭天…）

4. 产品原型归档

Common sense，无需解释，如果有疑问或者异议的，建议转行……

5. 需求文档归档

Common sense，无需解释，如果有疑问或者异议的，建议转行……

6. 模板文件归档

所谓模板文件，是指系统中可能存在的导入模板、导出模板这些内容。归档一下，后期肯定能用的到。

7. 测试文档归档

产品上线之前，一般都会由产品汪测试验收的。这份测试文档可就重要了，从公司层面来说，产品汪需要保证开发出来的产品按照原先的设想进行实现；从个人层面来说，这不就是开发们的小辫子么，让我们产品汪抓住了，我们就嘿嘿嘿……

8. 参考资料归档

我们在思考设计的过程中，肯定会或多或少地对一些其他内容进行参考借鉴，这些内容可以归档保留一下，归档的方式也很简单，往这个文件夹里面塞即可……

归档管理的方式方法

归档管理的核心要素包括两点：通过建立文档目录控制分类，通过设立命名规范控制版本。

还有一个横切面也需要注意一下：也就是我们待评审的内容和需求评审通过的内容，这个也需要区分开。

文档目录控制分类

不废话，直接上图：

命名规范控制版本

我们逐个列举以上内容的命名规范，如有异议，欢迎探讨。

需求：

格式：系统名称/项目名称-需求名称-时间-需求源

释义：需要从文件名称上面可以直观地看出来，这是哪个系统或者项目的什么需求，是什么时间，谁发送给我的。

示例：用户管理-动态标签-20190520-人名

思维导图：

格式：系统名称/项目名称-功能结构图-时间

释义：功能结构图一般改动起来比较简单，命名规范能达到便于检索的目的即可。

示例：用户管理-功能结构图-20190520

流程图：

格式：系统名称/项目名称-（功能模块-）时间

释义：一般情况下，我们的文档是在原型完成后进行编写的，所以好多时候不同模块的流程图就在同一个Visio文件中完成了。此时我们在文件命名时，只需要命名到系统名称/项目名称即可，关于功能模块的列表，可以在Visio中进行区分。

格式：用户管理-（登录模块-）流程图-20190520

用例图：

同流程图

原型：

格式：系统名称/项目名称-产品原型-版本号-日期

释义：RP文档也会有不同的分类，例如交互原型，所以对于我们产品汪来说，“产品原型”几个字还是需要标注一下的。因为这些文件最终还需要上传git或者svn，可能会跟其他部门的文件混淆。

注意将未评审和已评审的文件放在不同的文件夹中。

示例：用户管理-产品原型-V1.0-20190520

PRD文档：

格式：系统名称/项目名称-PRD文档-版本号-日期

释义：注意将未评审和已评审的文件放在不同的文件夹中即可。

示例：用户管理-PRD文档-V1.0-20190520

测试文档：

格式：系统名称/项目名称-测试文档-版本号-日期

释义：我们都是以版本为单位进行测试的，此处只需留存底稿即可，因为该类文档，基本上不会存在来回修改的情况。

示例：用户管理-测试文档-V1.0-20190520

结语

好了，这就是笔者今天分享的内容。每个公司环境不同，每个人的习惯也会不同，笔者这篇文章的重点在于说明一下，资料的归档管理对我们大家很重要。

如果对大家有所帮助的话，也希望大家能够点赞打赏一下，笔者在此叩谢。

还是借用我特别喜欢的一句话结尾吧：“一个人能够走多远，关键在于与谁同行！”

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

题图来自Unsplash，基于CC0协议