编辑推荐:
系统架构——小议软件架构
监理行业是一个新兴的行业，各类监理的标准也应实际的需要应用而生，尤其是随着国标《信息化工程监理规范 GB/T 19668.1-2005》于2005年5月1日的正式实施，也标明信息化工程监理机制已在我国全面推行。但目前仍有不少的政府部门的用户对信息化工程监理知之甚少，或者仅仅是首次接触。加上市场对监理需求的总量增长，不断有新的监理公司出现，这些公司多在软件开发或集成业务的基础上发展其监理业务，虽然有一定的行业背景和技术积累，但对监理服务的认识仍停留在基础阶段。从整个行业来看，监理服务还有待规范和成熟。这必须要项目建设各方和监理方自身对行业认识有一个很大的提高。
根据近两年我参与的监理项目，接触了建设方、用户方、承建方，大多数对监理的认识都有一定的误区，具体如下：
(1)监理方可全权负责整个项目
电子政务项目不能由哪一方能够完成，不能要求监理全权负责需求的定论工作，项目中的用户方的参与和配合起着很大的作用，监理是从项目规范的角度，协调各方的资源，对项目的需求进行把握。
目前北京已经在信息化工程代建制上开始了实际的尝试，相信通过代建制的探索，也将更好地界定监理方的角色范围，从而使监理方能更专注地完成“五控两管一协调”监理服务内容。
(2)把监理方当作承建方的角色
有些业主常常要求监理方替代承建方进行方案设计、需求调研或进行计划编制，尤其是在项目进度滞后的时候。这种职责不清的结果就是失去了独立的第三方的监督控制作用，承建方甚至逃避对项目成果的负责，发生质量问题或项目延期时，承建方可以找借口推脱责任。
(3)要求监理工程师坐班
有些项目是由业主方提供场地，以软件现场开发为主进行的，开发方的人员从需求调研到项目实施都在业主方现场工作。有些业主会要求监理工程师也必须天天报到，包括编码阶段。有些业主是由于人手不足，就把监理工程师当成专职打杂。这种意识来自于建筑行业所要求的“旁站”，但在软件开发项目中，这种“旁站”并不能起到更好的效果，甚至还会干扰开发进度。监理公司也是需要考虑成本和计算利润的，如果投入大量的现场人员，必然会降低人员的素质要求，因此，从项目整体质量的把握来说，监理工程师坐班并不见得是合理的方式。
(4)监理方自身的素质问题
在软件开发项目中，由于不同项目对软件质量标准的认识和要求不同，项目规模和周期不同，对监理的要求也有很大的差异。如何做好软件开发项目的监理始终是一个难题。拿一个项目中的最佳实践用到另一个项目时却可能完全行不通。监理方自身认识的误区主要来自两个方面：一是对监理规范和监理流程的不熟悉，实施中更多的是基于个人的经验跟着感觉走。二是不懂得平衡与权变，试图用统一的模式去应付所有的项目。
(5)不切实际
监理工程师从业之前一般都有几年的工作经验，有些也是从事软件开发的。从承建方的角色转变到监理方需要有一个过程，常常会不知不觉中发生偏差。同一个问题，站在不同的立场来看待和处理，结果会有不同。要做到独立公正，而不依赖个人的感情因素做好项目中的技术沟通和组织协调，需要监理工程师有系统分析的能力，综合考虑多方面的因素，不能站着说话不腰疼，也不能过分夸大某个因素的影响。
(6)太过分要求文档工作
正如小型开发项目适宜采用极限编程(XP)方法一样，对项目管理的要求也是因项目而异的。这里面既有一个管理成本的问题，也有管理收益的问题。我们参与过的项目中，有些在文档方面的要求过高，导致了项目的延期。道理其实是很简单的，文档的根本目的是在于沟通，也是软件工程的一个重要组成部分，而不是仅仅为了通过上级部门的评审或专家的认可。如果为了追求十全十美的文档而忽略了其他更关键的问题，反倒得不偿失。有的监理方为了强调监理的作用，对文档的要求很高，严格把关，殊不知物极必反，过度要求也可能走向另一个极端。
项目引入监理机制是为了降低项目实施的风险，提高项目的成功率，但由于各方对监理都可能存在一些认识上的误区，使得项目监理的作用并没有得到充分的发挥，甚至反倒有可能造成一定的负面影响，因此，对监理认识的误区也是项目的一个重要风险。
项目具有唯一性，每个项目在开始阶段都免不了要经历一段时间的振荡，各方经过逐步磨合走向合作配合。降低风险发生的概率应从项目启动阶段开始，建议监理方可以给业主方和承建方灌输相应的监理知识，同时，对涉及项目各方的流程进行明确，并由各方达成一致意见。通过采取各种事前控制的手段，尽量缩短磨合期，消除认识误区，使项目各方更快地形成一个紧密合作的团队，共同完成项目的建设。
