做项目的时候，往往最头痛的就是写文档、整理文档了。最近，在XX银行做项目，其实项目刚刚确定需求，本应该是轻松又愉快的时候，但是随之而来的一堆文档就让我头痛了。作为一个项目经理，难道不能把写文档的事情交给项目成员做么？遗憾的是，不能。因为没有人比你更熟悉项目的流程、交互逻辑、需求的关键点等等内容了。
两个方案可以解决：一是自己写；二是参照第一条。
经历了这么多项目，其实写文档是一个项目最重要的事情。为什么这么说呢？因为后来者都应该通过文档来了解整个项目，而不是通过做过的人口口相传。对！你没看错，就是口口相传。记得前面做的二期三期项目，到达现场之后，没有开发、测试、生产环境的说明文档；没有项目的需求文档；没有项目的运行维护手册；没有用户操作手册。一出现问题，都得打电话求助原先的开发者，关键是原先的开发者也记不清楚细节了.......所有的流程都得靠看代码、走测试。这样的项目是最失败的。
那么整个项目过程中有哪些重要的文档呢？
1. 会议纪要
每次开会分配的任务都有人假装不知道怎么办？每次周会制定的需求流程，会后就不认账了？会议纪要完美解决问题。写完后，发给各个干系人确认。没法假装不知道了吧。
2. 项目周报
每周的工作进度要及时向公司汇报，本周计划、本周工作、下周计划、项目状态等是需要体现在项目周报中的。这样可以阶段性的对项目状态做总结，对项目进度做全局把控。
3. 运维手册
系统上线后，要想人人都能玩转生产环境，运维手册是必要的。公司有一个东北项目，在现场唯一的一个运维人员离职之后，整个部门就懵逼了。因为没有人了解那个项目了。大写的尴尬。只能通过关系让离职同事 写了一个简单的运维手册，系统才算勉强接下来了。但是接下来的大批量的运维工作只能靠摸索一点一点完成了（心疼交接人员3秒钟）。那么运维文档应该包含哪些呢？日终、日启应该做的事情，数据库运维说明，常见问题解决办法等等。总而言之，能够涵盖系统的各个方面即可。
4. 入场须知
经历过进入一个项目时那种白纸一样的状态么？问啥啥不知，找个干系人都麻烦。那种一拳打到棉花上的感觉让人很是无奈。可是自己入的坑，含着泪也要做完。因此在我开始带项目的时候，第一个要求就是写入场须知说明书。这样在项目来新人的时候只需要将入场须知说明书邮件转发一下，那么项目的方方面面都很清楚明了了。
除了上面这些文档，需求文档、用户手册、原型设计等不重要了么？不是的，这个以后有机会再说。但是上面这些文档如果没有，那就赶紧脱坑，离这样的项目越远越好。
END.
