项目文档知多少（五）

二十三《项目阶段验收申请》

   这份文档要根据项目规模的大小以及签订合同时所约定的付款方式来决定是否需要。一般的小项目都采用是3:6:1的付款方式，那就不存在项目阶段验收的情况。如果是大项目，我们一般会力争的付款方式是3:3:3:1，那么在申请第二个30%的款项时，就必须向客户提交《项目阶段验收申请》了。该文档要详细描述前阶段的项目进展情况，能量化的地方一定要用数字说话，比如项目历时多长，完成了哪些功能模块，有哪些模块上线运行了，没有投运行的模块是出于什么原因。到现场工作了多长时间，做了多少次培训等等，最后还要列出下阶段的工作安排，需要客户配合的工作。除了这些有据可查的数据描述外，一些宏观的，客套的，应景的话也要作为总结信的语言放在最后。比如：项目为客户信息化取得什么成果，给客户解决了什么问题、带来什么好处，还要重点感谢客户的配合等。这份文档的终极目标是让参与验收的客户人员能在上面签字盖章，所以这份虚实结合、讲求策略〔面对一塌糊涂的项目这是必须的〕的文档一般由项目经理亲自操刀。
二十四《项目整体验收申请》

   基本上和阶段验收报告类似——虚实结合、讲求策略。但阶段验收申请中的下阶段计划安排要改为项目的后期维护服务，算是在这里做个小小的承诺〔一定要根据合同条款来〕。另外，在提交整体验收申请时，要附上项目过程文档。除了涉及到公司机密的文件之外，能够给的全部复印一份交给客户，不要让客户在文档方面挑我们的毛病。当然，能否顺利通过验收，绝不是文档做好就能搞定的事情，更多的是我们要用项目文档来管理〔规范〕我们的项目过程，毕竟，项目做得好才是通过验收的坚实基础。

   终于写完了项目文档知多少这一系列博客，也是自己的第一篇博客。在上下班的途中，在出差的火车上用手机一个字，一个字码出来的。回顾自己从业it行业8年，从程序员，项目经理，部门经理一步步的走开，始终坚持在一线上。既要深入到现场与各种类型客户打交道、协调关系，又要在部门内部深抓项目管理、平衡人力资源。在完成公司的任务之外还要考虑团队的建设，技术的走向，产品的创新。面对公司的发展，还得从公司层面上去和高层保持思想统一，带领部门人员贯彻执行，即使是以牺牲部门利益为代价。
   这么多年的忙与累，成功与失败，经验与教训，责难与鼓励，技术与管理，点点滴滴、积累于心。写博客既是表达心中所想的一种渠道，更是自我梳理项目管理经验的过程。之所以选择项目文档之多少作为开篇博客，其理由是因为我所列的文档贯穿于项目的整个过程，包括项目前期的投标，项目进行中的需求，设计，开发，测试，实施以及项目后期的验收及维护。通过这么些个文档首先将项目流程梳理清楚，至于流程的每个环节那都需要单独的篇章来回顾和总结。
  有的公司规模小，项目用不上这么些文档。有的公司规模大，管理更为规范，文档不止我列的这么一些〔例如：代码复查报告，风险分析报告等〕，还有的公司走的是敏捷开发之路，遵循简单的文档、面对面的沟通原则。总之，文档在项目管理的过程中起着工具、手段的作用，是沟通的桥梁，是约束的规范，是产出的结果。
   我们公司做得是行业应用软件，技术门槛不高，所以在招聘人员的时候，我大多数都会考察应聘人员的项目经历，团队合作经验及现场应对能力。在问到项目经历的时候，我一般会问应聘者在项目过程中会留下哪些文档。从他对文档的描述细节中我大都能看出他参与过项目的哪些阶段。然后再根据文档把问题延伸下去。我发现，看文档的人和写文档的人根本是两回事。看文档的人多是在别人的成果上进行工作，而写文档的人才真正参与到工作其中。因此，从文档的角度来考察个人的项目经历具备一定的说服力。
    写到最后，我还想再强调一下。文档只是工具，是需要灵活运用的工具，是需要根据项目的规模，人员的素质来匹配组合的。如果一味的遵守某些Iso或cmmi的要求为了文档而文档，其结果将会适得其反，不仅项目质量与进度没有显著的改善，还会弄得怨声四起，士气低落。只有弄清每个文档背后所要解决的问题〔文档只是结果〕，才能有效的利用文档这个工具去解决自己的问题。