在某种程度上，监理不仅需要进行传统意义上的监理工作任务，更要对业主提供深入细致的管理咨询服务。在电子政务工程项目实施过程中，监理需要和业主以及承建单位密切结合，应用科学的方法，找出项目存在的主要问题和风险，进行定量和确有论据的定性分析，查出存在问题的原因，提出切实可行的改善方案，进而指导实施方案，使电子政务工程项目的运行机制得到改善，提升整个工程的管理水平。在此过程中，特别是软件应用类项目的实施过程中，笔者结合自身工作经验，分析总结了9个可能存在的管理观念误区，希望能与各位读者共勉。
北京赛迪信息工程监理有限公司  张大雷 吴兰英

随着计算机水平的不断发展提高，电子政务工程项目也愈发呈现内容繁多、技术应用种类多样、建设工期较长、服务对象特殊、建设要求较高、完成质量严格、流程控制严密等特点，监理面对的服务商众多，协调和管理难度巨大。在某种程度上，监理不仅需要进行传统意义上的监理工作任务，更要对业主提供深入细致的管理咨询服务。在电子政务工程项目实施过程中，监理需要和业主以及承建单位密切结合，应用科学的方法，找出项目存在的主要问题和风险，进行定量和确有论据的定性分析，查出存在问题的原因，提出切实可行的改善方案，进而指导实施方案，使电子政务工程项目的运行机制得到改善，提升整个工程的管理水平。在此过程中，特别是软件应用类项目的实施过程中，笔者结合自身工作经验，分析总结了9个可能存在的管理观念误区，希望能与各位读者共勉。

误区一：在电子政务软件开发项目的需求分析阶段，开发方与业主方在大方向上达成一致，具体细节在以后讨论补充。因为无论开始时有多么细致， 以后对需求的修改几乎是必然的，这是一种非常危险的误区。实际上许多项目失败的最主要原因就是需求阶段对需求问题的描述不够细致准确，导致后来投入超出预计或者工程进度达不到要求。赛迪监理建议在项目需求分析阶段，开发方与业主方必须尽可能全面细致地讨论整个项目的应用背景、功能要求、性能要求、操作界面等要求、与其他系统的接口要求，以及如何对项目进行评估的各种评价体系和标准。并且在需求分析结束以后，双方还要建立联络机制和渠道，以尽早地对需求变动问题进行沟通确认。这并不是无用功，需求分析阶段尽可能细致详尽的工作能够为后续开发工作奠定良好和坚实的基础。

误区二：电子政务工程中需求是不断改变的，且改变是比较容易能够实现的，是良性的。我们需要承认，在项目建设过程中，由于种种原因业主方很难在需求分析阶段全面细致准确地描述所有问题。随着工程进度的推进，往往会有一些需求发生改变，或者未确认的需求得到确认。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“需求是不断改变的，且改变是比较容易能够实现的，是良性的”。事实上，随着工程进度的推进，实现需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在系统基本定版发布以后，甚至可能要花费60-100倍的代价。赛迪监理建议，在电子政务工程项目开展过程中，软件需求的改变应当尽量早地提出，尽早的进行沟通确认，这样才可能花费少， 容易被实现。

误区三：编码阶段是整个软件项目的最重要的阶段，应该把工作重点放在此阶段，资源投入也要适当倾斜。与以前的电子政务工程相比，现在由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，甚至软件产品定制开发的出现，目前电子政务工程的项目管理的中心发生了转移，由编码阶段向需求分析阶段和概要详细设计阶段转移。更多的问题需要在需求和设计阶段解决和发现，编码阶段只是将需求和设计准确的翻译成为产品，所以赛迪监理建议适当在需求和设计阶段加大投入和管理力度，会使整个工程更为可控和高效。

误区四：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对 程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护，工作量是很大的。所以赛迪监理建议对一般的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。

误区五：既然在项目人员配置中设置了专门的测试人员，那么电子政务工程所有的内部测试工作全部应该由专门的测试人员完成。笔者认为这是一个严重的误区，软件测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试;如果测试没有通过，不得已这才考虑对程序代码进行“白盒法”测试。赛迪监理建议，在交给测试人员进行测试之前，应该由程序人员自己进行必要的白盒测试，否则对系统的可靠性和稳定性构成了威胁。为了解决好这类问题，一方面需要提高对测试人员的要求，另一方面也需要程序员完成该有的白盒法测试。

误区六：电子政务工程项目管理只是项目经理的事情，和其他方无关。在电子政务工程日益复杂的的今天，系统规模大、复杂度高而且时间要求紧迫。要想提高电子政务工程的项目管理水平，这就需要提高整个项目团队的整体参与意识，需要各方协同作战。赛迪监理建议，成立项目领导小组，由主要领导牵头组织协调，由监理人员参与管理，由项目开发团队参与讨论，更细致更有效地开展项目管理工作。

误区七：在项目进度滞后的情况下，可以让更多的开发人员加入到开发团队中，通过增加人力资源的方式赶上进度。这个误区普遍存在，但在注重团队开发的时代，项目组应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的开发人员对目前开发的项目有一定了解，对业务理解也比较到位，并且可以很快适应了项目组的项目管理方式、软件开发风格、团队协作氛围，那么这样的人加入团队中是有益的。否则，可能事倍功半。因为尽管新加入的人个人能力可能很高，但是为了使其与大家一起协同工作，团队不得不分出人手对其进行与项目有关的技术业务培训，引导其融入团队，这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。

误区八：技术骨干应该成为项目的管理者。过去，这是一种普遍使用而且效果不错的方法；现在，这种方法却带来各种问题，有时甚至直接导致项目出现各种问题。这主要是因为随着软件开发分工的细化，对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术的掌握程度，而是其组织、领导、协调开发团队的能力。赛迪监理建议，技术骨干更适宜项目中某个专业组别的领导岗位，带领大家一起进行工作，而不是由技术骨干出任项目管理岗位。

误区九：管理人员关心项目整体进度，开发人员只关心自己的开发进度。这是一种“官僚”的想法，实际上开发人员作为团队中的一员，他不仅仅需要关系自己个人的开发进度。赛迪监理建议，当项目完成一个里程碑时，项目管理人员应该把这个消息通知每一位项目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。