【IT168 技术文章】

　　计算机管理信息系统(简称MIS系统)的开发是一项复杂的系统工程。从70年代开始，人们逐渐认识到，为了保证MIS系统开发成功，必须采用工程化的系统开发方法，并研究出一些符合工程化标准的开发方法。这些方法旨在指导开发者进行工程化的系统开发，从而加快MIS系统开发的速度、保证质量、以及降低开发成本。工程化的系统开发方法确实在开发实践中取得了一定的效果。

　　那么，是不是采用了工程化的系统开发方法便一定能保证MIS系统开发的成功呢？答案是否定的。有许多失败的MIS系统的例子，其开发也是采用了工程化的方法，或声称采用了这种方法。但结果在投入了大量资金后，系统却不能达到预期的目标、满足用户的需求，以致用户方怀疑是否应进行该项目的开发，或者开发所选择的硬件、软件以及开发工具是否得当。究竟问题出在哪里呢？笔者通过对一些失败的MIS系统的分析，发现问题并没有出在开发方法本身，以及硬软件的选择上，而是出在了开发方法的实施过程中，也就是说主要出在开发项目的管理上。

　　任何一种开发方法最终是要由人来实施的，人们在开发工作实施过程中不可避免地要遇到许多项目管理方面的问题，如何正确对待、解决这些问题，直接关系到MIS系统开发的成败。目前计算机界虽有许多关于MIS系统开发中项目管理方面的问题的讨论，但大多局限于针对理想开发环境中的理想开发模型的讨论。而实际的开发环境和开发模型却各不相同，它受到各种客观因素的影响，忽略这些因素，或者回避、不解决存在的问题，必将导致开发工作的不完善、甚至于失败。本文就是要通过讨论如何处理实际MIS系统开发中一些重要因素之间的关系，分析项目管理中存在的矛盾，来揭示其中存在的问题并探讨解决的方案。

    什么是MIS系统开发的项目管理   

　　MIS系统开发的项目管理是根据管理科学的理论，联系MIS系统开发的实际，保证工程化系统开发方法顺利实施的管理实践。它包括MIS系统开发中的项目评估及可行性分析、人员管理、进度管理及成本控制等方面。

    项目开发中的角色及其职责

　　一个MIS系统的开发需要用户方与开发方的共同协作。在一个MIS系统开发中，开发方人员和用户方人员各自扮演着不同的角色。主要角色有：

　　用户方的项目管理人员：他是开发项目的组织者，负有开发项目的计划、系统的阶段验收及对系统整体进度的监控、经费的使用、与开发方的项目管理人员工作的协调、用户方的使用人员的组织与培训等职责。

　　用户方的业务人员：MIS系统的需求的提出者，也是MIS系统的最终用户。他们是对应用系统开发成功与否的最终评判者。

　　用户方的决策层：MIS系统开发的最终决策机构，决策层要对MIS系统开发的项目的上马、经费的预算以及系统所要达到的总目标等作出决策。其决策直接关系到MIS系统的开发成功与顺利实施。

　　开发方的项目管理人员：负责项目的计划、开发人员的组织与调度、开发进度的检查、以及与用户方项目管理人员工作的协调。

　　开发方的软件编程人员：根据用户方的需求、按照项目的计划及进度进行系统开发。

    项目管理中各种问题及各种关系的处理

    1、用户方与开发方的关系

　　用户方与开发方是对立的统一体，双方均希望将开发项目做好。但用户方可能对计算机系统工程，如工程组织，缺乏全面的了解；而开发方对用户方的需求、细节了解不充分等因素，使得用户方与开发方对工程的理解从一开始就存在着差异。而这种认识上的差异与理解的不同往往在开发初期并没有表现出来，当系统开发结束时，双方才发现这种差异使开发出的系统与实际需求偏差甚远。因此，MIS系统开发项目管理的重要目标便是建立一个便于开发方与用户方之间进行交流的环境。在系统需求分析阶段，开发方与用户方的深入的交流是项目获得成功的关键。但这种交流却经常由于各种双方的误解而难以沟通。

　　在需求分析阶段，开发方的分析人员总是先把精力集中在整个系统的总的需求上，而不会对具体细节作过多的考查。当用户方提出一些细节要求时，开发方往往说：“这些问题留待后面讨论”，而糟糕的是以后却可能永远不会再谈及这个问题。当用户方认为已经向开发方提出这些需求时，开发方却根本未予考虑。因此，开发初期，用户方的项目管理人员应该把这些“留待后面讨论”的需求单独记录整理，在开发方做完系统的整体需求分析后，项目管理人员应及时提出对系统进行进一步的、更深入的、细致的、具体的需求分析，以解决那些开发方要“留待后面讨论”的问题。

　　在某些需求尚未确定时，用户方项目管理人员往往会说：“这部分需求我们还要考虑，不过你们可以先按现在的模式做。”遗憾的是，开发方经常就会把现在的工作模式作为将来的、确定的需求去设计开发系统，而把用户方在此需求上的未确定因素抛在脑后。当后来用户方要求其改变时，开发方便陷入了窘境。因此，用户方管理人员应尽量将需求陈述清楚，对不能确定的因素，应提出几种可能的实施方案供开发方参考，以保证开发方系统设计时，将不确定因素设计成灵活可变的功能。

　　开发方说：“用户方已经认可了需求分析报告，这表明我们已经彻底了解了用户方的要求。”

　　用户方说：“尽管我不太明白需求分析报告中的一些技术术语，但他们能写出这个报告，一定是对我们的需求了解得很深入了。”

　　其实，需求分析报告是对系统需求的书面表达形式。由于需求分析报告是采用软件设计的术语编写的，因此常常令计算机背景知识较少的用户方难以理解，也就很难发现需求报告中与实际需求不符之处，更难提出建设性的意见。特别是那些编写得较差的需求分析报告，用户方更是不知所云。

　　因此，用户方的项目管理人员一定要要求开发方对需求分析报告进行进一步更详细的解释，以便用户方准确地理解需求分析报告的内容，能及早地发现需求与实际的偏差。这也是对需求分析工作的总结与确认。

　　用户方说：“计算机应该能实现这个功能，为什么会作不到？”用户方往往容易过高地估计计算机的软件开发工具的能力，总认为它一定能实现任何所需功能，期望值过高，所以经常会对所设计的软件大失所望。其实任何技术均有其一定的局限性，计算机系统也不例外，系统开发的最终结果只能达到有限的目标。因此，双方应详细制定系统最终实现的目标，切不可用一些简单的术语来笼统概括需求，例如：“实现办公自动化”、“建立现代化的MIS系统”这种抽象的术语只能将用户对MIS系统的理解引入误区。

　　总之，用户方与开发方的关系是项目管理所要处理的最重要的关系之一，增加沟通和减少误解是处理好这个关系的关键。所以项目管理人员要有效地安排开发方软件人员与需求方使用人员的交流，保证有畅通的交流渠道。在交流中用户方要尽量避免含糊不清的需求，而开发方要杜绝敷衍了事、得过且过的行为。