初级监理工程师修炼之文档审核

一个项目的建设历程最终都是体现在项目文档里，每个阶段、每个环节都会形成不同的文档，那么每个文档的成文时间对应的就是项目每个阶段的起始时间或者是建设成果的形成时间。项目的建设过程、每个建设阶段的相对持续时间、工序的先后等，都存在一定的规律性，监理人员在审核文档时就要特别注意，尤其是对于后期集中补的文档，更要把它当作一个重要的审核工作环节。

比如某软件开发项目后期补的文档，总工期是7个月（要求开发完成，具备上线运行条件），开工时间是1月初，需求规格说明书确认时间定在2月初，设计说明书的成文时间是2月中旬，开发完成的代表性文档（测试记录、内部测试报告等）成文时间为6月底。这里可以看到，需求和设计的总时长才1个半月，但写代码（加测试）的时间却长达4个半月，按照软件工程理论，需求调研和设计是软件开发项目的重点工作，应占软件开发周期的大部分时间，而代码实现则是技术含量相对较低的工作，耗时应当相对较少，因此可以发现，上述的文档成文时间是存在不合理性（如果是按照实际进展形成的文档，能说明原因也可以）。

再如，某个弱电施工项目，第一批施工材料（管线）的到货验收时间签署日期是2月10日，而第一份隐蔽工程报验单的签署时间确实2月5日，材料都没有到货呢，如何进行的隐蔽工程施工呢？这就是工序时间上的不合理。

另外，监理人员在审核文档是还要注意一些隐含信息的时间逻辑。比如有些软件的操作手册里会放上一些系统截屏，里面可能会出现时间信息，这些时间信息不能晚于操作手册的成文时间；还有就是要注意监理文档（特别是周报和会议纪要）里体现出的某些工作完成时间、项目进展情况等时间信息，也要和承建单位提交的项目文档成文时间逻辑上相对应。

审核各个文档内容是否相互呼应

这点强调的是文档集里各个文档对同一个事项的描述应当是统一的，文档内容上不能出现相矛盾的信息。比如合同约定的某系统并发用户数量是600人，概要设计描述了能够达到并发700人，而详细设计又描述并发用户数是650人，虽然概要设计和详细设计的描述都满足合同要求，但是却不一致，最终可能会出现验收时无法确定以哪个为标准的情况。这类情况在技术指标方面的描述上也很容易出现，监理人员在审核文档时应注意，看到这类信息时应翻一翻前面的文档对比一下。

另外，还要注意文档间的“一脉相承”关系，或者叫双向可追溯性。最典型的是软件开发类的文档，例如需求规格说明书、概要设计说明书、详细设计说明书等，需求规格说明书确认的所有软件功能、性能、安全等方面的描述都应当在概要设计说明书和详细设计说明书里得到设计体现；反过来，详细设计说明书里的所有描述都能对应到概要设计和需求规格说明书里关于功能、性能或安全方面的描述。

审核方案或计划类文档的合理性

针对某项工作制定的实施方案或者进度计划，审核起来可能会有一定的难度，对监理人员的经验和技术水平也有一定的要求。但是抛开技术和经验方面的因素不说，我们一样可以从方案或计划的合理性、全面性、及可操作性等方面进行审核。

拿初验方案的审核来说，初验方案一般包含三部分内容，第一部分要说清楚项目建设情况，再要说清楚初验工作如何组织，最后一部分就是初验测试表单。对于项目建设情况描述，只要与项目实际情况相符就没什么大问题；初验工作的组织，就是要说清楚如何开展初验工作，无非是人员组织、时间安排、以及所需的测试工具等内容，满足项目实际要求即可；测试表单，或者叫测试用例，关键的就是要审核其是否涵盖了所有确定的需求，以及这些测试用例是否具有现场可操作性。这里重点说一下测试表单的审核，对于其是否能覆盖所有确定需求，只要审核人员认真对比一下需求确认文档或者合同、设计文档等，都不难进行审核；对于可操作性，就需要审核人员认真去看测试用例、测试方法或步骤，假设在验收现场的情况下能不能按步骤进行操作及得出预期结果，如果可以，就具有可操作性，如果不可行，就需要再修改或细化。例如，某系统验证关键数据完整性的测试用例——“用户对系统进行操作时，关键数据保持完整性”，这个用例就不具有可操作性，没说清楚用户进行何种操作、具体的操作步骤、什么是关键数据、何种状态表示关键数据是完整的等等。

关于文档里技术可行性、施工工序的合理性、时间计划的合理性、风险问题等方面的描述，如果审核人员觉得有难度的话应当请有这方面技术经验或类似实施经验的工程师协助审核。1/2 12下一页尾页

审核文档是否规范

文档的规范性，就是从文档的字体、字号、格式等方面，确保文档的统一、规范。有人可能会觉得，只要文档内容上没有问题，格式上就无关紧要了，其实我不同意这种看法。文档是否规范，不仅体现出的是文档编制人员以及审核人员是否认真的态度，在项目文档外部评审时——比如专家评审会上，可能也会带来一些问题（下文里具体说）。文档规范性的审核，总结我个人的经验，主要包含下面一些内容：

封面和文档内容格式保持统一。同一个项目承建单位的文档，各个文档的封面建议采用统一的格式，包括文档名称的字体、字号、行间距，封面底部的公司名称落款、时间信息的字体格式等；不同文档的内容也建议采用统一的格式，包括目录格式（包括字体、字号、间距等，下同）、章节标题格式、正文格式、图表名称格式等等。

避免错字、别字，段末没有句号、段首没有缩进，多词、少字等错误。多数情况下审核人员首先审核的都是电子版文档，拜托WORD软件的语法识别标记功能，在进行文档内容审核时，可以特意的关注这些标记，就很容易挑出“刺”来。

名称或称谓统一。也就是说，对同一个事物的称谓在一个或一类文档里应保持统一。如甲方、业主方、业主单位、建设单位、建设方等，都是对同一单位的称谓，在一个文档体系里应尽量一致。

特别注意项目名称要与合同一致。文档封面标题、文档内容信息里，项目的名称一定要与合同的一致，一个字也别差。有些项目名称口头上叫习惯了，纸面上就忽略了，很容易和合同约定的项目名称出现偏差，因此尤其要注意。有一种特殊情况，就是承建合同和监理合同约定的项目名称不一致，我个人的处理办法就是，承建单位文档依据承建合同，监理单位文档依据监理合同。

目录里的页码对应准确。文档编制和审核过程中都会出现反复修改的情况，修改完成后忽略目录的更新也是常见的问题，审核时应当注意。

需要手签的记录一定要手签，保持文档的原始性和真实性。例如测试记录、培训签到表、培训反馈意见、试运行记录等，如果是机打，在文档评审（如验收专家评审）时，评审专家就会怀疑文档的真实性，影响评审结果。

尽量避免只签名、盖章，意见栏为空的情况。对于一些报验、报审类表格，很多业主单位习惯于只签名、盖章，却在意见栏里什么也不写；或者一些表格里需要监理单位出具审核意见、承建单位出具签收意见的，也会出现空在那的情况。这样的文档在提交审核时，可能会被评审专家提出类似“你只签名不写意见到底是同意还是不同意啊”这样的问题，所以应尽量避免。

文档装订厚薄合适，装订顺序具有一定的规律性。根据项目规模或者周期的不同，项目文档的多少也不一定，在文档装订的时候，审核人员有必要提醒一下承建单位注意装订顺序以及合理确定装订册数。太薄，册数就太多，不方便管理；太厚，册数少了，但是不方便翻阅。文档的装订顺序应当有一定的规律，比如可以按照项目各阶段的时间顺序分类装订，也可以按照文档类别分类装订，装订好的文档每一册应当有个文档目录，方便查找。

结束语

关于文档审核方面的内容其实很多很多，再给这么个篇幅估计我也写不完。东西很零散，都是基于经验积累，总结和梳理起来确实比较困难，希望读者理解起来不是太费劲。

文档审核其实是监理工作的重要内容，所以在实际工作中也尽量做到留痕，比如将审核意见以专题报告的形式形成并且提交，这样既丰富了监理文档，也体现出了监理工作量，必要的时候也能作为备查依据。

信息系统工程项目所涉及的技术面很广，所以每个项目都有每个项目的特点，没有文档的固定要求，但是基本的方向和依据是明确的，监理人员只要把握住基本的方向和依据就能开展文档审核工作。监理人员不可能熟知各个领域的技术知识，所以对于文档审核，很少会说这篇文档哪里写得好（当然对比说明的时候除外），但是一定要能说出哪里写的有问题。