项目在做的时候，文档到处都有，需求文档在对接人电脑里，会议纪要在聊天记录里，设计稿在设计稿平台，部署说明在开发方那边。项目一结束，人员一散，这些文档就找不齐了。
两年后要查一个当初的约定，或者新来个同事要熟悉系统，才发现手头什么都没有。
一、文档按四类归
第一类是需求类，包括需求说明书、原型、变更记录、待定项清单。这类文档记录了系统应该做什么，是后期判断某个功能是不是漏做的依据。
第二类是设计类，包括界面设计稿、数据库设计、接口文档。这类记录了系统是怎么做的，接手维护的人最需要。
第三类是过程类，包括会议纪要、评审记录、测试报告、验收记录。这类看起来琐碎，但出现争议时靠它说话。
第四类是运维类，包括部署手册、账号清单、配置说明、常见问题处理。这类是日常使用中翻得最多的。
二、每类文档该由谁保管
需求类和过程类应该由甲方保管。这两类涉及双方的约定，放在甲方手上最稳妥。每次会后由甲方整理纪要并发出，形成习惯之后文档自然就攒起来了。
设计类和运维类由开发方产出，交付时一并给甲方。给了之后甲方要存进自己的知识库，不能只是收在某个邮箱里。
最简单的落地方式是建一个固定的共享目录，按上面四类分文件夹，约定所有相关文档都放进去。目录地址在项目启动时就告诉大家，之后所有文档只往这里放。这一条比任何文档规范都管用。
三、别指望文档写得像书
很多项目要求文档必须严格按格式写，结果是谁都不愿意写，最后草草了事。文档的价值在于准确和找得到，不在于排版。
可以用一个轻量的约定。每份文档开头写清楚这是什么、谁写的、什么时间、适用哪个版本的系统。正文把事说清楚就行，不用纠结章节标题是否对仗。
会议纪要更是如此。一页纸，写清时间、参加人、讨论了什么、定下了什么、下一步谁做什么，比一份格式精美的长文有用得多。
四、让文档在项目结束后还能用
项目结束之后，最容易做的一件事是给系统建一份移交说明。把上面四类文档的存放位置、系统的访问地址、各系统的负责人、服务商的联系方式写在一页上。新人或者接手单位拿到这一页，就知道去哪找东西。
另外建议把运维类的文档定期更新。系统升级了、账号变了、服务器换了，都要更新进去。判断标准可以这样定，如果一个新来的运维人员只看这份文档能不能处理常见问题。做不到就说明该更新了。
还有一点，文档的过期信息比没有文档更麻烦。如果某个账号清单是两年前的，照着找会浪费很多时间。所以每份文档开头写明最后更新时间，超过一年未更新的，用之前要核实一遍。